Skip to main content

List the calling bank's onboarding cases

GET 

/v1/onboarding-cases

Returns the onboarding case of the calling bank. An onboarding case is the record the platform operator opens to bring a bank onto the network; the bank's onboarding administrator then completes it through the /v1/onboarding-cases/{case_id}/... endpoints. Use this operation to discover the case_id you work with.

Required scope: connector:onboarding:read. The bank is taken from the bank_memberships claim of your access token; you never pass a bank_id. The platform allows at most one onboarding case per bank, so the list contains zero or one entry.

Order: newest first (by created_at, then id). The list is not paginated.

Each entry includes readiness (a checklist of what is still missing before you can submit). The list omits bank_portal_route_code; read the single case with GET /v1/onboarding-cases/{case_id} to get it. Reading the single case also refreshes the case state from its activation operation, so poll the single case, not this list, while the case is being approved and provisioned.

Onboarding administrator workflow (summary). The case states that allow bank edits are AWAITING_BANK_ADMIN, BANK_CONFIGURING and NEEDS_CHANGES (the case is editable). Your first successful edit moves an AWAITING_BANK_ADMIN case to BANK_CONFIGURING.

  1. Read the key catalogue: GET .../key-requirements.
  2. Provide the three signing keys (BANK_ADMIN, CREATE_INTERBANK_TRANSFER_MAKER, APPROVE_INTERBANK_TRANSFER_CHECKER) and the key-encryption key (ENCRYPT_TRANSFER_SOURCE_MESSAGE), either by registering your own (POST .../signing-targets, POST .../encryption-targets, then POST .../verify on each) or by letting the platform generate them in your cloud account (POST .../key-generation-jobs). Every key must end in verification_state VERIFIED.
  3. Add staff: POST .../staff-members. At least one member must carry the bank-admin role label.
  4. Configure webhook delivery: PUT .../webhook-setup. It must subscribe to beneficiary.screening.requested and have a signing secret.
  5. Optionally declare machine-to-machine workloads: PUT .../m2m-clients.
  6. Submit: POST .../submit-configuration. The case moves to READY_FOR_REVIEW and is no longer editable.

After you submit, the platform operator accepts the case, which starts an activation operation (activation_operation_id) and moves the case to AWAITING_APPROVALS. Once the required approvals are given the case moves to PROVISIONING and then ACTIVE, when your staff and workloads are provisioned in the platform IAM. A case whose activation is rejected, cancelled or expires moves to REJECTED; one whose activation fails moves to FAILED. NEEDS_CHANGES makes the case editable again.

Responses​

The calling bank's onboarding cases, newest first. An empty data array means no case has been opened for your bank.