POST
Invites either a sub-user under your account — a prepaid-card member, child, spouse, or card-only member — or, if you are a company, a corporate manager who operates your corporate. Send Authorization: Bearer <id_token>, the invitee’s details, exactly one application flag, and a step-up confirmation. The program comes from your ID token, so — unlike the auth endpoints — this call needs no x-program-id header.
Consumers can only invite a sub-role member or a corporate manager, never a plain customer — exactly one application flag must be set. A sub-user is a pseudo account funded from one of your own accounts; a corporate manager is not funded at all (see Corporate manager).
Self-service invites aren’t available on programs that authenticate via an external identity provider; those invites are created by your operator instead. Such a request returns 400 "This program does not support consumer self-service invites".

​
Application flags

Set exactly one of these to choose what you’re inviting — they are mutually exclusive, so setting zero or more than one returns 400: The first four are sub-roles. isCorporateManager is not a sub-role and cannot be combined with one.
isCompany is not accepted alongside any of these — a sub-user and a corporate manager are both always natural persons. A mis-cased flag (for example ischild or iscorporatemanager) is rejected with 400 rather than silently ignored.

​
Invitee details

Which of the invitee’s details you must supply depends on the invitee type: some need only email, some need the invitee’s identity (firstName, lastName, dob, nationality), and some need a full profile including address. Send what you have — if a field is required for that invitee the API responds 400 naming it. (address and phone may be inherited from your own account; see Inherited fields.)

​
Funding account (sub-roles only)

accountId (a UUID) is required when you set a sub-role flag and must be one of your own accounts — ACTIVE and not itself a pseudo account. It’s validated before the sub-user is created; if it’s missing you get 400 accountId is required when inviting a sub-role, and if it isn’t a valid, eligible account of yours you get 400 account not found or not eligible. A corporate manager is not funded from a parent account, so accountId is not used there.

​
Corporate manager

A corporate manager is a natural person who operates your corporate — for example a finance manager who needs to see the company’s accounts and order company cards. Set isCorporateManager: true and omit accountId. They complete their own individual KYC, and get no account and no card of their own. Once their onboarding completes they operate on your corporate’s resources: they see every account, card and transaction the corporate has, and cards they order are issued against your corporate — funded by the corporate’s account, embossed with the manager’s own name.
Only a corporate can invite a manager. The corporate is taken from your own application, never from the request body — there is no field for it. If your own application is not a company the request returns 400 Only a corporate customer can invite a corporate manager, and if you hold more than one company you get 400 rather than a guess at which one.A consequence worth planning around: because a manager’s own application is an individual, a manager cannot invite another manager. Only the corporate itself can.

​
The manager’s customerId changes on completion

This is the part to handle in your client. On GET /v1/applications, a corporate manager’s customerId is: Nothing else in your client needs to change. Once you read the corporate’s customerId from the manager’s application and use it in the path as you already do, accounts, cards, transactions and payments all return the corporate’s data — there is no separate “act as corporate” call and no manager-specific endpoint. applicationId always carries the manager’s own id, throughout — and on invited applications the manager’s own customerId equals it, so their personal id stays recoverable after the switch.

​
Inherited fields

Depending on the program’s onboarding configuration for the chosen role, some of the invitee’s details (such as address and phone) are inherited from your own application rather than the request body — for example a child typically inherits the parent’s address. When inheritance is enabled for a field, you can omit it from the request.

​
Step-up authentication

Every invite requires a step-up confirmation — either passkey or TOTP.
Start a challenge via POST /v1/auth/passkey/challenge, complete it on the device, then send:
Missing confirmation returns 422 SCA_MISSING and no user is created; an incomplete pair (e.g. totp without accessToken) returns 400; a pin confirmation is rejected with 422 SCA_INVALID_METHOD. For TOTP, the access token must belong to you, else 401.

Authorizations

​
Authorization
string
header
required

The user's id_token from authentication — the ID token, not the access_token. The program and environment come from the token.

Body

application/json

Sent by a signed-in customer. Exactly one application flag must be true — either a sub-role (isPrepaidCardCustomer / isCardOnly / isSpouse / isChild, mutually exclusive) or isCorporateManager. Consumers can only invite sub-role members or a corporate manager, never a plain customer.

accountId is required for a sub-role invite (it is the funding parent, and must be one of the inviter's own accounts — ACTIVE, not a pseudo account) and unused for a corporate manager, which is not parent-funded.

isCompany is not accepted alongside either: a sub-role invitee and a corporate manager are both always natural persons.

Must include a confirmation step-up object (passkey or TOTP).

​
email
string<email>
required
​
confirmation
Passkey · object
required

Discriminated step-up (SCA) credential. passkey and totp are accepted on this endpoint (a pin confirmation is rejected with 422 SCA_INVALID_METHOD).

​
firstName
string
​
lastName
string
​
dob
string

Date of birth, YYYY-MM-DD.

​
nationality
string

Alpha-2 country code, e.g. GB.

​
phone
string

E.164-style number.

​
address
object
​
accountId
string<uuid>

Funding parent account the invitee draws against. Required for a sub-role invite; must be one of the inviter's own accounts, ACTIVE, and not a pseudo account. Not used for isCorporateManager — a manager is not funded from a parent account.

​
isPrepaidCardCustomer
boolean
​
isCardOnly
boolean
​
isSpouse
boolean
​
isChild
boolean
​
isCorporateManager
boolean

Invite a corporate manager: a natural person who operates your corporate. Requires that your own application is a company. Mutually exclusive with every sub-role flag, and with isCompany. Does not use accountId.

Response

Invitation processed

​
success
boolean
Example:

true

​
data
object