REST INTEGRATION
Poll the Pinnacle REST API without waste.
Most Pinnacle API quota problems are design problems. A disciplined integration reads only what changed, reads it once, and spaces the calls. Four habits keep Pinnacle odds fresh in your backend while request volume stays flat.
The Pinnacle API since cursor
The REST API supports delta reads. Pass the cursor from the previous response and the next call returns only what changed since that point. A full fixtures read over a busy slate might return hundreds of events; a delta read after a quiet minute returns a handful, often none.
Store the cursor server-side, next to the snapshots it produced, in Redis, Postgres or whatever holds your market state. Each poller run reads the cursor, passes it with the request, then persists the new cursor together with the merged state. After a deploy or a restart, resume from the stored cursor instead of starting over.
The anti-pattern to avoid: re-reading full snapshots on a timer. It feels safe, but it moves far more data than cursor reads (the docs' own example is 1,522 events for a full prematch soccer board against 7 changed events for the delta after it) and makes your parser redo work that did not change. Full snapshots are for first boot and disaster recovery, not for steady state.
Cache and reuse downstream
One reader, many consumers. Your dashboard, pricing model, settlement service and alerting jobs all read your own store, never the API. Fifty internal consumers cost exactly the same upstream volume as one, because only the poller calls upstream.
The cache is also the security boundary. The API key lives in the poller, server-side. Browsers and client apps call your backend, which answers from its own copy with its own freshness metadata. The pipeline architecture on the homepage describes the shape: fetch once, normalize, serve your own interfaces.
Reuse changes the capacity question from how many users you have to how fast prices move, which is the question capacity planning actually answers.
Pace requests evenly
A per-second limit charges you for bursts, not averages. Ten board calls due every 5 seconds should leave one every 500 milliseconds, not ten at the top of the window. Even pacing keeps the instantaneous rate under the ceiling and leaves room for retries and per-event detail calls.
Avoid top-of-minute alignment. A cron entry that fires on the minute starts on the same second as every other cron-driven client on the internet, and APIs feel it. Offset your schedule, and within each cycle spread calls with a simple queue: interval divided by calls becomes the delay between requests.
The worked example on the homepage computes exactly this evenly distributed rate. If your scheduler cannot hold that shape, the effective limit you experience is lower than the number on the plan, and the first symptom is the 429 pattern covered in rate limit handling.
Handling failures
Reads will fail: timeouts, a 5xx from upstream, a 429 when a burst slips through. Design for failure in the poller, not in the consumers.
Set the client timeout well below the poll interval so a hung read cannot stall the next cycle. Retry with exponential backoff and jitter, honor Retry-After on 429 responses, and cap attempts so one bad minute does not multiply into a traffic spike. The rate limits guide walks through the pattern with pseudocode.
Between failures, keep serving the last good snapshot and mark it stale. An odds display that is 20 seconds old and labeled beats an empty one. If misses pile up, the fix is usually volume, not heroics: revisit the cursor, the cache hit rate and the pacing before touching the plan.