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

Create a production key with Pro permissions in the developer dashboard. Use https://api.daya.co/pro/v1 and send the key in X-Api-Key. The key owner must have a linked, active Pro account. Creating a key does not provision that account. A shared dashboard key can access Pro only when it has the Pro grant. Business permissions alone do not grant Pro access, and Business funds are not automatically spendable in Pro. New dashboard keys currently offer Pro Read, Trade, and Write, but not withdrawals. Manage Pro webhooks from the dashboard’s Pro workspace. Existing Pro-specific keys continue to use https://api.pro.daya.co/public/v1. New-key use on those existing endpoints requires separate rollout and support-enabled developer access. See Authentication for the correct key and URL pairing. Both paths use live balances and real money. Pro has no partner sandbox. Confirm account setup and enabled funding and withdrawal rails with Daya before launch.

​
Start here

​
Verified public contract

The table below describes the existing-key contract at https://api.pro.daya.co/public/v1. The new-key path supports the listed market, account, order, and withdrawal-option reads, plus trading. It does not expose webhook management, and new dashboard keys do not support withdrawal creation. 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. For the existing-key contract, 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. For new dashboard keys, follow the dashboard webhook setup steps to register an endpoint, save its signing secret, and inspect deliveries in the Pro workspace; do not call /pro/v1/webhooks. 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

New dashboard keys do not currently support Pro withdrawals. For existing Pro keys, withdrawals require 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 matching key and base URL from Authentication.
  • 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.