> ## Documentation Index > Fetch the complete documentation index at: https://docs.daya.co/llms.txt > Use this file to discover all available pages before exploring further. # Partner Integration > Set up Pro trading, funding, order tracking, and reconciliation for your product ## 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: ```text theme={"dark"} https://api.pro.daya.co/public/v1 ``` 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](/pro/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 | Step | What to do | Detail | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Provision access | Request a Pro account and server-side key. Ask for read and trade access; request withdrawal access only if needed. | [Pro authentication](/pro/authentication) | | 2. Set up your ledger | Assign an internal customer and operation ID to each funding and trading action. Keep a separate Pro cash and order allocation per customer. | The Pro balance endpoint is an account total, not a customer balance. | | 3. Check funding | For crypto, use only an address returned for the exact asset and chain, then wait for `crypto.deposit.completed`. For NGN bank funding, wait for `deposit.completed` or reconcile with `GET /deposits/completed`. | [Deposit addresses](/pro/api-reference/list-crypto-deposit-addresses) and [completed bank deposits](/pro/api-reference/list-completed-deposits) | | 4. Check cash and market | Read balances, the market, and the order book before offering a trade. | [Balances](/pro/api-reference/get-balances) and [Markets](/pro/api-reference/list-markets) | | 5. Review and place an order | Request an order quote, show the estimated price and fee, then place a market or limit order. Save one `client_order_id` per logical order. | [Order quote](/pro/api-reference/get-order-quote) and [Place order](/pro/api-reference/place-order) | | 6. Track execution | Treat an accepted limit order as open until it fills, cancels, rejects, or fails. A partial fill changes cash and quantity before the order is final. | [Order](/pro/api-reference/get-order) and [Order trades](/pro/api-reference/list-order-trades) | | 7. Reconcile | Deduplicate signed webhook events. Reconcile customer allocations with account balances, orders, trades, confirmed crypto deposits, and completed NGN bank deposits. | [Pro webhooks](/pro/webhooks/overview) | ## Verified public contract The Pro service mounts these actions under `https://api.pro.daya.co/public/v1`: | Action | Representative routes | Authentication | | -------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------- | | Read public market data | `GET /markets`, `GET /orderbook/{symbol}`, `GET /market-trades/{symbol}`, `GET /last-price/{symbol}` | No API key | | Read account data and preview an order | `GET /account`, `GET /balances`, `GET /orders`, `GET /trades`, `POST /orders/quote` | Read scope | | Place, replace, or cancel an order | `POST /orders`, `PUT /orders/{id}`, `DELETE /orders/{id}` | Trade scope; Trade also grants Read | | Read withdrawal options | `GET /withdrawals/onchain/options`, `GET /withdrawals/bank/banks` | Read, Trade, or Withdraw scope | | Create a bank or onchain withdrawal | `POST /withdrawals/bank`, `POST /withdrawals/onchain` | Withdraw scope | | Manage webhooks and inspect deliveries | `/webhooks` routes | Write scope | 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: | Status | Meaning | Terminal? | | -------------------- | ---------------------------------------------------------------- | --------- | | `new` | The order has been admitted but is not yet resting or completed. | No | | `open` | The order is resting on the book. | No | | `partially_filled` | Some quantity executed; the remaining quantity is still active. | No | | `pending_settlement` | Execution occurred and settlement is still being finalized. | No | | `filled` | The full order completed. | Yes | | `cancelled` | The remaining quantity was cancelled. | Yes | | `rejected` | The order was not accepted for execution. | Yes | | `failed` | Processing failed. | Yes | 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](/pro/webhooks/overview). 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.