Skip to main content
An Arbol access token identifies both an actor and an organization. The API verifies those claims before it resolves any resource or executes a handler.

​
Tenant boundary

Organization identity comes from the verified credential. Public resource inputs therefore do not accept an orgId that changes the tenant boundary. This has three practical effects:
  1. Resource identifiers are meaningful only inside the credential’s organization.
  2. A resource from another organization is never made accessible by supplying its identifier.
  3. Organization membership and role changes take effect through the identity provider, not through a second API-owned permission store.

​
Actors and permissions

The OpenAPI contract can declare user-delegated and machine-to-machine security alternatives. Within either alternative, the listed scopes are an all-of requirement. For example, an operation that reads a conversation transcript can require both conversations:read and conversations:transcript. Possessing only one scope is insufficient.
User tokens also carry the baseline organization grant declared by the contract. Machine credentials receive only the explicitly granted operation scopes.

​
Design integrations around the boundary

  • Store Arbol resource identifiers with the organization context in your application.
  • Request the smallest permission set your integration needs.
  • Treat a 403 response as an authority decision, not as a signal to retry with a different organization identifier.
  • Re-authorize when membership, role, or connected-account access changes.