A question buyers bring to checkout is how many users a plan supports. The answer is that the question does not apply: Pinnacle API plans are metered on request rate and transport, not seats. Ten thousand users of your app and ten users cost the same upstream, because the API never sees your users. It sees your poller.
What the plans meter
The plan guide starts from the loop, not the price list: what matters each minute is whether your code waits for drops, polls boards, does both, or needs every frame. The plans differ in exactly those dimensions: the REST rate, whether the SSE drop stream is included, and whether the raw WebSocket can be added, checked 2026-10-03. Nowhere in that list is a user count.
Where your users actually read
Your users should never touch the API at all. The standard shape is one reader upstream and many consumers downstream: your poller holds the key, writes your own store, and your site or app reads from that store. A thousand concurrent visitors then cost exactly the same upstream volume as one, because only the poller calls the API.
This is also why a slow month for your audience changes nothing about the bill, and a viral week changes nothing either. The bill follows the loop's rate, not the audience's size.
When user count sneaks back in
Indirectly, users do shape the plan. A bigger audience usually justifies more features: more sports covered, a live view next to the prematch one, an alerting bot on the side. Each feature is a loop, and loops are what the plans meter. So the question to ask is not how many users you have, but how many boards your features need and how fresh they need them.
A single-sport odds page refreshing every few seconds needs far less than a multi-sport screen with live prices. Both can serve any number of readers.
The sizing exercise, restated
Count sports, count phases, pick the interval, and the arithmetic gives you requests per second. That figure, plus whether you need the drop stream or raw frames, picks the plan. If your estimate sits near a ceiling, remember the pricing page's warning, checked 2026-10-03: a published per-second limit is not permission to run permanently at it.
Size for the loop, cache for the crowd. The plan question is a rate question wearing a pricing costume.