Skip to main content
This quickstart provisions your first OMS custodial wallet through the API. You authenticate, create a customer to own the wallet, provision the wallet, and read its balance. OMS holds the keys, so there is no wallet SDK and no user signing.
Custodial wallets are in early access and require an OMS API key. Request access if you do not have one yet.
1

Get a bearer token

You do not send the API key directly on requests. Exchange the key and secret for a short-lived bearer token at POST /auth/token, then send that token as Authorization: Bearer {accessToken} on every other call.
The token is valid for 60 minutes. When a request returns 401, exchange your key for a fresh token and retry. If POST /auth/token returns 429, the endpoint is rate-limited: back off before retrying.
2

Create a customer

Every custodial wallet belongs to a customer record. Create one before provisioning a wallet. Only type is required; when you omit endorsements, OMS defaults to cryptoCustody and usd (which auto-includes basic). If you also plan to fund the wallet with fiat (the next-step cash or card flows), include the full set of identifying fields so the customer can be provisioned to move money, not just a name.
Store the cst_ ID. You pass it in the path when provisioning the wallet. PII fields (birthDate, residentialAddress, ipAddress, identifyingInformation) are write-only: OMS accepts them but never returns them. Only individual is supported for type today. Endorsement statuses use SCREAMING_CASE (INACTIVE, PENDING, ISSUES, ACTIVE, REJECTED, REVOKED_ISSUES, OFFBOARDED).
A custodial wallet can be created for a name-only customer, but that customer cannot be provisioned to move fiat. If you later fund the wallet with a fiat-to-crypto flow, those calls fail because the customer is not provisioned for fiat. For USD and cash flows, provide a structured residentialAddress, phone (E.164), birthDate, and a government ID in identifyingInformation (for US customers, an ssn or itin) at creation, or add them later with PATCH /customers/{customerId}.
In sandbox, endorsements are auto-approved so you can provision and use wallets without a live KYC integration. Provisioning still reads the identifying fields above, so include them in sandbox too.
3

Provision a custodial wallet

Create the wallet with POST /customers/{customerId}/wallets. The customer ID goes in the path, and the body names the asset the wallet holds and the chain it lives on. OMS derives the on-chain address and manages the keys.
The address is the wallet’s on-chain Polygon address. The wlt_ ID is what you reference as a source or destination in quotes and transactions. A custodial wallet is internal (OMS-managed) with a status of active. List a customer’s wallets any time with GET /customers/{customerId}/wallets.
4

Read the wallet balance

Read a wallet’s current balance any time with GET /wallets/{walletId}/balance.
A freshly provisioned wallet starts at zero. Fund it with a fiat-to-crypto flow, then poll this endpoint or subscribe to transaction webhooks to track the balance.

What’s next

Custodial wallets overview

When to use custodial wallets and how OMS secures keys.

Create a wallet (API reference)

Full request and response reference for POST /customers/{customerId}/wallets.

Fund a wallet

Bring fiat into the wallet with the cash-in or virtual account flows.

Get started with OMS

The end-to-end payments walkthrough, from customer to first transaction.