Skip to main content

Praxis API overview

Reach for the HTTP APIs when you want scripts, services, or pipelines-as-code to do the same things you can do in the UI: manage collectors, pipelines, integrations, and related objects. Request and response shapes are defined by the OpenAPI document for your Praxis environment; in this documentation, the generated pages under API Documentation in the sidebar mirror that spec.

Where to read every path and schema
In the left sidebar, open Praxis (or your app), then expand API Documentation. Operations are grouped by tag (for example Collectors, Pipelines).

When teams use these APIs​

  • Operations at scale — List, filter, restart, reload pipelines on, or upgrade many collectors without clicking through the UI.
  • Automation — Promote pipeline changes from CI/CD, keep an internal portal in sync, or integrate with your change-management system.
  • Consistency — Apply the same tenant and RBAC rules as the product: your token or service account must be allowed to touch the same resources a user could.

What you can call depends on your Praxis version and edition; the OpenAPI file and API Documentation pages always reflect what your server actually exposes.

Access and security (what you need to line up)​

  • Base URL — Use the HTTPS API base URL for your environment (often the same host as the UI, with a versioned prefix such as /v1/...). Your OpenAPI servers entry lists the exact values.
  • Authentication — Expect short-lived tokens tied to sign-in and tenant context. Collector supervisors and other machines typically use client credentials (or the flow your identity team documents). Never commit long-lived secrets to source control.
  • Tenant scope — Each request runs in a tenant context; verify your automation is using the right tenant and roles.
  • Authorization catalogs — Praxis HTTP APIs are checked against the praxis application in the RBAC catalog (permission names such as pipeline:read). Identity Management APIs (orgs, tenants, users, invitations, API tokens, SSO) are keyed as idm. Audit exports or GET /v1/users/{id}/realized-permissions style responses list permissions per app_id; use praxis and idm, not legacy adaptive-pipeline / identity strings.

Your deployment guide and OpenAPI security section are the sources of truth for hostnames, scopes, and credential types.

A good first API call​

Pick a read or list operation you care about (for example List collectors). A successful response confirms:

  • the base path and API version you should hard-code or configure;
  • that auth and tenant headers or tokens are correct;
  • pagination and filter parameters your integration should use.

How this documentation is organized​

  • This page — How APIs fit your workflow and where to read the full reference.
  • API Documentation (sidebar) — Generated from OpenAPI (paths, parameters, schemas, and try-it where enabled).
  • Integrations and Installation — Human-oriented reference for collectors and pipeline building blocks; they do not replace the HTTP reference.