← Blog · 📝 Article · 10 October 2026

Betfair Streaming API: Fix No Packets Before Lay Signals Stall

Betfair Streaming API: Fix No Packets Before Lay Signals Stall

The Stream API needs a Live Application Key, a fully verified and funded account, and a valid bearer token on every connection. Missing any of these three is the single most common reason developers see no packets at all. A Delayed App Key still connects but returns conflated data roughly every three minutes, which is unusable for any live trading or lay-signal logic.

TL;DR:

  • listMarketBook has a 200 point weight limit per call; batch ten or fewer market IDs and request only fields your strategy needs.
  • TOO_MANY_REQUESTS is account wide and occurs above three concurrent requests, so stagger calls to keep no more than three in flight.
  • Internal placement calls time out after five seconds, but orders may appear up to fifteen seconds later; check order state before resubmitting.
  • con=true means several updates were merged, usually because your consumer fell behind; queue each message and process it outside the socket reader.
  • A heartbeat timeout from 10 to 300 seconds can cancel unmatched bets after disconnect, but inspect actionPerformed because cancellation may be partial.
Donkeyradar
Find Pre-Race Lay Signals Without Building a Stream
DonkeyRadar uses historical strike rates and live market prices to publish pre-race lay signals for UK, Australian and US horse races.

Table of Contents

How to obtain and use a Live Application Key and bearer token

A Live Application Key only activates once your account passes identity verification and holds real funds. Betfair treats this as a gate against abuse of live market data, so a Delayed key is what you get by default, and it returns updates in a single message every three minutes rather than a continuous feed.

Once you have a Live key, authentication for streaming uses a bearer token rather than the plain session token some REST calls accept. The most frequent cause of NOT_AUTHORIZED is sending a session token issued for a non-interactive or vendor flow where the stream expects a web application login, or letting the token expire mid-session.

What TOO_MUCH_DATA, TOO_MANY_REQUESTS and TIMEOUT errors mean

Betfair weights every request by the fields you ask for, and listMarketBook enforces a 200-point limit per request. Stack heavy projections like full order books across many markets and you exceed that ceiling quickly.

The limit is fixed at 200 points per listMarketBook call, and combining EX_ALL_OFFERS with EX_TRADED projections can push the effective weight far higher per market than a lighter field set.

TOO_MANY_REQUESTS is tied to your account ID, not to a single session, and appears once more than three concurrent requests are in flight. TIMEOUT_ERROR on an order placement does not mean the order failed: internal calls time out after five seconds, but an order can still appear up to fifteen seconds later, so always check order state before resubmitting. Our guide to Betfair unmatched bets covers that verification step in detail.

How to build marketFilter and marketDataFilter to subscribe efficiently

Subscribing to too much data is the quiet killer of stream performance. A tight marketFilter keeps the socket lean, and the fields you request in marketDataFilter decide both your payload size and your weighting.

  1. Scope eventTypeIds, marketTypes, countryCodes and venue filters to exactly what your strategy trades.
  2. Pick EX_BEST_OFFERS with a small ladder_levels value for low-latency trading rather than EX_ALL_OFFERS, which carries the full depth of the book.
  3. Add EX_MARKET_DEF only where you need market status, inplay flags or runner removals.
  4. Request SP_* fields separately and only for markets where starting price matters to your logic.
  5. Re-evaluate your field list whenever you add markets, since weight compounds across simultaneous subscriptions.

Understanding con=true, img=true and cache sequencing

Every streaming message carries a publish time (pt) you use to order updates and reject anything arriving out of sequence for a market you already hold a newer state for. Two flags matter more than any other field in the payload.

Pro Tip: Hand off every incoming message to a queue immediately and process it on a separate thread or task, so the socket reader never blocks waiting on your trading logic.

How reconnection works and why to register a heartbeat

Keep your original subscription filter in memory. On reconnection you resend it and Betfair returns a RESUB_DELTA that patches your existing cache back into sync, though some markets instead send a fresh img=true full image, which you must swap in atomically to avoid a race between old and new state.

Heartbeat protects you from silent disconnects but is not a substitute for monitoring: treat it as a backstop, not a guarantee, and pair it with your own alerting.

Short betfairlightweight examples and how to avoid buffering bottlenecks

The betfairlightweight wrapper handles the socket plumbing and gives you listener classes to build on rather than parsing raw JSON yourself.

  1. Create a trading client, log in, then call trading.streaming.create_stream(listener=listener) to open the connection.
  2. Build a streaming_market_filter scoped to your event types and markets, and a streaming_market_data_filter naming only the fields you need.
  3. Subscribe with stream.subscribe_to_markets(market_filter=..., market_data_filter=...) and call stream.start().
  4. Inside your listener, push each market_book update onto a queue and return immediately, leaving the heavy processing to a worker consuming that queue.
  5. For backtesting, betfairlightweight also exposes historical stream generators that replay recorded data through the same listener interface, so your production parsing logic needs no rewrite.
  1. Confirm your app key is Live, not Delayed, and that the account passed verification and holds funds.
  2. Check that both X-Application and X-Authentication headers are present and the token has not expired.
  3. Trim your marketDataFilter fields and batch market IDs to stay under the weight limit.
  4. Watch your logs for repeated con=true and move processing off the socket thread if you see it.
  5. Verify your heartbeat is registered and responding, since a silently failed heartbeat leaves open positions unprotected on disconnect.

