Webhooks vs polling for odds data

Odds data suits polling, not webhooks. Prices change continuously rather than at discrete events, so there is no clean moment to push. You poll the endpoint on its refresh cadence and send an If-None-Match header to get cheap 304 Not Modified responses when nothing has moved. That keeps you fresh without burning bandwidth. A fast-moving price stream does not map neatly onto webhooks, which is why OddsRelay is pull-based: you poll us, and we say so plainly.

What is the difference between webhooks and polling?

Polling is you asking the server for the current state on a schedule; webhooks are the server calling you when something happens. Both move data between two systems, but they suit opposite shapes of data.

• Polling: your client makes a request every few seconds and reads whatever the endpoint returns. You control the cadence, you retry on your own terms, and the server stays simple. The cost is requests that sometimes return nothing new.
• Webhooks: you register a URL, and the provider sends an HTTP request to it when a defined event fires. You wait instead of asking. The cost is a public endpoint you must run, secure, and keep available, plus retry and ordering logic when a delivery fails.

The deciding question is how the underlying data changes. Webhooks fit sparse, discrete events: a payment settled, a subscription cancelled, a file finished uploading. Polling fits state that changes continuously and that you want a fresh snapshot of. Odds are firmly the second kind.

Why do continuously-changing prices favour polling?

Because a price does not have a natural "event" to hang a webhook on. A match_odds selection on bet365 can drift many times a minute, and the paired exchange lay price moves independently. There is no single moment that means "this changed, notify now" without you defining an arbitrary threshold. Push everything and you have rebuilt a stream; push only large moves and you miss the small ones that still matter to a matcher.

Polling sidesteps that entirely. You ask for the current board on a cadence that matches how fast it changes, and you always get a coherent snapshot. Every selection is consistent with every other because they came from the same read. With webhooks fired per-change, you would stitch a consistent picture back together yourself from a stream of partial updates.

How does ETag and If-None-Match work here?

Each response carries an ETag header, a short fingerprint of the current board. You store it, then send it back on your next request as If-None-Match. If the board is unchanged, the server replies 304 Not Modified with no payload, and you keep the data you already have. If it changed, you get a fresh 200 and a new ETag. The pattern looks like this:

GET /v1/odds/prematch?region=uk HTTP/1.1
Host: api.oddsrelay.io
Authorization: Bearer or_live_...
If-None-Match: "b3d9a1f2"

# unchanged since last poll:
HTTP/1.1 304 Not Modified
ETag: "b3d9a1f2"

# changed since last poll:
HTTP/1.1 200 OK
ETag: "c7e04a88"
{
  "event": "Arsenal vs Chelsea",
  "market": "match_odds",
  "selection": "Arsenal",
  "back": { "bookmaker": "bet365", "odds": 2.10 },
  "lay":  { "exchange": "betfair", "odds": 2.14, "liquidity": 1840 },
  "rating": 98.1,
  "qualifying_loss": -0.12
  // ... region, feed_type and freshness fields elided
}

The matched shape is the point: each row carries the bet365 back price paired with the exchange lay price, plus rating and qualifying_loss, so a 304 means your whole matched board is still current. For the mechanics of cadence, backoff and conditional requests, see polling efficiently. For every field in a 200 body, see the response envelope.

Does OddsRelay push webhooks?

No. OddsRelay is pull-based. You poll api.oddsrelay.io on your cadence and read the current matched board; we do not push webhooks, and we would rather tell you that up front than advertise a feature we do not ship. The feed covers 60+ UK books with bet365 included, matched against three exchanges (Betfair, Smarkets, Matchbook), and it is served from a shared board that every client reads with a conditional GET.

Our honest latency posture is pre-match polling on roughly a few-second cycle, which sets a sensible floor for how often you need to ask. Polling faster than the board refreshes just returns more 304s. The live vs pre-match data split explains why the pre-match cadence is where the durable value sits today.

When would webhooks actually make sense?

Webhooks earn their keep when events are sparse and each one matters individually. For odds data that is rarely the price stream itself, but there are adjacent cases where a push model reads well:

If you want push-style alerts on top of a pull feed, the clean pattern is to poll the board and fire your own webhooks or notifications when a condition you care about is met. That keeps the threshold logic in your product, where it belongs, and leaves the feed to do one job well: return the current matched board on demand.

The short answer

Odds prices change continuously, so you poll a snapshot on the refresh cadence and use If-None-Match to keep it cheap; webhooks fit sparse events, not a fast-moving price stream. OddsRelay is pull-based by design, with bet365 matched against exchange lay prices in every row, and it powers a leading UK matched-betting platform today. You can read the full contract in the API docs, or wire up a conditional GET against real data with a free trial.