Authorization

Overview

The Partner IAM API is a backend and admin-facing API group. Its operations manage organizations, invitations, org domains, org connections, and org-specific access control, so the authorization model is primarily service-side.

These routes should be treated as administrative operations, not public browser-facing user flows.

Primary authentication models

The dominant patterns in this group are:

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

This group is much closer to management APIs than to consumer login APIs in how it is authorized.

Required credentials

Depending on the route, expect:

• 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 Partner IAM API group:

• APIKey
• APISecret
• ClientId
• ClientSecret
• M2MBearerToken

Practical interpretation

• most operations are backend-authenticated administrative calls
• M2M token usage is especially relevant for org automation and partner-system integrations
• end-user bearer-token assumptions do not describe this group well

Headers and query parameters

Common auth inputs include:

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

Because these routes affect org membership and org access control, they should be executed from trusted systems only.

Token usage guidance

Prefer service-to-service execution

Partner IAM operations are best executed from backend services, admin tooling, orchestration layers, or partner-management systems.

Use M2M where available

M2M bearer tokens are a strong fit for:

• automated invitation systems
• org-provisioning services
• B2B onboarding flows
• admin panels backed by server-side orchestration

Examples and common patterns

Typical patterns in this group include:

• creating organizations from a provisioning backend
• issuing and resending invitations from an admin service
• assigning org roles as part of onboarding or account governance
• verifying organization domains during enterprise rollout
• managing org connections through partner configuration services

Common auth errors and pitfalls

• treating partner IAM endpoints like consumer-facing account routes
• exposing tenant or client secrets in browser code
• assuming org operations can rely on user-session auth alone
• underusing M2M tokens for service automation

Always validate the generated operation page for the exact endpoint, especially for invitation, role, and connection management flows.