curl --request POST \
--url https://api.next.orenda.finance/v1/access-management/invite/customer \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--header 'x-program-id: <api-key>' \
--data '
{
"email": "grace.hopper@example.com",
"confirmation": {
"method": "totp",
"totp": "123456",
"accessToken": "eyJraWQiOiJ...inviter-access-token"
}
}
'{
"success": true,
"data": {
"message": "Customer invitation processed successfully"
}
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}Invite a customer
Creates an invited customer from the back-office.
Send email plus a step-up confirmation. A back-office invite either onboards a plain customer (just email) or a sub-role member by setting a flag (isPrepaidCardCustomer / isCardOnly / isSpouse / isChild).
Funding parent account: sub-role invitees are onboarded as pseudo accounts funded from a real parent account, so whenever a sub-role flag is set, accountId is required and names that parent. It is validated before the user is created (must exist, be ACTIVE, and not be a pseudo account, and be reachable by the caller — in the operator’s program, and for a custodian operator, under the inviting custodian). Two 400s can result: Invalid request body when a sub-role flag is set without accountId (schema), and VALIDATION_ERROR when the account is not found / inactive / pseudo / not reachable (resolver).
Pay-in IBAN: when the resolved onboarding role enables pay-in (isPayInEnabled), payInIBAN is required (omitting it returns 400); for roles without pay-in it is ignored.
Step-up authentication: the request must include a confirmation object — either { method: "passkey", passkeySession, assertion } or { method: "totp", totp, accessToken } — on every invite, back-office included (except the step-up-exempt sessions noted below). Missing confirmation → 422 SCA_MISSING; an incomplete pair → 400; an unsupported method (e.g. pin) → 422 SCA_INVALID_METHOD. For TOTP, the access token must belong to the acting inviter, else 401.
SSO programs: for programs that authenticate via an external client reference (program config usesClientRefAuthentication: true, e.g. potjestaging), no Cognito user is created; instead clientReference is required and becomes the application identity. SSO callers are step-up exempt, so no confirmation is needed on that path.
Machine-to-machine (M2M) callers: server-to-server integrations authenticated via api-control (client-credentials) have no human to satisfy a passkey/TOTP challenge, so they are step-up exempt too — no confirmation is required, and any step-up fields sent are ignored.
Consumers inviting their own sub-users use the same route on the customer API; see the customer API reference.
curl --request POST \
--url https://api.next.orenda.finance/v1/access-management/invite/customer \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--header 'x-program-id: <api-key>' \
--data '
{
"email": "grace.hopper@example.com",
"confirmation": {
"method": "totp",
"totp": "123456",
"accessToken": "eyJraWQiOiJ...inviter-access-token"
}
}
'{
"success": true,
"data": {
"message": "Customer invitation processed successfully"
}
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}{
"success": false,
"code": "<string>",
"message": "<string>"
}Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
The program the request acts on.
Body
Sent by a back-office caller. Includes a confirmation step-up object — back-office invites are challenged like any other. A plain invite needs only email; setting a sub-role flag (isPrepaidCardCustomer / isCardOnly / isSpouse / isChild) makes accountId required and names the funding parent account the invitee draws against. Sub-roles are mutually exclusive — set at most one flag (zero = plain customer); two or more returns 400.
Discriminated step-up (SCA) credential. passkey and totp are accepted on this endpoint (a pin confirmation is rejected with 422 SCA_INVALID_METHOD).
- Passkey
- TOTP
Show child attributes
Show child attributes
Pay-in IBAN assigned to the invitee. Required when the resolved onboarding role enables pay-in (isPayInEnabled); ignored for roles without pay-in.
External identity reference (max 36 chars). Required only for SSO programs (program config usesClientRefAuthentication: true, e.g. potjestaging) — there it becomes the application identity and is rejected with 400 if missing. Ignored for normal Cognito programs.
36Funding parent account the invitee draws against. Required when any sub-role flag is set. Validated up front: must exist, be ACTIVE, not be a pseudo account, and be reachable by the caller (in the caller's program; for custodians, under the inviting custodian).