SX Bet API (2026): Endpoints and Authentication

SX Bet is a peer-to-peer sports prediction market, so every price came from another user's resting order. That makes its API less like a sportsbook feed and more like a small exchange gateway: read a book, sign an order, watch a socket. The docs are unusually complete for a venue this size.

What the SX Bet API Covers

Every response arrives in the same envelope, { "status": ..., "data": ... }, and paginated routes use a cursor: send pageSize up to 100, pass the returned nextKey back as paginationKey. Settlement is USDC with six decimals, so amounts are base-unit integer strings: one dollar is "1000000".

Access splits three ways. Public market data is open to anyone: markets, the book snapshot, best odds, fixtures, live scores and the trade tape. Account reads need a key. Orders and funding need the key plus a signature. Toronto mirrors all three tiers on testnet with its own key.

Authentication: One Key, One Header

Getting a key takes seconds and no application: log in to sx.bet, go to Account, then Overview, and click Generate API Key Now in the API Credentials card. Two warnings: the key is displayed once and never again, and only one key can be active at a time, so generating a fresh one silently invalidates every previous key.

Authentication itself is one header: x-sx-api-key. Watch the spelling, because the docs flag x-api-key as a different, legacy credential and the wrong header for V3. Every response is scoped to the address that owns the key.

The signature layer applies to exactly two routes: POST /orders-v3 needs an EIP-712 signature over the order struct, and POST /user/transfer-to-proxy needs an EIP-2612 permit. Cancels, reads and heartbeats need only the key. The WebSocket uses a third credential, a short-lived token from /user/realtime-token-v3/api-key.

The REST Endpoints That Matter

Pick your history grain deliberately: /fills-v3 is one row per match, /trades-v3 one row per bet, /positions-v3 net exposure.

Posting an Order in Six Steps

Deploy and fund a proxy wallet first with POST /user/deploy-proxy. Orders without one fail with 400 PROXY_NOT_DEPLOYED, which catches almost everyone once.

One, fetch metadata. GET /metadata/obv3 returns the EIP-712 domain, chain ID, odds ladder step size and escrow address; read it at startup rather than hardcoding. Two, round your odds down to a multiple of oddsLadderStepSize × 10^15: divide, floor, multiply back. Three, pick a time in force. GTC rests, IOC executes what it can and discards the rest, FOK fills entirely or not at all.

Four, sign the order struct. Eight fields: marketHash, baseToken, totalBetSize, percentageOdds, salt, expiry, maker and isMakerBettingOutcomeOne. The domain version is "1", not "1.0", a detail that quietly breaks signatures ported from older code. Five, submit and expect HTTP 201 with status PENDING. Six, wait for activation, because pending is not live: either set waitForOutcome: true or watch the account:orders_v3 stream until the order flips to ACTIVE.

Batches allow ten orders per request, all sharing the same maker, and they are not atomic, so a duplicate clientOrderId fails the whole batch. Taking liquidity uses the same endpoint: an IOC or FOK order hits the book instead of resting, and results land in your fills rather than your orders list. Because percentageOdds is implied probability, lower is better for a taker, and an order at 48% may match at 46% but never at 50%. Self-matching is blocked, and only the two public REST routes accept showTakerPerspective=true.

Canceling, and the Dead Man Switch

Three cancel routes, three behaviors. DELETE /orders-v3 takes up to 100 order IDs and is synchronous, waiting up to five seconds for the matching engine before reporting per order whether the cancel was confirmed, refused, or still unconfirmed. DELETE /orders-v3/event and DELETE /orders-v3/all return the moment the command is accepted and confirm nothing, so removal shows up on account:orders_v3 as INACTIVE.

Then the feature that tells you SX Bet expects real market makers. POST /heartbeat/v3 takes one field, timeoutSeconds, from 0 to 3600. Arming and refreshing are the same request, so you call it on a timer, and if your process dies every open order is canceled with inactiveReason: "HEARTBEAT_TIMEOUT". Send 0 to disarm.

The WebSocket Layer

Real-time data runs on Centrifugo over one connection at wss://realtime.sx.bet/connection/websocket, with a toronto equivalent for testnet. Centrifugo ships official SDKs for JavaScript, Python, Go, Dart, Swift, Java and C#. Connect with a token from /user/realtime-token-v3/api-key through the client's getToken callback. The token carries a sub field holding your checksummed address, and account channels use channel_#{checksummedAddress}, which has to byte-match that sub. Case matters.

The channels mirror the REST surface. Public: orderbook_v3:{marketHash} for one market's depth, orderbook_v3_event:{eventId} for a whole event, best_odds_v3:global, recent_trades_v3:global, plus markets:global, fixtures:global and fixtures:live_scores. Private: account:orders_v3_#{address}, account:fills_v3_#{address} and account:trades_v3_#{address}. One connection caps at 512 channels, error code 106 past that.

Recovery is Centrifugo's. Subscribe with recoverable: true and the client replays what it missed on reconnect, giving at-least-once delivery inside the recovery window. Read the subscribed event: if recovered is true the gap is filled, and if false, history was pruned and you re-seed from REST. Deduplicate on the messageId in ctx.tags. Order book channels carry a monotonic version instead, so apply a publication only when its version exceeds yours.

Rate Limits, Endpoint by Endpoint

SX Bet publishes real numbers, not vague guidance. Authenticated limits are metered per API key over sixty-second windows, and order routes are generous: 5,500 for POST /orders-v3, 3,000 for DELETE /orders-v3, 1,200 for reading your orders, 600 for the heartbeat. The blunt instruments are tighter, at 120 for cancel-by-event and 60 for cancel-all. Fills, positions, trades and balance sit at 300 each, the realtime token at 30, proxy deploys and transfers at 20.

Public limits are metered per client IP: 5,500 each for the book snapshot and best odds, 500 for metadata and summary routes, 200 for public trades. Unauthenticated traffic also shares a global edge bucket of 35,000 requests per ten-minute window.

Metered responses carry X-RateLimit-Limit and X-RateLimit-Remaining, and going over returns HTTP 429 Too Many Requests with a Retry-After header. The docs are blunt about the fix: subscribe instead of polling, because subscriptions do not use your request budget.

Watching SX Bet Next to Every Other Venue

One exchange only tells you what one pool of liquidity thinks. SX Bet's prices come from whoever is willing to post, so the same game can sit at a different number here than on a regulated US exchange, and that gap is the reason to watch more than one book. Predictefy covers 15+ venues and matches the same event across them, so a game becomes one row with every venue's price beside it instead of six tabs and six auth schemes. Predictefy's arbitrage API is free to use if you would rather screen those gaps programmatically.

Frequently Asked Questions

Conclusion

The SX Bet API is a small, well-documented exchange gateway: one credential for reading, a second for signing, and a published number for every limit. What breaks first is predictable: the proxy wallet you forgot to deploy, the PENDING order you treated as live, odds that never landed on the ladder, and a polling loop that should have been a subscription. Keep the official docs open.

One housekeeping note: this is information, not financial, tax or legal advice. Endpoint paths, rate limits and eligibility change, and SX Bet restricts access by jurisdiction, so verify against the official docs and terms before you build anything that moves money.