Skip to main content

​
What you are integrating

Pro is Daya’s USD/NGN order-book trading product. It is not the Coins token-swap API or the Stocks instrument API. USDT and USDC deposits are accounted for in the unified USD balance. For quotes, orders, order books, and filters, use the exact active market symbol returned by GET /markets. The current service market is USD-NGN. Your Pro orders and balances belong to the provisioned Pro account. If your product serves many customers, keep a customer-level ledger in your own system. Map each Pro deposit, order, trade, and withdrawal to the customer whose funds you manage. Pro does not turn one account balance into separate customer balances.
Business, Coins, Stocks, and Pro balances are separate. A deposit to a Business funding account does not automatically fund Pro. Confirm the supported funding route for your Pro account with Daya before showing it to customers.

​
Confirm your access

Ask Daya to provision a Pro account and API key before you implement money movement. The current public Pro contract uses this base URL:
This is a production endpoint with live balances and real money. The current public contract does not define a Pro sandbox. Validate with a small, controlled live amount and confirm enabled funding and withdrawal rails with Daya before launch. Use the Pro-specific daya_sk_ key in the X-Api-Key header. The current endpoint reference and quickstart describe this contract. A Business API key does not authenticate to Pro, and Business funds are not automatically spendable in Pro. Ask Daya to confirm the account, scopes, and available funding and withdrawal rails in writing.

​
Start here

​
Verified public contract

The Pro service mounts these actions under https://api.pro.daya.co/public/v1: Write and Withdraw do not grant Read. Use separate least-privilege keys when trading, treasury movement, and webhook administration run in different systems.

​
Safe order and funding behavior

POST /orders/quote needs Read scope. It previews an order; it does not reserve funds or guarantee execution. POST /orders needs Trade scope. Check the current balance and order book, then submit only after the customer confirms. Use the exact market symbol returned by GET /markets. Save one client_order_id for each logical order. Reuse it after a request timeout and query the order before creating another one. If you include client_order_id when quoting a limit order, send the same value on the order because it can affect self-trade handling. Send the quote’s estimated_fee unchanged as max_taker_fee; this authorizes the maximum cumulative taker fee, while the service charges the realized fee. Order status has the following meaning: Pro can report order.created, order.partially_filled, order.filled, order.cancelled, order.rejected, and trade.executed webhook events. The order resource can also reach the terminal failed status, but Pro does not send an order.failed webhook. Poll GET /orders/{id} until the order is filled, cancelled, rejected, or failed. Credit or debit your customer ledger from the actual fills, not just from order acceptance. Create and manage the HTTPS webhook with the /webhooks endpoints and a key with Write scope. Store the secret returned at creation, verify every signature, and deduplicate by event_id. Use GET /webhooks/{id}/deliveries to inspect delivery attempts. Poll orders and reconcile if delivery is delayed. See Pro webhooks. Treat crypto and NGN bank deposits as separate recovery flows. For crypto, GET /deposits/addresses returns existing account-level addresses; it does not provision a new address, create a customer-owned wallet, or return deposit status. Subscribe to the signed crypto.deposit.completed webhook and credit the customer only after that event. The public API does not provide a crypto-deposit lookup. If the event is delayed, review the webhook delivery log when available, compare the aggregate Pro balance, and contact Daya with the transaction hash. Do not credit one customer from the aggregate balance alone. For NGN bank funding, use the signed deposit.completed webhook. Use GET /deposits/completed for backfill and reconciliation. That endpoint contains completed NGN bank transfers only; it does not contain crypto deposits. For both rails, an account-level address or bank instruction alone does not identify which customer sent funds. Attribute the deposit through a method you can reconcile before posting it to your customer ledger. A supported chain in another Daya product does not imply that Pro accepts deposits on that chain.

​
Withdrawals and launch checks

Withdrawals are a separate money-movement permission and can be disabled even when trading works. Confirm the enabled bank and onchain options, limits, fees, and required withdrawal scope with Daya. Do not rely on a Trade key alone for withdrawal access. A withdrawal request needs its own stable idempotency_key in the request body. If the request times out before it returns a transaction ID, replay the exact request with the same idempotency_key. The API returns the original result without creating a second withdrawal. Do not use a new key for that retry. Before launch, test that you can:
  • Authenticate with the assigned Pro key at https://api.pro.daya.co/public/v1.
  • Receive and reconcile a real deposit into the Pro account without mixing customer allocations.
  • Place a small order, handle a partial fill, and reconcile the final trades and fees.
  • Recover from an order timeout and a duplicate or delayed webhook.
  • Confirm withdrawal and funding availability for the account instead of assuming every documented rail is enabled.
For support, send the base URL, endpoint, request ID, Pro order or transaction ID, client_order_id, timestamp, symbol, and a redacted request. Never send an API key, webhook secret, or full customer KYC record.