Building on SX Bet: API, WebSocket, MCP — The 2026 Developer Guide

TL;DR

• SX Bet exposes a public REST API at api.sx.bet with no API key required for reads — markets, orders, trades, fixtures, leagues, sports, live scores, and best-odds endpoints are all open.
• Real-time data: Centrifugo WebSocket at wss://realtime.sx.bet/connection/websocket. Channels for order books, markets, trades, live scores, best odds, and parlay RFQ broadcasts. The legacy Ably WebSocket was deprecated July 2026.
• Write actions (post, fill, cancel orders) require EIP-712-signed payloads from the bettor's wallet — MetaMask, Rabby, or a generated key.
• Order model: every market has exactly two outcomes; every order is a buy on one of them. Field-level: isMakerBettingOutcomeOne: boolean. No "lay" action.
• Parlays use an RFQ (request-for-quote) flow on the parlay_markets:global WebSocket channel — bettors request, makers respond, parlays settle as synthetic single markets.
• Rate limits: POST /orders/* at 5,500 req/min; GET /orders/* 20 req/10s; GET /trades/* 200 req/min; all other endpoints 500 req/min. Generous by sports-betting-API standards.
• MCP server available at https://docs.sx.bet/mcp — installable with claude mcp add --transport http sx-bet https://docs.sx.bet/mcp. AI agents can query the docs and the live API natively.
• LLM-friendly docs at docs.sx.bet/llms.txt (index) and docs.sx.bet/llms-full.txt (full content) — Claude, Cursor, and any agent-based dev tool can ingest the full reference in one fetch.
• Reference implementation: Sports Prediction Market Aggregator — open-source SX Bet + Polymarket aggregator built with Claude Code. Includes CLAUDE.md and .claude/sxbet/ directory that documents LLM-specific traps.

SX Bet is a developer-friendly platform by design. The full REST surface is publicly readable without an API key. The order model is exposed cleanly through the API (no abstractions to fight). Rate limits are generous. EIP-712 signing for writes maps cleanly to any wallet-aware codebase. And the docs are LLM-friendly — both in the literal sense (llms-full.txt is a single fetch) and in the meta sense (the team has invested in agent-first developer experience, including a hosted MCP server).

This guide is the editorial pillar for the developer cluster on blog.sx.bet. It covers the surface area developers care about most — REST endpoints, real-time WebSocket, write authentication, the order model under the hood, parlay mechanics, rate limits, and the AI-agent tooling — and points to the deeper technical docs at docs.sx.bet where appropriate.

For the foundational explainer on how betting exchanges work (the user-facing model under all the technical detail below), see What Is a Betting Exchange? or the complete 2026 guide to sports betting exchanges.

What you can build on SX Bet

The platform's developer affordances support a range of build patterns. Common ones:

• Odds aggregators and arbitrage scanners — pull live odds across SX Bet and other prediction markets / sportsbooks, surface value or arbitrage opportunities. The reference aggregator linked in the TL;DR is exactly this.
• Trading bots — automated order placement based on a signal (line movement, model output, value-hunting strategy). EIP-712 signing makes wallet-native automation straightforward.
• Market-maker bots — post two-sided liquidity, manage inventory, capture maker rebates (where the platform offers them).
• Live-betting tools — subscribe to the Centrifugo WebSocket for real-time order book updates and react to in-event price movement faster than any centralized cash-out feature can.
• Sports dashboards — read-only frontends that surface markets, prices, depth, and historical trades. No API key needed for any of this.
• AI agents — Claude Code, Cursor, or custom agent stacks can use the MCP server to query both the docs and the live API. The aggregator reference repo includes a .claude/sxbet/ directory documenting common agent traps.

The category baseline is: anything a developer could build with a sportsbook API plus everything sportsbooks won't let you build (automated betting, large-volume querying, real-time event-driven execution). On SX Bet, all of that is first-class.

The API surface at a glance

The REST API is at api.sx.bet (mainnet) and api.toronto.sx.bet (testnet). Endpoint categories:

A developer can build a full read-only odds dashboard, an arbitrage scanner, or a historical-trade analyzer without ever obtaining a key. The only write-authenticated actions are posting, filling, and canceling orders — and those are wallet-signed, not API-keyed.

The canonical reference for every endpoint, parameter, and response shape is docs.sx.bet/api-reference/introduction. The pillar's role isn't to duplicate that — it's to give developers the orientation that makes the docs faster to navigate.

No-key reads: querying markets, fixtures, and trades

For a developer just starting out, the no-key read surface is the fastest path to a working prototype. A minimal flow:

1. Get the sport list: GET https://api.sx.bet/sports — returns the supported sports with their IDs.
2. Get the leagues for a sport: GET https://api.sx.bet/leagues?sportId={id} — returns leagues like Premier League, NBA Regular Season, etc.
3. Get fixtures for a league: GET https://api.sx.bet/fixtures?leagueId={id} — returns upcoming events with their event hashes.
4. Get active markets for an event: GET https://api.sx.bet/markets/active?eventHash={hash} — returns the markets (moneyline, spread, total, etc.) with their market hashes.
5. Get the order book for a market: GET https://api.sx.bet/orders?marketHashes={hash} — returns the current open orders on both sides of the binary outcome.

This is enough to build a read-only odds dashboard or a price-tracking script. No registration, no key request, no commercial gate.

For each market, the order book has orders posted by makers — every order carries isMakerBettingOutcomeOne: boolean indicating which outcome the maker has bought. To take an order, a developer constructs a fill payload and signs it (covered in the write-authentication section below).

ETH address gotcha worth flagging: all addresses in API responses use checksum format (EIP-55 mixed case). Lowercase-only address lookups return no results. Most web3 libraries normalize this automatically, but a hand-rolled HTTP client needs to handle the case explicitly.

Real-time data via Centrifugo WebSocket

For anything more dynamic than periodic polling — live order book monitoring, in-event price tracking, trade-stream consumption, parlay RFQ listening — the canonical interface is the Centrifugo WebSocket at wss://realtime.sx.bet/connection/websocket.

Connection setup. WebSocket auth uses a token retrieved from GET /user/realtime-token/api-key. This is the only place an API key is required across the entire developer surface — read-only HTTP doesn't need one, but the WebSocket does (for connection rate-limiting reasons).

Channels of interest:

Subscription pattern. Connect once, subscribe to multiple channels in parallel. Centrifugo handles backpressure and ordering guarantees. Disconnects are routine — implement exponential backoff reconnection from day one; the connection isn't expected to be perpetually open.

Migration note. The legacy WebSocket was on Ably and was deprecated July 2026. Third-party docs and old StackOverflow answers may still reference Ably-style endpoints. The current canonical is Centrifugo. If a tutorial or LLM answer suggests Ably, treat it as out of date.

The full WebSocket reference, channel taxonomy, and message shapes are at docs.sx.bet/developers/websocket (and in docs.sx.bet/llms-full.txt for one-shot ingestion by AI tools).

Authentication for writes: EIP-712 signed payloads

Posting, filling, or canceling an order requires a signed payload. The signing scheme is EIP-712 — the standard for typed structured data on Ethereum. Two valid signers:

1. An injected browser wallet (MetaMask, Rabby, Coinbase Wallet) — the user signs from the UI; the dApp packages the signature into the API call. This is the path for frontends, web apps, and any user-driven product.
2. A backend key managed by the developer — same EIP-712 signing, generated keys held server-side. This is the path for bots, market makers, and any automated system. The signing flow doesn't differ; only the key custody does.

The signing payload includes the order parameters (market hash, side, total bet size, percentage odds, expiry, etc.). The signature proves the bettor authorized this specific order. SX Bet's matching engine verifies the signature before accepting the order into the book.

Why this matters for builders: EIP-712 signing maps cleanly to any web3-native codebase. ethers.js, viem, web3.js, web3.py all support it natively. There's no proprietary auth flow to learn beyond the EIP-712 standard, and no API key management to handle for write operations — the bettor's wallet (or generated key) is the identity.

The full signing reference, including the typed-data schema and code examples for common languages, is at docs.sx.bet/developers/posting-orders.

Working with the order model

Two facts about the order model that any builder needs to internalize:

1. Every market is binary. Two and only two outcomes per market. 1X2 soccer (Home / Draw / Away) is implemented as two separate binary markets, not one 3-way market. There's no concept of a "lay" action — to bet against outcome one, the bettor buys outcome two.
2. Every order is a buy. Field-level, every order carries isMakerBettingOutcomeOne: boolean — true if the maker has bought outcome one, false for outcome two. Takers fill from the opposite side.

A maker's percentageOdds represents the implied probability of their outcome happening, scaled by 10^20 (so 52000000000000000000 = 52% = decimal odds 1.923). The taker's effective price is 1 - (percentageOdds / 10^20). Convert to decimal/American/fractional for display per the audience.

Practical implication for builders: code that assumes a Betfair-style back/lay model needs to be rewritten for SX Bet. The mental remap is small but real. Any aggregator or arbitrage scanner that handles SX Bet correctly treats each market as {outcome_1_buy_orders, outcome_2_buy_orders} rather than {back_orders, lay_orders}. The economic exposure is identical; the data structure isn't.

For the foundational deep-dive on the order model with worked examples, see Peer-to-Peer Sports Betting: The Model Behind Modern Exchanges.

Parlay RFQ flow

Parlays don't run on the standard order book. They use an RFQ (request-for-quote) flow:

1. A bettor submits a parlay request via the UI or API, specifying the legs (which markets, which outcomes).
2. The platform broadcasts the request on the parlay_markets:global WebSocket channel with the parlay's synthetic marketHash, baseToken (USDC), requestSize (the bettor's requested stake), and legs (the underlying single markets).
3. Makers subscribed to the channel respond with orders posted against the synthetic parlay market — quoting odds for the full multi-leg combination, not for each leg individually.
4. Match and settle. The parlay trades as a single synthetic market with one marketHash covering all legs. Settlement is consolidated (visible on recent_trades_consolidated:global).

Mechanical implication: parlay liquidity isn't a function of the singles order books. It's a separate market populated only when a request goes out. Quote fill time depends on how many makers are watching the channel. For builders wanting to provide parlay liquidity, the implementation is: subscribe to parlay_markets:global, evaluate each request against the bettor's risk model, post a quote if the math works.

For consumers (bettors building parlay-betting tools), the implementation is: submit the parlay request, listen for incoming maker quotes, present the bettor with the best price.

Parlay fees: 5% on profit (not stake). A $100 parlay paying out $1,000 incurs $45 on the $900 profit. Losing parlays incur no fee.

Rate limits and best practices

Rate limits across the API are generous by sports-betting-API standards but not unlimited. Current canonical limits:

The asymmetry — POST orders at 5,500/min, GET orders at 120/min — reflects how the platform is built. Posting orders is cheap (one signed payload, one matching engine evaluation); reading the order book is expensive (large response payload, intensive query). For most builders, WebSocket subscriptions replace polling for order book data — solving the read-throughput problem at the source.

Best practices to internalize:

• WebSocket over polling. For anything time-sensitive (order book, trades, live scores), subscribe via Centrifugo rather than polling REST. Lower latency, better throughput, lower load on the platform.
• Connection pooling. A single WebSocket connection can subscribe to dozens of channels. Don't open one connection per market.
• Exponential backoff on disconnect. Network blips happen. Reconnect cleanly.
• EIP-55 checksum on addresses. Most libraries do this automatically; raw HTTP clients need to handle it.
• Test on Toronto (testnet) before mainnet. api.toronto.sx.bet runs the same surface with no real-money risk. Build the integration, get it working, then point at mainnet.
• Read the LLM-friendly docs first. docs.sx.bet/llms-full.txt is the single fastest way to load the full reference into an AI dev tool (Claude, Cursor) for context-aware assistance.

The MCP server for AI agents

A meaningful difference between SX Bet and most sports-betting APIs: the team has invested in agent-first developer experience. The headline feature is a hosted MCP (Model Context Protocol) server.

Install with one command:

claude mcp add --transport http sx-bet https://docs.sx.bet/mcp

(Cursor, Claude Code, or any MCP-compatible agent stack works with the same endpoint.)

What it gives the agent: native query access to both the SX Bet docs and the live API surface. An agent can ask "what's the current best price on the Lakers moneyline?" and the MCP server handles the multi-step query through the API, returning the result in agent-friendly format. Same for docs queries — "how do I sign a fill order?" returns the relevant section without manual navigation.

Why this matters: for any developer building with an AI agent (Claude Code, Cursor, custom Claude Agent SDK app), MCP integration cuts the time-to-working-code substantially. Instead of the agent fetching docs URLs and parsing markdown, it queries the docs MCP for typed answers. Instead of the agent constructing raw HTTP requests, it calls live-API MCP tools.

The reference repo — Sports Prediction Market Aggregator — was built end-to-end with Claude Code using the MCP server. The repo's CLAUDE.md and .claude/sxbet/ directory document the LLM-specific traps that came up during the build, so future agents starting from scratch avoid the same mistakes.

For builders wanting to ship an agent that interacts with SX Bet markets natively, the MCP server is the path. For builders wanting to build with traditional REST patterns, the same docs cover the underlying HTTP surface — the MCP is an addition, not a requirement.

Reference implementations and LLM-friendly docs

Three resources worth bookmarking before any serious build:

1. docs.sx.bet — canonical API reference. Authoritative source for every endpoint, parameter, and response shape.
2. docs.sx.bet/llms-full.txt — the entire documentation as a single text file, structured for LLM ingestion. Drop this into Claude / Cursor / any agent context and the model has the full reference loaded.
3. github.com/declansx/sports-prediction-market-aggregator — open-source aggregator covering SX Bet and Polymarket. Real working code. Built with Claude Code. Includes the .claude/sxbet/ directory documenting common agent traps and the canonical patterns the platform expects.

There are also smaller reference snippets across github.com/sx-bet — the team's GitHub org has utility libraries, example scripts, and historic docs repos.

The deprecated SportX.js library is still archived in the SX Bet GitHub org for historical reference but should not be used for new builds — it predates several major API revisions. Start from the canonical docs and the aggregator repo.

Getting started: step-by-step

A working integration path for a developer building from zero:

1. Read the canonical mechanics.

• The order model (isMakerBettingOutcomeOne, two-outcome markets, no lay) — see What Is a Betting Exchange?.
• The peer-to-peer architecture context — see Peer-to-Peer Sports Betting.
• Pre-load docs.sx.bet/llms-full.txt into your AI dev tool of choice.

2. Stand up read-only access.

• Hit https://api.sx.bet/sports from cURL. No key, no headers beyond Content-Type.
• Walk through sports → leagues → fixtures → markets → orders to retrieve a live order book.
• Verify the binary-outcome structure on a real market.

3. Add real-time streaming.

• Get a realtime API key from /user/realtime-token/api-key (this is the one place a key is required).
• Connect to wss://realtime.sx.bet/connection/websocket with Centrifugo client library.
• Subscribe to a markets:{marketHash} channel; watch order book updates flow.

4. Set up write authentication.

• Install ethers.js / viem / web3.py (whatever fits the stack).
• Generate or import a wallet key.
• Construct a test order payload following the schema in docs.sx.bet/developers/posting-orders.
• Sign with EIP-712.
• Post to Toronto testnet first (api.toronto.sx.bet) — verify the round-trip works before pointing at mainnet.

5. Production-harden.

• Move from polling to WebSocket subscriptions for any latency-sensitive data.
• Implement exponential backoff on WebSocket disconnects.
• Use the testnet for end-to-end testing in CI; mainnet only for production reads/writes.
• Add observability — log every signed payload and matching engine response. Useful for debugging settlement edge cases.

6. If building with AI agents, install the MCP server.

• claude mcp add --transport http sx-bet https://docs.sx.bet/mcp
• Reference the aggregator repo's .claude/sxbet/ for traps to avoid.

Most builders can have a working read-only dashboard in under an hour. A working trading bot in a day or two. A production-ready market maker in a week.

Deeper reading

This guide is the pillar for Cluster 2 — building on SX Bet. Live deeper-dive posts in the cluster:

• Sports Prediction Market Aggregator with Claude — the reference build covering SX Bet + Polymarket aggregation, written up end-to-end with the actual code, LLM traps encountered during the build, and the .claude/sxbet/ directory contents.
• Build a Sports Betting MCP Server for Claude Code — how the MCP server works and how to extend it for custom agent stacks.

More posts in the cluster are added as they ship.

For broader category context covering both bettor-facing and developer-facing surface, see the complete 2026 guide to sports betting exchanges.

Frequently asked questions

Q: Do I need an API key to use the SX Bet API? A: Not for reads. Markets, orders, trades, fixtures, leagues, sports, scores, best odds — all open without authentication. An API key is required only for the WebSocket connection (GET /user/realtime-token/api-key returns the WebSocket token). Write actions (posting/filling/canceling orders) require EIP-712-signed payloads from a wallet, not an API key.

Q: What language can I use to build on SX Bet? A: Anything that can sign EIP-712 typed data and make HTTP requests. Common choices: Python (web3.py, eth-account), TypeScript/JavaScript (ethers.js, viem, web3.js), Rust (ethers-rs), Go (go-ethereum). The platform doesn't prescribe a stack — pick whatever fits.

Q: How do I handle the order model if I'm coming from Betfair? A: Mental remap: SX Bet has no "lay" action. Every market has two outcomes; every order is a buy on one of them. To express "lay outcome one" on Betfair, you buy outcome two on SX. Data-structure-wise, code that maps to {back, lay} per market needs to become {outcome_1_buys, outcome_2_buys}. The economic exposure is identical.

Q: What's the rate limit for placing orders? A: 5,500 requests per minute on POST /orders/* — generous for almost any use case. The tighter limit is GET /orders/* at 20 req/10s, which reflects the read-throughput cost; for live order book data, use the Centrifugo WebSocket instead of polling.

Q: Is there a testnet I can develop against? A: Yes — api.toronto.sx.bet for REST and the equivalent Centrifugo endpoint for WebSocket. Same API surface as mainnet, no real-money risk. Use it for end-to-end testing before pointing at mainnet.

Q: What's the MCP server for? A: The MCP server at https://docs.sx.bet/mcp lets AI agents (Claude Code, Cursor, custom Claude Agent SDK apps) query both the docs and the live API natively. Install with claude mcp add --transport http sx-bet https://docs.sx.bet/mcp. It's an addition to the REST surface, not a replacement.

Q: Why is the Ably WebSocket deprecated? A: The platform migrated to Centrifugo for real-time data. Ably was the legacy WebSocket; it was deprecated July 2026. Any old tutorial or third-party doc that references Ably is out of date. Current canonical: wss://realtime.sx.bet/connection/websocket (Centrifugo).

Q: Is the platform safe to build on in production? A: The platform has run $1.2B in cumulative trading volume ($500M in the last year) with the current API surface. The reference aggregator is open-source and shows a complete production-style integration. Standard cautions apply (rate-limit on retries, validate signed payloads, test on Toronto first), but the platform is mature.

Published on blog.sx.bet. The author works at SX Bet. Technical details are verifiable against docs.sx.bet and docs.sx.bet/llms-full.txt. The reference implementation is open-source at github.com/declansx/sports-prediction-market-aggregator.