Betfair API Rate Limits and Best Practices

This page contains affiliate links — if you open an account through them we may earn a commission at no cost to you. It never changes our verdict.

This is a sub of our Betfair API developer guide, and it assumes you already have an application key and a working login flow. The limits below are the ones that actually bite in production. None of them are arbitrary — each protects Betfair’s infrastructure and, indirectly, the fairness of the market — but they catch out almost everyone the first time they scale a bot from one market to thirty.

The limits at a glance

There are four distinct limits to keep straight, because they throw different errors and have different fixes. First, the market-data weighting limit: each data request carries a weight, and weight times the number of markets cannot exceed 200 points, or you get TOO_MUCH_DATA. Second, the transaction limit: more than 1,000 individual order instructions in a single second returns TOO_MANY_REQUESTS. Third, a concurrency limit on certain order-related calls, which also surfaces as TOO_MANY_REQUESTS and applies per account ID. Fourth, data-usage monitoring, where Betfair can apply charges if your data consumption is high relative to your betting. Mix these up and you will fix the wrong thing.

The 200-point data weighting limit

This is the limit beginners hit first. Calls like listMarketBook, listRunnerBook, listMarketCatalogue and listMarketProfitAndLoss let you pass several market IDs at once, but Betfair caps the total data you can pull in one request. The rule is precise: the sum of the price-data weights multiplied by the number of market IDs must not exceed 200 points per request. Exceed it and the API returns TOO_MUCH_DATA rather than partial data — the whole request fails. The point of the rule is to stop a single call dragging the entire order book for dozens of markets at once, which is expensive to serve and almost always unnecessary.

How request weights add up

The weight depends on what price data you ask for. Requesting the best prices only (EX_BEST_OFFERS) is light; requesting the full ladder (EX_ALL_OFFERS) or all traded volume (EX_TRADED) is heavy. As a working rule, EX_BEST_OFFERS carries a weight of about 5 and EX_ALL_OFFERS about 17, so the maths falls out like this:

• Best offers (weight ~5): 200 ÷ 5 = up to roughly 40 markets per request.
• Full ladder (weight ~17): 200 ÷ 17 = only about 11 markets per request.
• No price data (catalogue/static, weight ~2): far more markets per request.

So the practical lesson is to request the lightest projection that does the job. If your bot only needs the touch prices to make a decision, never ask for the full ladder — you cut your per-request capacity by more than three quarters for data you are not using. Verify the current exact weights against the developer docs, because Betfair has adjusted them over the years, but the formula (sum of weight × market count ≤ 200) is stable.

The 1,000-transactions-per-second limit

The transaction limit is about orders, not data. It triggers on placeOrders, cancelOrders, updateOrders and replaceOrders when the number of individual instructions you submit exceeds 1,000 in a single second. Crucially, it counts instructions, not API calls — a single placeOrders call containing 300 bet instructions counts as 300 transactions. For a normal trader this is effectively unreachable; you would have to be firing enormous batched orders. But an automated bot that cancels and re-places across many markets every cycle can approach it, especially if it is churning orders unnecessarily. The cleanest defence is also the best trading habit: do not cancel and re-place an order you could simply leave in place.

Concurrency and the TOO_MANY_REQUESTS error

Separately from the transaction cap, Betfair applies a concurrency limit to certain calls, and it is tied to your logged-in account ID rather than your session token — opening multiple sessions does not get you around it. The calls that contend are the ones that read order or matched state: listMarketBook when you request an OrderProjection or MatchProjection, listCurrentOrders, and listMarketProfitAndLoss. In the worst case all three compete with each other, so if you are simultaneously polling positions, current orders and P&L, you can self-inflict TOO_MANY_REQUESTS even at modest request rates. listClearedOrders has its own separate rate-limiting and does not contend with these. The takeaway: do not parallelise order-state reads aggressively, and serialise or stagger them instead.

Data charges and bet volume

Polling cadence: how often is too often

If you must poll rather than stream, cadence is the variable that decides whether you stay safe or get throttled. There is no need to poll listMarketBook faster than the rate at which your strategy can actually act on the data. For pre-race work, a poll every second or two is plenty; the prices simply do not move fast enough pre-off to justify more, and hammering the endpoint ten times a second just burns your data allowance and inches you toward charges for no benefit. In fast in-play markets the temptation to poll harder is strongest and the danger greatest — this is precisely where you should switch to the Stream API instead, because no sustainable polling cadence keeps up with an in-running market anyway. As a rule of thumb: if you find yourself wanting to poll more than once a second, that is the signal to stream, not to poll faster. The trader who polls a sensible cadence and streams the rest never thinks about rate limits; the one who polls aggressively spends their evenings reading error logs.

