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.

Execution Intelligence

Pre-trade forecast, live monitor, post-trade review, scenario simulator.

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:

Suffix	Meaning	Example
`_1e8`	Quantity × 10⁸	1 BTC = `100_000_000`, 0.5 ETH = `50_000_000`
`_1e9`	Price × 10⁹	$50,000 = `50_000_000_000_000`
`_bps`	Basis points	10 bps = 0.10%
`_ns`	Nanoseconds since Unix epoch	`1705406400000000000`

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 parent_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.

HTTP	Code	When
`400`	`BAD_REQUEST`	Malformed request
`400`	`VALIDATION_ERROR`	Invalid field values (includes `details`)
`401`	`UNAUTHORIZED`	Missing or invalid API key
`403`	`FORBIDDEN`	Valid key but insufficient permissions
`404`	`NOT_FOUND`	Resource doesn't exist
`409`	`CONFLICT`	Kill switch active, duplicate order with different params
`429`	`RATE_LIMITED`	Too many requests — back off and retry
`500`	`INTERNAL_ERROR`	Server error — retry with same `graph_id`
`503`	`SERVICE_UNAVAILABLE`	Temporarily 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.

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.

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.