Share one Pinnacle API key across pollers without 429s

One Pinnacle API key, five sports, three processes: the rate limit does not care how many workers you run. The per-second ceiling belongs to the key, so every worker you add spends from the same budget. The design that works partitions the boards across workers, paces them against one shared limiter, and keeps one cursor per board.

The ceiling belongs to the key

Every plan carries a per-second allowance, and crossing it returns 429 with a Retry-After header, as the rate limits guide documents, checked 2026-10-01. Two pollers each running at 6 requests a second on a 10-a-second tier are one 12-a-second load as far as the API is concerned. The first number to compute is therefore not any worker's speed but the total: sports times phases divided by interval, summed across everything that runs.

Partition the boards, not the requests

Give each worker its own slice of the coverage: a set of sports and phases that no other worker touches. Partitioning beats sharing a task queue for one reason: the since cursor is per board. A worker that owns its boards owns its cursors, stores them next to the snapshots they produced, and resumes them after a restart without coordinating with anyone.

Two workers polling the same board do not halve the cost of the board. They double it.

Pace against one shared budget

Backoff state has to be shared, because ten processes each backing off politely still add up to ten times the requests, as the rate limits guide warns. The same goes for pacing. A small shared limiter, for example a token bucket in Redis that every worker checks before a call, keeps the aggregate rate under the ceiling no matter how individual schedules drift.

Keep steady-state usage under roughly 70 percent of the ceiling. On a 10-a-second tier that is 7 a second across all workers combined, leaving the rest for retries, resynchronizations and the occasional full board read, per the same guide's headroom rule.

Watch the aggregate, not the workers

Per-worker logs lie by omission: each worker can look healthy while their sum is over budget. Track the total request rate and the 429 count across the key, and alert on that, not on any single process. The capacity planning guide turns sports, phases and interval into the per-second figure you compare against the ceiling. Run that arithmetic before adding a worker, not after the first 429 storm.

One key, one budget, many workers. Partition the boards, share the limiter, and the ceiling stops being a surprise.