Beyond the hard error-throwing limits, Betfair monitors how much data you pull relative to how much you actually bet, and reserves the right to apply data charges under its API terms when usage is heavy and betting is light — the API is meant to support betting, not free bulk data harvesting. There is also a high bet-volume threshold (in the region of several thousand bets per hour) above which additional terms can apply. Most individual traders never come close to either, but if you are running a data-hungry model that polls constantly and bets rarely, you are exactly the profile the charges exist for. The fix overlaps neatly with everything else here: pull less data, pull it more efficiently, and use streaming.

Why the Stream API solves most of this

If there is one piece of advice that fixes more rate-limit problems than any other, it is this: stop polling for prices and use the Exchange Stream API instead. Polling means hammering listMarketBook on a timer, which is exactly what runs into the 200-point weighting cap and the data-usage monitoring. The Stream API works the opposite way — you subscribe once to the markets you care about, and Betfair pushes you incremental updates whenever prices change. You get faster, fresher data with a fraction of the request overhead, and the weighting limit largely stops being your problem because you are not making repeated heavy data requests. For any application that needs near-real-time prices — in-play bots especially — streaming is not an optimisation, it is the correct architecture. Our streaming API guide covers how to set up the subscription.

Best practices that keep you inside the limits

The official guidance and hard experience point the same way. Make the minimal number of transactions possible: every order you place, cancel or replace is a transaction, so do not churn. Prefer leaving an order in place over cancelling and re-placing it — not only does this stay well under the transaction limit, it also keeps your queue position, which matters far more to your fills than most people realise. Request the lightest projection that answers your question, and never pull the full ladder when the touch will do. Batch market-data requests up to but not over the 200-point cap. Serialise order-state reads rather than firing listCurrentOrders, listMarketProfitAndLoss and order-projection book calls in parallel. And above all, stream prices rather than poll them. Do these five things and you will essentially never see a limit error.

Handling errors and backoff gracefully

Even a well-behaved bot will occasionally trip a limit — a burst of in-play activity, a transient spike — so build the handling in rather than letting an exception kill the loop. When you receive TOO_MANY_REQUESTS, back off: pause, then retry with an exponentially increasing delay rather than immediately hammering the endpoint again, which only deepens the contention. When you receive TOO_MUCH_DATA, do not retry the same request — it will always fail — instead split it or lighten the projection programmatically. Log every limit error with the request that caused it so you can see patterns, and treat a rising rate of them as a signal that your architecture, not your retry logic, needs attention. Robust error handling is a whole topic in itself; we cover the full set of failure modes in API error handling.

Testing safely against the delayed application key

Every limit above is far easier to learn about on the delayed application key than on the live one with real money at stake. Betfair issues two keys — a delayed key that returns data on a delay and is ideal for development, and a live key for production — and you should do all your rate-limit experimentation on the delayed one. Deliberately push it: request thirty markets with the full ladder and watch TOO_MUCH_DATA appear so you recognise it instantly in production; build your backoff and chunking logic against the delayed key until limit errors are handled cleanly; only then point the same, already-hardened code at the live key. The cost of discovering the 200-point cap in development is a confusing afternoon; the cost of discovering it live, mid-session, with a position open, is real money and a blind bot. Treat the delayed key as your wind tunnel and the limits stop being surprises.

The verdict

Betfair’s API limits look fiddly until you see the single idea behind them: the API exists to support betting efficiently, not to be a free, unlimited data tap. Respect the 200-point weighting rule, stay far below the 1,000-transaction ceiling by not churning orders, serialise your order-state reads, and — the big one — stream prices instead of polling them. Get those right and the limits become invisible; you will run a faster, cheaper, more reliable bot that never gets throttled or charged. Build on the developer guide, get streaming working via the Stream API, and harden the whole thing with proper error handling before you let real money near it.

FAQ

Related reading

Start at the Betfair API developer guide, set up access with an application key and the getting-started flow, then build in Python or Node.js. Move real-time data onto the Stream API, protect your fills with good queue position, harden everything with error handling, and understand the risks of running a bot.