Market maker quickstart - Edel Developer Docs

This is the shortest path for a market maker or an automated strategy: get an owner-approved 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. Get a key with the device grant

An API key is issued through the agent-connect device grant (the RFC 8628 shape). The program starts the grant, a human approves it once in the browser, and the program collects the key. All three routes are public; the key is the credential every step after this uses.

Start the grant

Call POST /v1/agent-connect/start with a client name and the scopes you need. No credential is required yet.

curl --fail-with-body --silent --request POST "$EDEL_API_URL/v1/agent-connect/start" \
  --header "content-type: application/json" \
  --data '{"clientName":"acme-market-maker","scopes":["read","trade"]}'

The response carries the codes and the poll schedule:

{
  "version": "agent-connect-start/v1",
  "connectCode": "<opaque connect code, keep private>",
  "userCode": "BCDF-GHJK",
  "verificationUrl": "<this venue's approval page>/connect-agent?code=BCDF-GHJK&scopes=read,trade&client=acme-market-maker",
  "expiresInSeconds": 600,
  "intervalSeconds": 5,
  "scopes": ["read", "trade"],
  "keyLifetimeSeconds": 86400
}

Have the owner approve it

Show the owner verificationUrl and userCode. The owner opens the page (the Demo /connect-agent page), signs in with a passkey, checks that the code and scopes match what you asked for, and approves. Approval is a passkey call to POST /v1/accounts/:accountId/agent-connect/approve; the owner makes it in the browser, not you. An approval can never grant more than the page showed.

Collect the key

Poll POST /v1/agent-connect/complete with your connectCode every intervalSeconds. Start polling right after step 1, because the owner may approve before you show the code again.

curl --fail-with-body --silent --request POST "$EDEL_API_URL/v1/agent-connect/complete" \
  --header "content-type: application/json" \
  --data '{"connectCode":"<connect code from step 1>"}'

The poll answers one of four states:

`status`	Meaning	What to do
`authorization_pending`	The owner has not approved yet.	Keep polling at the interval.
`slow_down`	You polled faster than the interval.	Add five seconds to your interval, then continue.
`expired`	The grant timed out (ten minutes) or the key was already collected.	Start a new grant.
`approved`	The owner approved.	Read the key, once.

The approved answer returns the key exactly once:

{
  "version": "agent-connect-complete/v1",
  "status": "approved",
  "apiKey": "edel_ak_...",
  "key": {
    "keyId": "8f2b1c9a-...",
    "accountId": "your-account-id",
    "scopes": ["read", "trade"],
    "state": "active",
    "expiresAtEpochMs": 1700000000000
  }
}

Store apiKey in a private file only your process can read. It is never returned again. Never put it in a command-line argument, a log line or a chat message.

2. Authenticate every request

Send the key as a bearer on every private request:

curl --fail-with-body --silent "$EDEL_API_URL/v1/accounts/$ACCOUNT_ID" \
  --header "Authorization: Bearer $EDEL_API_KEY"

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:

curl --fail-with-body --silent "$EDEL_API_URL/v1/api-keys/current" \
  --header "Authorization: Bearer $EDEL_API_KEY"

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:

curl --fail-with-body --silent --request POST "$EDEL_API_URL/v1/orders" \
  --header "Authorization: Bearer $EDEL_API_KEY" \
  --header "content-type: application/json" \
  --header "Idempotency-Key: $ORDER_ATTEMPT_ID" \
  --data '{
    "accountId": "your-account-id",
    "marketId": "BTC-USD-PERP",
    "clientOrderId": "acme-000123",
    "side": "buy",
    "orderType": "limit",
    "price": "65000.0",
    "quantity": "0.5",
    "postOnly": true
  }'

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:

curl --fail-with-body --silent --request POST "$EDEL_API_URL/v1/orders/$ORDER_ID/cancel" \
  --header "Authorization: Bearer $EDEL_API_KEY" \
  --header "content-type: application/json" \
  --header "Idempotency-Key: $CANCEL_ATTEMPT_ID" \
  --data '{"accountId":"your-account-id","marketId":"BTC-USD-PERP"}'

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), present it on the socket, then subscribe. The ticket, not the key, travels on the connection, so a long-lived socket never parks your key.

See the WebSockets tab for the subscribe frame and the payload of each channel.

Optional: the MCP server

An AI agent can reach the venue through the Edel Model Context Protocol server, which authenticates with an API key from the same device grant 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

An agent key expires (24 hours by default). To renew, run the device grant again and have the owner approve a fresh key; there is no self-service rotation for an agent key. The owner can revoke a key at any time with their passkey session. A refused key answers 401; connect again. 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.

​1. Get a key with the device grant

​2. Authenticate every request

​3. Place and cancel orders

​4. Stream the book and your fills over WebSockets

​Optional: the MCP server

​Renew and revoke

​Shared reference

1. Get a key with the device grant

2. Authenticate every request

3. Place and cancel orders

4. Stream the book and your fills over WebSockets

Optional: the MCP server

Renew and revoke

Shared reference