Access management models who may act on whom: operators (human back-office users), software users (machine identities), and the customers they manage. All endpoints are under /v1/access-management/ and use the operator’s bearer token plus the x-program-id header.
Every endpoint below is also in the interactive API Reference tab — full schemas, examples, and a “try it” playground. The customer-invite flow has a dedicated walkthrough at Invite a customer.

​
Introspection

EndpointReturns
GET …/meThe caller’s profile and role.
GET …/program-claimsThe programs the caller can act on (claim * = all).

​
Users

EndpointNotes
GET …/bo-usersAll back-office users in the program (limit + nextToken pagination).
GET …/software-usersThe program’s software (machine) users.

​
Inviting customers

  • POST …/invite/customer — a back-office caller invites either a plain customer ({ "email" }) or a sub-role member by setting a flag (isPrepaidCardCustomer / isCardOnly / isSpouse / isChild). When a sub-role flag is set, accountId is required and names the funding parent account. payInIBAN is required when the resolved onboarding role enables pay-in. Every invite carries a step-up confirmation. See Invite a customer for the full flow — it embeds the Try it playground for POST …/invite/customer. (Customers inviting their own sub-users use the same route on the customer API.)
  • GET …/invited — invites this caller has sent, with live card details where linked.

​
Step-up authentication

Every invite requires a step-up before the invitee is created — including back-office invites. The request carries a confirmation object, either passkey or TOTP:
  • Passkey — { "method": "passkey", "passkeySession", "assertion" }, where passkeySession comes from POST /v1/auth/passkey/challenge and assertion is the JSON-stringified WebAuthn assertion.
  • TOTP — { "method": "totp", "totp", "accessToken" }, the 6-digit authenticator code plus the inviter’s Cognito access token (which must belong to the inviter).
See Invite a customer for the full flow.
SituationResult
Complete passkey or TOTP confirmationVerified, then the invite proceeds.
Incomplete pair (e.g. totp without accessToken)400 VALIDATION_ERROR.
No confirmation422 SCA_MISSING; no user is created.
pin (or other unsupported) method422 SCA_INVALID_METHOD.
TOTP token not belonging to the inviter401 UNAUTHORIZED.
Verification failsRequest rejected; no user is created.

​
Per-resource access grants

Fine-grained grants let an invited customer use a specific account and/or card:
  • POST …/accesses — { "customerId", "accountId", "cardId"?, "accountAccess"?, "cardAccess"? }; at least one access flag, and cardId is required with cardAccess.
  • PATCH …/accesses — same shape, toggles existing grants.