Platform overview
The Ark Platform is the client-facing API at the centre of the Ark ecosystem. It presents a single, uniform Ark contract over many backing banking and identity providers: you authenticate once, work against one set of Ark resources, and the platform selects and talks to the right provider behind the scenes. You never call a provider directly or choose one per request.
The platform is deliberately thin over those providers. For most domains it keeps no copy of the provider's data — it holds only the references it needs to keep each Ark resource pointing at the provider that owns it. The data it does own is tenant-facing reference data: parties, your client and brand records, product-catalogue entries, and notification templates and allow-lists.
Your requests are scoped to a client / brand
Ark is multi-tenant. Every request runs in the tenant carried by your bearer token — a client and brand. That scope is implicit and enforced on every call: you only ever see and act on resources that belong to your client/brand, and a party or resource from another tenant is not visible to you (it reads as not-found). You never pass a client or brand id in the body to widen that scope — it comes from your credentials.
How requests are routed
For each capability (say "create a party" or "make a payment"), the platform routes your request to the provider configured for your client/brand. Which provider serves a given capability is operational configuration, not something you select or see — your request and response are always in the uniform Ark shape regardless of which provider fulfils it. If no provider is configured for a capability your tenant calls, the request fails with a clear error rather than guessing. Operators manage that configuration through the admin surface (below).
What you can do
Each domain exposes a group of routes under the global /v1 prefix. Resources with a journey over
time link to their lifecycle; how to call each route is in
endpoints.
| Domain | Routes | Resource journey |
|---|---|---|
| Parties | /v1/parties/* | Parties (PROSPECT → ACTIVE → TERMINATED) |
| Identity verification | /v1/parties/kyx* | KYX — a verification session, independent of party status |
| Accounts | /v1/accounts/* | Account — open, signatories, transactions |
| Cards | /v1/cards/* | Card (issue → provision → ACTIVE ↔ LOCKED → CANCELED) |
| Payments | /v1/payments/* | Payment — validate then initiate; scheduled payments |
| Payees | /v1/payees/* | — |
| Scheduled payments | /v1/parties/scheduled* | Payment |
| Statements | /v1/parties/statements* | — |
| Notifications | /v1/notifications/* | Notification |
| Banking products | /v1/banking/products | — |
| Address | /v1/address/* | — |
Operator / admin surface
A separate set of operator routes under /v1/admin/* configures the instance — they are called
by back-office tooling, not by an end-customer integration, but they are part of the platform's API.
Through them an operator sets up and maintains the tenant configuration that the customer-facing
routes above depend on:
| Operator capability | What it manages |
|---|---|
| Clients & brands | register and update the tenant client/brand records |
| Products | the product catalogue and per-client/brand product mappings |
| External applications | OAuth2 client-credential applications and which clients/brands they may access |
| Routing policies | which backing provider serves each capability for a client/brand |
| Configuration | the business-rule (BRE) definitions used for rule-driven decisions |
| Domain-object mapping | links existing customer/account/card records to their provider data when onboarding into Ark |
See endpoints → admin for how to call these.
How callers authenticate
Every route requires a bearer token (a B2B JWT) issued for your tenant; most resource routes also require an active party context, and the operator routes require operator credentials. The exact requirements per route are noted in endpoints.