Enterprise API Surface

AxonFlow Enterprise adds customer-portal, identity, deployment, admin, and regulated-workflow APIs on top of the core Agent and Orchestrator runtime APIs.

The most important rule is simple: do not assume every enterprise API uses the same authentication model.

Main API Families

API family	Primary path	Typical auth model	Use it for
Portal sessions	/api/v1/auth/...	portal login session	customer-portal login, logout, session checks, SSO availability
Portal operations	/api/v1/keys, /api/v1/license, /api/v1/nodes, /api/v1/usage	portal session	portal-backed admin and visibility workflows
Admin organization APIs	/api/v1/admin/...	admin API key in SaaS production	organization lifecycle, password reset, license operations
SSO configuration	/api/v1/sso/...	portal session with SSO configuration permission	SAML/OIDC configuration, metadata fetch, login audit
SCIM provisioning	/scim/v2/...	SCIM bearer token	IdP-driven user and group provisioning
SCIM token management	/api/v1/scim/tokens	portal session with SSO configuration permission	create, list, and revoke SCIM tokens
Deployment operations	/api/v1/deployments/...	portal session	version checks, upgrade trigger, upgrade status, upgrade history
Runtime management	/api/v1/llm-providers, /api/v1/connectors, policy APIs	portal session or runtime-specific auth	provider, connector, policy, and governance operations
Regulated workflow APIs	framework-specific /api/v1/... paths	enterprise auth context	compliance exports, assessments, dashboards, and oversight workflows

Authentication Patterns

Portal session auth

Used for customer-portal workflows. Login creates the axonflow_session cookie, and portal-backed APIs use that session context.

Useful routes:

• POST /api/v1/auth/login
• POST /api/v1/auth/logout
• GET /api/v1/auth/session
• GET /api/v1/auth/sso/availability

Admin API key auth

Used for /api/v1/admin/... routes. In SaaS production, these routes require X-Admin-API-Key. Non-production and self-managed environments may configure the middleware differently, but production runbooks should treat the header as required.

Treat the admin API key like a database credential or cloud root credential. It is for tightly scoped tenant lifecycle and license automation, not application runtime code. Detailed organization-admin endpoint reference is kept in the protected enterprise docs because it covers organization CRUD, password reset, and license issuance.

SCIM bearer-token auth

Used only for /scim/v2/... provisioning requests from identity providers.

Authorization: Bearer scim_your_token_here
Accept: application/scim+json

Discovery endpoints such as /scim/v2/ServiceProviderConfig are public in the current implementation. User and group operations require the bearer token.

Runtime and control-plane auth

Agent, Orchestrator, policy, connector, and provider routes may use runtime credentials, portal sessions, or internal service auth depending on the route family. Check the specific API page before assuming a header pattern.

Choosing The Right API

If you need to...	Start with
call the governed runtime from an application	Agent API or Orchestrator API
decide which path an app should call	Runtime Request Paths
configure provider routing	LLM Provider API
manage policies	Static Policy API and Dynamic Policy API
manage organizations or licenses	use the protected enterprise admin reference
configure SSO	Single Sign-On
provision users and groups from an IdP	SCIM 2.0 Provisioning
plan enterprise deployment operations	Deployment Overview

Common Integration Mistakes

• using SCIM bearer tokens against portal APIs
• trying to use portal sessions for /scim/v2 provisioning
• treating /api/v1/admin/... as ordinary portal-user APIs
• assuming deployment upgrade acceptance means rollout completion
• building against compliance APIs without confirming the enabled module and auth context

Related Docs

• API Overview
• Auth Header Matrix
• Identity Overview
• Deployment Overview