Test your Pinnacle odds pipeline offline before going live

A polling pipeline for the Pinnacle odds API can be tested almost entirely offline. Capture a small set of real responses while you are on the free key, then replay those files through your parser, your cursor logic and your storage layer. Only freshness and timing still need the live API. Everything else can fail safely on your machine first.

Record a fixture set once

You need three recordings: a full board read, the delta read that follows it, and an error response. The REST API answers a full read with an events array and a last cursor; send that cursor back as since and the next call returns only what changed. The documented contrast is sharp: 1,522 events for a full prematch soccer board against 7 changed events in the delta after it, as the integration guide notes, checked 2026-09-29.

Save each response body to a file with its status code, its headers and the cursor you passed. The free key's allowance, 100 requests a day, covers this and leaves the day almost untouched. Keep the files in your repository next to the tests, and refresh them when you change the sports you cover.

Replay through your parser

Point the parser at the files instead of the network. It should produce the same market state from the recorded full read every time, and applying the recorded delta should change exactly the events that changed. This is where most parsing bugs surface: missing periods, renamed leagues, a market that appears in one period and not another.

If you keep a price-change table, replaying the delta twice must not double the rows. The rule from the storage design, insert only when a selection's price differs from the latest row you hold, is exactly the kind of invariant a replay test enforces.

Rehearse the failures on purpose

Offline is the only place where the API fails on command. Serve your client three canned responses: a 429 with a Retry-After header, a 500, and a 200 with truncated JSON. The expected behavior comes from the rate limit guide: honor Retry-After exactly, back off with jitter when no header is present, cap attempts so a bad cycle fails instead of blocking the next one, and treat a 200 with an invalid envelope as an error rather than an empty board.

Log what your client does in each case. A client that hammers through a canned 429 will hammer through a real one on a match day, when headroom matters most.

Test the restart path

Kill the process mid-cycle, restart it, and check that polling resumes from the stored cursor instead of re-reading a full board. The integration guide reserves full snapshots for first boot and disaster recovery; your test should prove the steady state actually works that way.

If you hold a latest-price map in memory for deduplication, rebuild it from the table at startup and confirm the first poll after the restart writes no phantom changes.

What still needs the live API

Fixtures cannot prove freshness. Prematch boards refresh on the source's schedule, about every 30 seconds per the capacity guide, checked 2026-09-29, so polling faster buys nothing, and only a live run shows the real cadence of changes. End the rehearsal with one small live run on the free key: one board, a few polls a minute apart, then compare the observed delta sizes with your recordings.

Record once, replay many times, fail on purpose. The quota you do not spend on testing is quota your first live week keeps for itself.