What is the difference between an odds feed and an odds API?

A polling API returns prices when you request them, so each response is a complete picture. A feed pushes changes as they occur, which is faster and more efficient but means your state is built from a chain of updates that must be kept consistent.

What happens if an odds feed disconnects?

You must resynchronise, not just reconnect. Request a fresh snapshot and rebuild state from it, because messages sent while disconnected were missed. Applying new deltas to stale state is a common bug that produces prices which look valid and are wrong.

When is an odds feed better than polling?

When timing is the question being studied, when coverage is large enough that frequent polling becomes expensive, or when an application shows live prices. For closing price evaluation and most research, scheduled polling is simpler and sufficient. A reasonable path is to build on polling first and add a feed for the questions polling cannot answer.

What Is an Odds Feed?

An odds feed is a data connection that pushes price updates to you as they happen, usually over a persistent connection such as a WebSocket or a message stream. It contrasts with a polling API, where you request prices on a schedule. Feeds deliver changes faster and require handling of ordering, gaps, and reconnection.

How a feed works

A persistent connection. Rather than making a new request for each set of prices, your system opens a connection and keeps it open. Common transports are WebSockets, server-sent events, and message queue subscriptions.

Snapshot, then deltas. On connecting, most feeds send the current state of the markets you subscribed to. After that they send only changes: this price moved, this market was suspended, this market reopened, this event started. Your system applies each change to its copy of the state.

Message contents. A typical update identifies the event, market, and selection, and carries the new price, line where relevant, market status, and one or more timestamps. Many feeds also include a sequence number.

Heartbeats. Periodic messages that carry no price data and simply confirm the connection is alive. Their absence is how you detect a connection that has silently stopped delivering.

Subscriptions. You usually specify which sports, events, or markets you want. Subscribing to everything produces a very large message volume, much of which a given project does not need.

Feed versus polling

Polling is simple and self-correcting: every response is a complete picture, so a missed request costs only that moment. A feed is faster and more efficient, since you only receive what changed, but your state is built from a chain of changes, so a missed message can leave your copy wrong until you detect it and resynchronise.

What a feed requires from you

Detecting gaps. If messages carry sequence numbers, check that each one follows the last. A jump means messages were missed. Without sequence numbers, gaps are much harder to detect, which is worth weighing when choosing a provider.

Resynchronising. When a gap is detected or the connection drops, request a fresh snapshot and rebuild state from it. Reconnecting and continuing to apply deltas to stale state is the most common feed bug, and it produces prices that look valid and are wrong.

Handling ordering. Messages can occasionally arrive out of order. Use sequence numbers or source timestamps, not arrival time, to decide which update is newest.

Keeping up. During busy periods, message volume spikes. If your system processes updates more slowly than they arrive, a backlog builds and everything you read is increasingly out of date. Measure the lag between source timestamp and processing time, and alert on it.

Recording raw messages. Store the raw stream with receipt timestamps before transforming it. When a price looks wrong later, the raw log is the only way to find out whether the source sent it or your processing produced it.

Monitoring silence. A quiet feed can mean quiet markets or a broken connection. Heartbeats distinguish the two; alert when they stop.

Storing state from a feed

Keep two things: the raw message log and a current state table rebuilt from it. If processing logic changes or a bug is found, the state can be regenerated by replaying the log from the last good snapshot, which is much safer than trying to patch a state table in place.

When a feed is worth it

Timing is the question. Studying how quickly markets react to information, or which sources move first, needs updates at the moment they happen. Polling at any practical interval blurs exactly the thing being measured.

Coverage is large. Polling many markets frequently becomes expensive in requests. A feed that sends only changes can be far more efficient at scale.

Live applications. Anything displaying current prices to people, or reacting to in-play changes, needs the latency a feed provides.

When it is not. Evaluating models against closing prices, building historical datasets from scheduled snapshots, and most research questions are served perfectly well by polling. The added engineering of a feed, particularly resynchronisation and monitoring, is real ongoing work and should be taken on because a question needs it.

A reasonable path is to build on polling first, confirm which questions polling cannot answer, and add a feed for those.

This page describes data infrastructure and is not betting advice.

Test the failure path first

Before trusting a feed integration, deliberately break it. Kill the connection mid-stream, drop messages, and delay processing. Confirm that gaps are detected, state is rebuilt from a snapshot, and alerts fire. An integration that has only been tested while everything works has not really been tested.

Frequently asked questions

What is an odds feed?: A data connection that pushes price updates to you as they happen, usually over a persistent connection such as a WebSocket or message stream. It typically sends an initial snapshot of subscribed markets, then a stream of changes including price moves, suspensions, and status updates.
What is the difference between an odds feed and an odds API?: A polling API returns prices when you request them, so each response is a complete picture. A feed pushes changes as they occur, which is faster and more efficient but means your state is built from a chain of updates that must be kept consistent.
What happens if an odds feed disconnects?: You must resynchronise, not just reconnect. Request a fresh snapshot and rebuild state from it, because messages sent while disconnected were missed. Applying new deltas to stale state is a common bug that produces prices which look valid and are wrong.
When is an odds feed better than polling?: When timing is the question being studied, when coverage is large enough that frequent polling becomes expensive, or when an application shows live prices. For closing price evaluation and most research, scheduled polling is simpler and sufficient. A reasonable path is to build on polling first and add a feed for the questions polling cannot answer.