Skip to main content

​
Single-object responses

The core Daya API does not use one envelope for every endpoint. Parse each operation according to its schema. These successful operations return exactly one object under data: For example, POST /v1/banks/resolve returns:
Read the resolved name from body.data.account_name, not body.account_name.

​
Flat objects

Other core single-object responses are flat. This includes customer create/get/update and verification, funding-account create/get/disable/settlement updates, quotes, transfers, deposits, virtual accounts and their deposits, bridges, liveness checks/sessions, and legacy onramps/offramps/payouts. In particular:
  • POST /v1/funding-accounts and GET /v1/funding-accounts/{id} return the funding account directly. Read body.id and body.settlement_destination.
  • GET /v1/merchant/withdrawals/{id} returns the withdrawal directly, even though POST /v1/merchant/withdrawals wraps its submission result in data.
  • The legacy POST /v1/withdrawals alias returns a flat withdrawal object. New integrations should use the documented merchant withdrawal route.
Do not add or remove data based only on HTTP method or resource name. Pro, Coins, and Stocks have separate API contracts; this list covers the core API, not those products.

​
Lists and errors

A list’s data field is an array, not a single-object envelope. For example, GET /v1/banks returns {"data": [...]}. Customer balances also use an array under data, even when only one currency is returned. Paginated lists include the pagination fields defined by their operation. Errors use {"error": {...}}. Check the HTTP status before parsing a success body. A successful DELETE /v1/recipients/{id} returns 204 No Content with no JSON body. Use the generated public schema for field definitions and each operation’s status codes.