Skip to main content

DAI API Documentation

This API lets a merchant hold balances on behalf of its own customers: credit incoming crypto transfers, pay out to external addresses, settle between customers, and trade — all against one integration token.

Everything an integration does happens through the calls documented here: opening a customer, issuing an address, placing an order, sending a payout.

A dashboard is available alongside the API for transaction history, reports and exports.

All requests go to https://api.example.com, and every path carries the /api prefix.

Quick Overview​

  • Members and accounts — open a customer, get an account per asset, read balances
  • Deposit addresses — issue an address per customer and network, optionally with an expiry
  • Auto-conversion — have whatever arrives on an address swapped into a chosen asset automatically
  • Withdrawals — quote the fee, then pay a customer's balance out to an external address
  • Transfers — move balance between two customers of the same owner
  • Trading — place market and limit orders for a customer, cancel them, and read the fills
  • Webhooks — register endpoints to be notified of deposits, withdrawals, orders, trades and market changes
  • Service — a public health check

Getting Your API Token​

API tokens are issued manually — you receive yours rather than generating it.

  1. Store it server-side — it has full access to your account, payouts included
  2. Send it in the Api-Token header on every request except /api/health
GET/api/assets
curl 'https://api.example.com/api/assets' \
  -H 'Api-Token: YOUR_API_TOKEN'

The catalogue you get back is the merchant's own: the fee fields on List Assets are resolved for your fee group.

Authentication covers the rest: what a token does and does not allow, and what to do when one is rejected.

Your First Four Calls​

A working integration is reachable in four requests:

INTEGRATION SEQUENCE
# 1 — what can I accept, and on which networks?
GET  /api/assets

# 2 — open a customer (takes no body)
POST /api/members
     → { "id": 9670, "accounts": [ ... ] }

# 3 — give that customer an address to be paid at
#     account_id: the account from step 2 whose asset this network carries
POST /api/accounts/{account_id}/deposit_addresses
     { "dchain_id": "trc20usdt" }

# 4 — read what arrived, for the member from step 2
GET  /api/deposits?member_id=9670

Creating a member also opens one account per asset, and they come back in the same response — take the id of the account in the currency you want to be paid in. Pick one whose asset the network in step 3 carries, or the call is refused with 1001. Both creates answer 201, not 200.

Next Steps​

  • How It Works — the end-to-end money lifecycle
  • API Conventions — POST answers 201, lists are paginated envelopes with a few exceptions, amounts are strings, and how to make a retry safe
  • Authentication — what the token allows, and the one endpoint that needs none
  • Errors — the response format and every code, with the ones worth retrying
  • Create Withdrawal — the most consequential call in the API