Authorization

Overview

The Management API is primarily administrative and service-side. Most operations in this group are intended for backend systems, admin tooling, or automation layers that manage tenant configuration and governance.

This group should not be treated as a public user-facing API surface.

Primary authentication models

The dominant auth patterns in this group are:

• tenant API key and secret
• client ID and client secret
• machine-to-machine bearer tokens

These patterns reflect the operational nature of tenant and platform administration.

Required credentials

Depending on the route, expect some combination of:

• apikey
• apisecret
• client_id
• client_secret
• Authorization: Bearer <m2m-token>

Security schemes used in this group

The current public spec uses these schemes in the Management API group:

• APIKey
• APISecret
• ClientId
• ClientSecret
• M2MBearerToken

Practical interpretation

• tenant credentials are common across management endpoints
• client credentials are used where application-level authorization is part of the control plane
• M2M tokens are important for service automation and backend orchestration

Headers and query parameters

Common auth inputs in this group include:

• query apikey
• query apisecret
• query client_id
• query client_secret
• header Authorization: Bearer <token>

These routes should usually be called from controlled backend systems, not public applications.

Token usage guidance

Use service-side credentials

Prefer server-side tenant and application credentials for administrative operations.

Use M2M for automation

If your architecture supports service-to-service authorization, M2M bearer tokens are appropriate for workflow engines, integration services, and admin automation.

Keep configuration writes backend-only

Provider, client, policy, and governance changes should never be exposed to browser-only clients.

Examples and common patterns

Typical patterns in this group include:

• provisioning OAuth, JWT, or SAML client configurations
• rotating or updating provider settings
• maintaining templates and communications settings
• configuring password policy, CAPTCHA, passkeys, or second factors
• managing webhooks, workflows, roles, and permissions
• generating SOTT from a secure backend service

Common auth errors and pitfalls

• exposing tenant or client secrets in client-side code
• using consumer-auth assumptions from Authentication API on management endpoints
• assuming all configuration endpoints support the same auth shape
• skipping M2M token support where service automation is expected

Always validate the exact generated operation page for the endpoint you are automating.