Conventions

Amounts are integers, always

Every monetary value in this API, request or response, is a whole number of the chain's smallest unit, carried as a JSON string.

They are strings because they do not fit in a JavaScript number, and integers because the alternative is worse.

For anything user-facing you will want USD. GET /prices returns the current USD price of each chain's native token, and you do the conversion on your side.

curl -X GET "https://example.com/prices"

{  "base": 0,  "bsc": 0,  "ethereum": 0,  "robinhood": 0,  "solana": 0}

Chains

solana, ethereum, base, bsc, robinhood. Solana runs on SVM semantics, the other four on EVM. Where the behaviour differs, which is mostly around funding, the page in question says so.

A chain identifier is always lowercase. An unknown one comes back as 400 bad_request with the offending value quoted.

Timestamps

RFC 3339, UTC, as strings: "2026-02-14T09:31:07Z". The one exception is gap_with on the catalog, which takes Unix epoch seconds because it is a comma-separated list and readability lost that argument.

Pagination

Two schemes, and which one you get depends on how the underlying list behaves.

Cursor paging on /catalog and /wallets, where rows move under you. Ask for a page, get back items and a next_cursor, then pass that cursor to get the page strictly after it. A null cursor means you have reached the end. The cursor is opaque, so do not build one yourself.

GET /catalog?chain=solana&count=50
GET /catalog?chain=solana&count=50&cursor=<next_cursor from the previous page>

Offset paging on /quotes, /purchases, /quotes/abandoned and /funding/plans, which are your own records and hold still. limit and offset, both clamped server-side.

Errors

Every failure uses the same envelope:

{
  "error": {
    "code": "conflict",
    "message": "insufficient inventory: requested 50, available 31"
  }
}

404 deserves a note. Scoping happens before existence, so a quote belonging to another organisation is reported as not found rather than forbidden. Telling you it exists would already be telling you something.

The 2FA variant

Some sensitive actions answer 401 with an extra X-2FA-Required response header and a richer body:

{
  "error": {
    "code": "two_fa_required",
    "message": "two-factor code required",
    "challenge_id": "…",
    "method": "email",
    "label": "…",
    "sent_to": "o…r@example.com"
  }
}

It shares a status code with "your session is gone", which is why the header is there. Check it before you tear down the session. On the organisation surface this only shows up for accounts that have enrolled a second factor.

Idempotency and retries

There is no Idempotency-Key header. Where repeating a call would be dangerous, the endpoint is idempotent by construction instead:

• GET /quote/{id}/keys returns the same keys however many times you ask.
• POST /funding/plans/{plan_id}/start reports the current state rather than starting a second time.
• Settlement is driven by the on-chain balance, so paying and then calling POST /quote/{id}/settle twice settles once.

Where it would not be dangerous but also not free, as with POST /quote and POST /funding/plans, a retry creates a second record. Reconcile with GET /quotes or GET /funding/plans rather than blindly re-sending.