CAPACITY PLANNING
Capacity planning for a Pinnacle odds API pipeline.
Capacity planning for the Pinnacle odds API turns three product decisions into two numbers: requests per second and requests per day. Run the arithmetic before you pick a plan, and the Pinnacle REST API becomes a budget you manage instead of a quota you fear.
The three inputs
Every capacity estimate for Pinnacle odds comes from three inputs, and each one is a product decision before it is a technical one.
Sports covered. The markets endpoint answers one sport per request and returns every event in it, each with its money line, spreads, totals and team totals across periods. Covering four soccer leagues or every soccer league costs the same request; covering five sports costs five.
Phases. Live and prematch boards are separate requests with the same shape. The docs put the prematch refresh at about every 30 seconds, so polling faster than that buys nothing. Live prices reach the feed within a fraction of a second, so live is where the interval matters.
Poll interval. The interval decides how fresh your state is and how often you pay for it. Halving it doubles the requests with no change in scope. After the first call the since cursor returns only the events that changed, so a faster interval adds requests but little payload.
The math: boards ÷ interval
The formula is one line. Requests per second equals the boards you poll, sports times phases, divided by the interval in seconds. When live and prematch run on different intervals, add the two rates. Requests per day is that rate times the active seconds in a day.
Worked examples, polling every board all day:
| Scope | Poll interval | Requests / second | Requests / day |
|---|---|---|---|
| 5 sports, live5 boards per cycle | 1 s | 5 | 432,000 |
| 5 sports, live and prematch10 boards on two intervals | 5 s live, 30 s prematch | 1.17 | 100,800 |
| All 13 sports, live and prematch26 boards on two intervals | 2 s live, 30 s prematch | 6.93 | 599,040 |
Two lessons fall out of the arithmetic. First, the interval is the strongest lever on live boards: moving from 5 seconds to 1 multiplies requests fivefold with zero added coverage. Second, fixtures do not add requests; sports and phases do. Poll 16 active hours instead of 24 and every daily figure falls by a third, so count active hours, not calendar hours.
Headroom for match days
Match days change the payload, not the board count. When a full Saturday slate runs, each board carries more events and more of them change between polls, so responses grow and your parser works harder, while a board is still one request.
Requests do grow with events when you fetch per-event detail, such as one prematch event's full markets or its alternate lines. Budget those calls separately: 200 detail calls every 30 seconds is about 6.7 requests a second on their own. Kickoff clustering and the occasional timeout retry stack on top, exactly when you can least afford staleness.
Size for the peak, not the average. If peak load exceeds your per-second ceiling, the excess is not queued, it is rejected, and your state goes stale during the minutes that matter most. The patterns in rate limit handling keep rejections from becoming outages, but headroom is the real fix.
From volume to a Pinnacle API plan
Once you have requests per second at peak, matching volume to a plan is mechanical. Free REST access, 20 requests per minute and 100 requests per day, is enough to inspect responses and prototype. Production polling needs paid capacity: the tiers compared on this site run at 10 and 30 requests per second with unlimited daily volume, so the per-second rate is the number to match.
Work the formula with your own inputs and compare the peak figure with the ceilings in the plan section. A peak of 6 requests per second fits the 10 per second tier. All 13 sports live every second is 13 a second, which needs the 30 per second tier.
To turn the same schedule into a monthly figure, the API cost calculator on pnclAPI takes the interval, active hours and boards and returns requests per billing period.
Two ways to shrink the bill before upgrading: the delta reads in efficient REST polling cut wasted calls, and the backoff discipline in 429 handling stops retries from burning quota.