Security considerations beyond authentication, including data privacy

Authentication headers get the most attention, but a few other practices matter once your stream is live in production. Session tokens and app keys should never sit in source control or client-side code, since anyone holding them can place orders or pull market data under your account. Store them in environment variables or a secrets manager and rotate the session token on every fresh login rather than reusing one indefinitely.

Treat the data itself with care too. A live stream carries your own order and position information alongside public market data, so logs that capture full payloads for debugging can end up holding account-sensitive detail. Scrub or encrypt logs before they leave your infrastructure, and restrict who on your team can read raw stream captures.

If your pipeline runs on shared or cloud infrastructure, isolate the process holding your credentials from anything public-facing. A compromised web front end should never have direct access to the same environment variables as your trading client. Network-level controls, such as restricting outbound connections to Betfair’s known endpoints, add a cheap extra layer without touching your application code.

None of this replaces Betfair’s own account security settings, two-factor login and IP controls, which remain your first line of defence. Streaming credentials simply extend that same attack surface into your own codebase, so they deserve the same discipline.

Security considerations beyond authentication, including data privacy — overview diagram

Use cases specific to lay betting and integration tips with DonkeyRadar signals

A lay-betting pipeline cares about one thing above all else: catching a price drift before the field settles into its final shape. Streaming market updates let you watch a horse’s lay price move in real time rather than polling every few seconds and missing the moment it happened, which matters most in the minutes before a race when liquidity and prices move fastest.

Our lay betting strategy guide explains how we combine statistical signals with live market data to flag the weakest runner in a race before it goes off. A typical integration pattern takes a published signal, watches the corresponding market through the stream, and triggers an order only once the live price crosses a threshold you set, rather than acting on a stale snapshot.

Lay signal to threshold-triggered order flow

Because our signals are published ahead of race time, your streaming client can subscribe to exactly the markets you need rather than scanning an entire race card, which keeps your weight usage low and your consumer fast. Pairing a narrow, well-scoped subscription with a signal feed is a practical way to keep both API limits and execution latency under control.

Donkey’s operational perspective on using streaming data for lay-signal pipelines

Streaming earns its keep the moment polling intervals start costing you price movement, which for lay signals is most of the time near the off. Polling is simpler to build, but a cache that falls out of sync or a missed heartbeat can leave a position unprotected without you noticing until it is too late.

We treat the stream as infrastructure, not a convenience: disciplined reconnection handling and an active heartbeat are what let an automated lay strategy run unattended with any confidence.

— Donkey

Betting a straightforward route to lay signals without building a stream yourself

Everything above assumes you want to build and maintain your own streaming client, which is the right call if integration is the point. If your goal is simply to act on strong lay opportunities, we publish our signals before races with full historical results tracked and verified, so you can judge the approach on its record rather than take our word for it.

DonkeyRadar Free gives you daily lay signals with no streaming code to maintain, and DonkeyRadar Pro adds real-time alerts by email and Telegram, full results history and API access for anyone who wants to feed our signals into their own trading software. Our checklist for picking horses to lay walks through the selection logic behind each signal if you want the reasoning before you commit. Start with the free tier and see the published results for yourself at Donkeyradar.

FAQ

What is the difference between a Live and Delayed Betfair App Key?

A Live Application Key streams real-time market updates and requires a verified, funded account, while a Delayed key returns conflated updates roughly every three minutes. The delayed feed is fine for exploring the API but unsuitable for any strategy that depends on current prices.

Why do I keep getting TOO_MUCH_DATA errors on listMarketBook?

Your combined field projections are exceeding the 200-point weight limit per request. Reduce the projections you request or split your market IDs into smaller batches to bring the total weight back under the ceiling.

What does con=true mean in a streaming message?

It means the update was conflated because your client did not consume previous messages fast enough, and it usually points to your own processing speed rather than a problem on Betfair’s side. Moving message handling onto a separate queue away from the socket reader typically resolves it.

Does DonkeyRadar require me to build my own streaming integration?

No, our signals are usable directly through the dashboard with no coding required, and API access on DonkeyRadar Pro is available for anyone who wants to feed results into their own trading software. The streaming guidance in this article is aimed at developers building their own tools, not a requirement for using our signals.

What happens if my client loses connection without a heartbeat registered?

Any unmatched limit bets remain live on the exchange with no automatic protection if your client disconnects unexpectedly. Registering a heartbeat with a preferredTimeoutSeconds value between 10 and 300 triggers automatic cancellation of those bets if no heartbeat is received in time.

Sources