Skip to main content
This reference is generated from the Rach CaaS OpenAPI specification. CaaS is a separate product with its own base URL and keys — see the CaaS overview for the product model, and Idempotency & settlement before you go live. The embedded escrow has a separate custodial model and pilot requirements. Its presence in this reference does not confirm deployed production availability, country eligibility or managed compliance.

​
Base URL

​
Authentication

Every B2B endpoint uses your CaaS API key in the X-API-Key header, prefixed rach_sk_live_ / rach_sk_test_.
CaaS keys are separate from your Payments keys and are not interchangeable. See Get your API keys.
Test keys simulate supported mutations without on-chain execution. Account test mode also overrides a live key. Reads pass to their normal handlers rather than a separate persistent sandbox. See environment behavior, especially before trying to poll a simulated escrow ID.

​
Conventions

Amounts are strings. Money is never a JSON number — binary floating point cannot represent decimal money exactly. Send "10.50", not 10.5. Stablecoin amounts carry up to six decimal places, fiat up to two. Escrow has an explicit unit exception: its create request uses whole tokens, while live responses/webhook snapshots return integer base units. For TRON USDT, "25000000" in a response means 25 USDT. Money-moving calls return 202, not 200. The request is durably recorded, not completed. See Idempotency & settlement for how to get the outcome. Phone numbers are E.164 — +2348010000001, with the + and country code. On transfers, sender_phone and recipient_phone also accept a 0x wallet address; the format is auto-detected. Always send an idempotency key. It is what makes a retry safe. Reuse the same value when retrying — a new value is a new payment. Escrow creation uses its tenant-scoped reference for idempotency; it has no separate idempotency_key. Escrow actions do not accept idempotency keys. Read persisted state after an uncertain result or a conflict before taking further action.

​
Errors

Errors return a JSON body with an error field describing what went wrong.
402 means your ledger is short, not the customer’s. Funding a customer always draws from your pre-funded balance, so this is a signal to top up your treasury — not to tell the customer they have insufficient funds. The response includes the requested amount and the top-up endpoint.
429 is not rate limiting. It means the customer has exceeded their daily or monthly AML transaction limit. Backing off and retrying will not help — the limit resets on its own schedule, and the customer needs a higher limit or has to wait. The error field says which limit was hit.