Market-maker integration

Connect an independently operated market-making strategy through the owner-approved agent connection. The owner grants a scoped key for one account and a limited lifetime. Start with read access while validating market data, account state and recovery behavior.

Enable trade scope only when the owner authorizes the strategy. A trading credential does not grant permission to deposit, withdraw or complete secure setup. Market makers can integrate directly through REST and WebSockets; MCP is optional.

Select the target from environments, then read GET /v1/api-keys/current. Verify active state, principal, approved account, scope and expiry. Check account readiness and its active secure identity binding. Funding is an owner action in the app.

Read GET /v1/markets and choose a currently permitted market. Load scales, quantity and price bounds, fee fields and margin parameters from the returned metadata. Keep credentials, balances and market configuration separate for each environment. The catalogue and key-metadata examples in market data and API keys are read-only starting points.

Read the book, account, positions and live open orders once. Connect a socket and subscribe to market.book, market.trades, market.price, market.funding and market.status as needed by the strategy. Mint a ticket for account.orders, account.fills, account.positions, account.balance and relevant margin/PnL channels. Wait for each acceptance and reconcile snapshots before enabling quotes.

Track public feed health separately from private account health. Rotation must produce a fresh auth_ok before expiry. On a gap or dropped private subscription, stop decisions based on cached account state and recover it. The book is a complete projected snapshot; do not add its sizes to the prior book as if they were deltas.

After read-only validation, the owner can authorize the strategy's exact scope of trading. Preview an intended order using current data, then place a deliberately bounded first order in the approved test environment. postOnly applies only to limits, and reduceOnly is a separate exposure constraint.

Use stable clientOrderId and Idempotency-Key values. Confirm the response, account order event and any fills. Test cancelling an owned remainder with a separate stable cancel identity. Preserve existing exposure when interpreting a partial fill: cancellation does not reverse it. See Orders API for the request variants and batch behavior.

Reserve authenticated request capacity for orders, cancellations, ticket minting and recovery. The default budget is 600 requests per credential per 60-second fixed window; stream live updates over a shared WebSocket connection. See rate limits for reset and retry behavior.

Define stop conditions for stale state, unavailable channels, credential expiry and unknown order outcomes before enabling a strategy. REST and WebSockets provide the market-making interface. MCP offers optional snapshot and command tools for AI clients; it does not replace a live feed.

The default authenticated limit is 600 requests per 60 seconds per key or signed-in user. The window starts with the first request and resets 60 seconds later; it is not a rolling window. The configured limit can differ by environment. Use the limit documented for your approved venue; do not assume that a limit described for the forthcoming Mainnet venue applies to Devnet. Minting realtime tickets counts against the authenticated budget.

Excess requests return 429 with code rate_limited, retryable: true and recoveryActions containing retry_after. The response has no Retry-After header. Wait for the fixed window to reset, at most 60 seconds, and retry the same request with its original mutation identities. If an upstream or future response supplies a valid Retry-After, honor that delay as well. Avoid synchronized retry bursts.

Invalid-credential traffic is limited separately by network address. Public authentication allows 20 requests per 60 seconds per trusted client IP. Device-grant polling uses its returned interval and slow_down behavior within the approval handshake.

Define strategy limits for maximum inventory, order quantity, outstanding orders, stale-data age and accumulated losses before starting. For AI-driven strategies, enforce these limits in client controls as well as the model’s instructions. The venue still applies its own risk controls; client checks do not bypass them. Evaluate mark/index health, market status and available margin before a risk-increasing action.

Pause new exposure when key verification fails, private data is stale, continuity is broken, a source is unavailable or an order's outcome is unknown. Keep a separate cancellation path, while recognizing that a venue halt can reject cancellation too. A 24/7 perpetual market is not a promise of uninterrupted connectivity or order acceptance.

Retain the original request, clientOrderId, Idempotency-Key and any returned orderId. Inspect the current order and reconcile account.orders, account.fills and positions. If the contract says the error is retryable, retry the identical attempt after the required delay. A transport timeout must preserve the original order identity.

For batch operations, track results by their request index and individual order identity. Already accepted siblings remain accepted. If history lags behind live state, show that lag and use the live order endpoint for a working-order question. Keep persistence and settlement observations separate from the immediate order decision.

Agent keys require a new owner-approved device grant when an extension is needed; there is no unattended renewal route. Plan approval before expiry so access does not lapse unexpectedly while a strategy has outstanding orders.

Realtime tickets have their own shorter lifetime. Rotate the current ticket, then authenticate the socket with the new ticket before expiresAt. Do not reuse a consumed ticket on a replacement connection. After recovery, rebuild the state needed for the strategy and only then resume. Revocation should immediately disable new commands and prompt the owner to review outstanding orders and exposure.

Record requestId, operation name, status/error code, retry decisions, timing, logical order identity and relevant sequence positions. Monitor heartbeat age, private authentication expiry, subscription acceptance, stale channels and snapshot freshness. Redact authorization headers, API keys, connect codes, tickets and owner signing material.

Measure behavior in your authorized target environment before increasing traffic or risk limits. The public API does not provide a throughput or latency service level. Use integration testing to validate changes before updating a running client.

A quoting loop needs current public prices and depth alongside private working orders, fills, exposure and available risk capacity. Track the freshness of each input separately. Pause decisions that require private account state when that state is stale, even if public market ticks continue.

Use stable order identities and reconcile fills racing a cancellation before calculating replacement quantity. A cancel/new sequence is not an atomic amendment. The public API does not provide a dead-man switch, automatic cancel-on-disconnect or a universal replay window, so plan for outstanding orders during a connection failure.