Add a staff member to an onboarding case

POST 
/v1/onboarding-cases/:case_id/staff-members

Declares a person to be provisioned in the platform IAM when onboarding is activated. The member is created in state READY; nothing is provisioned until activation.

Required scope: connector:staff:write.

Allowed states: AWAITING_BANK_ADMIN, BANK_CONFIGURING, NEEDS_CHANGES (otherwise 409). The first edit moves AWAITING_BANK_ADMIN to BANK_CONFIGURING.

Fields (all in data.attributes):

• email (required): the member's email address. It is trimmed and stored in lower case, must contain @ and a domain with a dot (otherwise 422), and must be unique within the case (otherwise 409). The same value is used as the member's sign-in subject at the federated identity provider.
• roles (required, at least one, unique): preset labels bank-admin, maker, checker, readonly. Labels describe the member's function and may be combined (for example maker and checker); they do not grant any API permission. At least one member of the case must have bank-admin before you can submit.
• scopes (required, at least one, unique): the member's API permissions. They are the only source of authorisation for the member's calls. Allowed values are the scopes assignable to M2M workloads (listed on PUT /v1/onboarding-cases/{case_id}/m2m-clients) plus connector:m2m-clients:read. Operator, onboarding (connector:onboarding:*), staff administration (connector:staff:*) and unknown scopes return 422.

The order of roles and scopes in responses is not significant. Staff members do not hold signing keys in the platform.

Onboarding administrator. The onboarding administrator (admin_contact on the case) is not a staff member, and their onboarding access is removed when the case is activated. Add them here as well if they need access after activation.

Provisioning outcome. When the case is activated, every staff member receives a bank membership with their roles and scopes in the platform IAM. Members change to ACTIVE when the case becomes ACTIVE.

No Idempotency-Key is used. Repeating a successful request returns 409 because the email is already on the case.

Request

Responses

201

Staff member created in state READY.

409

The request conflicts with an earlier request or with the current state of the target: an Idempotency-Key reused with a different body (IDEMPOTENCY_CONFLICT), a request with the same key still in progress (IDEMPOTENCY_PENDING), or a target resource in a state that does not allow the request (STATE_CONFLICT).

422

The request is well-formed JSON but cannot be processed: the body does not match the expected shape (a missing or unknown member, a wrong type, or a wrong data.type), or it breaks a business or cross-field rule. Correct the request before retrying.