This is the integration path for a venue market-making bot with a server-issued API key: authenticate every request with it, place and cancel orders over REST, and read the book and your own fills over the realtime WebSocket. No MCP server is required; that is an optional layer covered at the end. The introduction carries the base URLs of the venue this site is deployed on. This page does not repeat them: a second table would state one venue’s hostnames on every other venue’s site, which is exactly the drift the generated Base URLs section removes. The examples below read the REST base URL from $EDEL_API_URL and the key from $EDEL_API_KEY. Set EDEL_API_URL to the REST base URL the introduction lists.

​
1. Receive a server-issued bot key

A market-making bot does not use the agent-connect browser grant. The venue bot runtime issues its first key server side after verifying its workload identity and configured bot-to-account binding. The bot rotates that key before its seven-day expiry. These are server-only operations, not public setup steps. The bot key and an agent key are checked the same way and have the same one-account read and trade boundary. If you operate an independent automated strategy rather than the venue bot runtime, use the trading-agent browser approval flow instead. Do not imitate the bot issuance path. See the shared API key table for all principal kinds.

​
2. Authenticate every request

Send the key as a bearer on every private request:
Public market-data routes need no key. Authenticated requests are rate limited per credential (see the rate-limits section of the introduction); stream state instead of polling to stay well inside the limit. To confirm what a stored key is, read its metadata (never the secret) with GET /v1/api-keys/current:
Protect the key: it can trade this account. It can never deposit, withdraw or change the Canton Party; those stay behind the owner’s passkey session. See Authentication models for the guarantee that bounds a key.

​
3. Place and cancel orders

Placing and cancelling both need the trade scope, and both take an Idempotency-Key header: reuse the same value on every retry of one call, so a lost response never places or cancels twice. A placed order also carries a clientOrderId in its body; choose it once for the logical order and keep it stable across retries. A cancel body names only the owned account and market. Place an order with POST /v1/orders. A limit order carries orderType limit, a price and a quantity as decimal strings; side is buy or sell:
Cancel the unfilled remainder of a resting order with POST /v1/orders/:orderId/cancel. The body names the owned account and market. An exact replay with the same Idempotency-Key returns the original decision; a later cancel with a new key returns not_found:
The REST API reference has the full order request and response contracts, including market orders, reduceOnly, and attached take-profit and stop-loss (autoClose).

​
4. Stream the book and your fills over WebSockets

Live data is pushed over the WebSocket at /streams/v1/ws. Edel has no webhooks, and REST polling does not scale, so a market maker reads state from the socket.
  • Market channels are open. Connect and subscribe to market.book and market.trades (and market.ticker, market.funding, and the rest) with no credential.
  • Account channels need a ticket. Your own events arrive on account.orders, account.fills, account.positions and account.balance. Mint a short-lived, account-scoped ticket with your key (POST /v1/realtime/ticket, read scope), send it in an auth frame on the socket, and subscribe only after auth_ok arrives. The ticket, not the key, travels on the connection, so a long-lived socket never parks your key. Rotate the ticket and authenticate the same socket again before expiresAt; the socket authentication flow shows every frame.
See the WebSockets tab for the subscribe frame and the payload of each channel.

​
Rate and risk limits

By default a venue allows 600 authenticated requests per 60 seconds for each API key. The window starts with your first request and resets 60 seconds later; it does not roll. Minting a realtime ticket counts against the same budget. A venue can set a different limit; a staging or production venue never allows more than 6,000 per window. A request over the limit is refused before the API acts on it, with 429 and this envelope:
The response has no Retry-After header. Wait for your window to reset, at most 60 seconds, then send the same request again with the same Idempotency-Key and clientOrderId. A rate-limit refusal is never permission to retry an order with a new identity. Stream state over WebSockets instead of polling REST; polling is the most common way a client reaches the limit. Every order still passes the venue’s pre-trade risk checks, market bounds, margin and account readiness rules. A valid key is not evidence that an order was accepted, journaled or settled. Preserve clientOrderId and Idempotency-Key across an uncertain response. Do not infer a fill from a successful HTTP response. The bot runtime also applies its own configuration and fleet limits, which may be stricter than the public REST quota.

​
Optional: the MCP server

An AI agent can reach the venue through the Edel Model Context Protocol server, which authenticates with an owner-approved agent API key and exposes trading tools. It is optional. A market maker does not need it: the REST and WebSocket path above is the complete integration. Reach for the MCP server only when you want an LLM-driven agent to hold the tools directly.

​
Renew and revoke

A bot key expires after seven days and the venue bot runtime rotates it before then. An independent agent key expires after 24 hours by default and needs a new owner-approved device grant. A refused key cannot trade; stop and follow the issuance path for its principal kind. See Authentication models for the full lifecycle and the security guardrail that bounds a key to reading and trading.

​
Shared reference

Use the REST API reference for request and response contracts, and WebSockets, not REST polling, for live data.