Operators authenticate through the same auth endpoints as customers — there is no separate back-office login. What makes a session an operator session is the role carried in its claims.

​
Signing in

  1. POST /v1/auth/login with email + password, and the x-program-id header.
  2. Complete the 2FA challenge with POST /v1/auth/verify-2fa (TOTP). Operators are expected to have 2FA set up; use POST /v1/auth/mfa/setup + confirm on first login.
  3. Use the returned access_token as Authorization: Bearer <access_token> on every Management API call.

​
Roles and permissions

The token’s claims determine what an operator can do:
RoleScope
PROGRAM_SUPER_ADMIN / PROGRAM_ADMINAdministration within their program(s).
CUSTODIAN / CUSTODIAN_ADMINScoped access to the customers they manage.
(Orenda-internal roles also exist; capabilities exclusive to them aren’t covered by these docs.) Individual endpoints additionally check permission claims (for example transactions.view, payments.create, reports.view, audit.trail.view, triage.edit). Each endpoint’s required claim is noted on its page. Two introspection endpoints help you build operator UIs:
  • GET /v1/access-management/me — who am I: the caller’s profile and role.
  • GET /v1/access-management/program-claims — which programs this operator can act on, with per-program access metadata. A claim of * means all programs.