Sequence/docs
REST API

API Reference

The full trading lifecycle in one API — submit orders, query market data, manage credentials, deploy algorithms, stream real-time updates. JSON over HTTPS.

code
Base URL: https://api.sequencemkts.com

Interactive Swagger UI: api.sequencemkts.com/docs (browse without auth).


Endpoints

Orders & Graphs

Submit, cancel, amend orders. Execution graphs (TWAP, brackets, hedges). Fills. Kill switch.

Market Data

NBBO, order book depth, batch quotes, price history, DEX pools, token info.

Portfolio & Balances

Unified positions — fiat, crypto, perps, event contracts — in one endpoint.

Prediction Markets

Kalshi + Polymarket: slugs, settlement, rewards, redeem.

Credentials

Venue API keys, Sequence Wallet, and Sequence API key lifecycle.

Algorithms

Deploy, start, stop WASM algos. Per-deployment logs, metrics, traces.

Streaming

SSE for orders / fills / TCA. WebSocket for market data and signing.

Analytics

TCA reports, venue quality, execution cost attribution, market structure.


Authentication

Every request needs a Bearer token:

bash
curl https://api.sequencemkts.com/v1/health \
  -H "Authorization: Bearer seq_live_YOUR_API_KEY"

API keys start with seq_live_ (production) or seq_test_ (sandbox). Get yours from Settings → API Keys in the Terminal.

Sandbox keys return live market data but simulate order fills — useful for testing without risking real money.


Data encoding

Sequence uses fixed-point integers for financial values to avoid float precision errors. Every numeric field is suffixed with its scale:

SuffixMeaningExample
_1e8Quantity × 10⁸1 BTC = 100_000_000, 0.5 ETH = 50_000_000
_1e9Price × 10⁹$50,000 = 50_000_000_000_000
_bpsBasis points10 bps = 0.10%
_nsNanoseconds since Unix epoch1705406400000000000

If a field has no suffix (e.g. bid_price), it's a human-readable float. Rule: suffix = fixed-point integer, no suffix = float.

Warning

Getting _1e8 and _1e9 confused makes your orders 10× wrong. A qty_1e8 of 50_000_000_000_000 isn't 0.5 BTC — it's 500,000 BTC. See Data Formats for full conversion tables.


Request format

  • All request and response bodies are JSON (UTF-8).
  • HTTPS only — plain HTTP is rejected.
  • Content-Type: application/json required on POST / PATCH / PUT.

Request ID

Every request gets a correlation ID:

  • Send your own: X-Request-Id: your-id (≤128 chars).
  • Or let the server generate a UUID v4.
  • Echoed back in the response X-Request-Id header.

Idempotency

Order submissions are idempotent via graph_id. Submit the same graph_id twice → second request returns the original order's node_order_id without creating a duplicate. Safe retries — on timeout or 5xx, retry with the same graph_id and you'll never double-submit.

If you retry with the same graph_id but different parameters, you get 409 Conflict.


Errors

All errors return a structured JSON envelope:

json
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "validation error: qty_1e8: must be positive",
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "details": [
      { "field": "qty_1e8", "message": "must be positive" }
    ]
  }
}

code is stable and safe for programmatic handling. message is human-readable. details is only present for VALIDATION_ERROR.

HTTPCodeWhen
400BAD_REQUESTMalformed request
400VALIDATION_ERRORInvalid field values (includes details)
401UNAUTHORIZEDMissing or invalid API key
403FORBIDDENValid key but insufficient permissions
404NOT_FOUNDResource doesn't exist
409CONFLICTKill switch active, duplicate order with different params
429RATE_LIMITEDToo many requests — back off and retry
500INTERNAL_ERRORServer error — retry with same graph_id
503SERVICE_UNAVAILABLETemporarily unavailable — retry
Tip

Always check error.code, not HTTP status alone. A 400 might be BAD_REQUEST (malformed JSON) or VALIDATION_ERROR (valid JSON, bad values) — the handling differs.


Rate limits

Each API key has a requests-per-second limit on your account profile. Exceeding it returns 429. The limit applies across all REST endpoints.

The limiter is a token bucket: bucket capacity = 2× your qps (so an idle key can absorb a brief burst), refill = qps tokens/sec. Default tier-by-tier:

TierSustained QPSBurst capacity
free510
paid / pro / enterprisevaries2× sustained

Each API key has its own bucket — keys do not share quota. Buckets do not share across IPs either; rate limiting is keyed on the authenticated client_id, not on source IP.

SSE and WebSocket connections are long-lived and don't count against the rate limit after the initial connection. WebSockets use a short-lived ticket: POST /v1/ws/ticket for a one-time token, then pass it as a query parameter on the WS upgrade.

See Rate Limits for headers and retry strategies.


Venue health & drift detection

GET/v1/health/edges

Public endpoint (no auth). Compares an operator-configured set of expected venues against the venues currently connected via cc-link (local + peer-link mirrored). Designed for external monitors / status pages — point any HTTP probe at it on a 60-second interval and alert on drift == true.

Response

json
{
  "expected": ["binance","bybit","coinbase","cryptocom","dex","hyperliquid","kalshi","kraken","okx","polymarket","solana","binance-perp","bybit-perp","okx-perp","bitget"],
  "connected": ["binance","binance-perp","bitget","bybit","bybit-perp","coinbase","cryptocom","dex","hyperliquid","kalshi","kraken","okx","okx-perp","polymarket","solana"],
  "missing": [],
  "extra": [],
  "drift": false
}
FieldDescription
expectedThe CC's EXPECTED_VENUES env list. Operator-defined ground truth for what should be connected.
connectedBare venue names (without venue-edge- prefix) currently in the local registry plus anything mirrored from a peer CC via EdgeViewMirror.
missingexpectedconnected. Any value here means a venue silently dropped — alertable.
extraconnectedexpected. Informational; usually means a new venue came online before the operator updated the config.
drifttrue iff missing is non-empty.

For the per-edge view (region, connected venues, symbol counts), use /v1/edges (auth required).


Quick example

Full workflow in curl — quote, submit, check:

bash
# 1. Get quote for ETH-USD
curl https://api.sequencemkts.com/v1/quotes/ETH-USD \
  -H "Authorization: Bearer $SEQ_API_KEY"
 
# 2. Submit a market buy for 1 ETH
curl -X POST https://api.sequencemkts.com/v1/orders \
  -H "Authorization: Bearer $SEQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"symbol": "ETH-USD", "side": "buy", "qty": 1.0}'
 
# 3. Check the graph status
curl https://api.sequencemkts.com/v1/execution_graphs/graph_YOUR_ID \
  -H "Authorization: Bearer $SEQ_API_KEY"

For SDK examples (Python, Rust, CLI), see the Quick Start.