WEBSOCKET CAPACITY
Pinnacle WebSocket API capacity: raw frames, not polls.
Pinnacle REST API sizing starts from a poll interval and a per-second budget. A raw WebSocket stream removes both, and replaces them with a frame flow, a reconnect budget and a copy of market state that only your client holds. Capacity planning still matters; it just measures different things.
What the Pinnacle WebSocket API changes
On REST, freshness is a schedule you design. Every refresh is a request, and requests are what plans meter: 10 per second on Core 10 at $99 per month, 30 per second on Core 30 at $229 per month. The whole capacity question reduces to interval times scope, measured against that ceiling.
A raw WebSocket stream inverts the model. Once the socket is open and subscribed, frames arrive as prices move: there is no poll interval to tune and no per-second budget to defend on the stream itself. What arrives is not a processed alert but the raw frame flow, and applying those frames into a coherent picture of every event and market you follow is your code's job. The API stops being a lookup service and becomes a feed you keep a replica of.
The capacity questions that remain
Frame rate at peak. Average traffic is calm; a full Saturday slate or a live favorite is not. Size parsing, CPU and downstream queues for the busiest minute you intend to follow, not the daily average, because frames queue on your side of the socket the moment your consumer falls behind.
Reconnect and resync cost. Sockets drop. Recovery means re-subscribing and rebuilding state from the fresh snapshot the socket sends at the start of every connection. That snapshot arrives over the socket, not through your REST budget, but a large board comes in several chunks, so rebuilding takes real parsing time at exactly the moment you are busiest.
Storage of state. Each worker that consumes the stream holds its own copy of the markets it tracks. Decide what lives in memory, what you persist for faster restarts, and how much RAM a full slate of markets costs before you subscribe to one.
Raw frames vs SSE alerts
SSE and raw WebSocket are both push, but they push different things. SSE drop alerts are processed: the feed side has already decided what changed and whether the move clears a threshold, and your code reacts to a notification. Raw WebSocket frames are unprocessed: you compute the changes, the thresholds and the meaning yourself.
That split maps to two kinds of consumer. If your product reacts to moves, SSE fits: Drop alerts at $99 per month, or Core 10 + alerts at $149 per month when you also need 10 requests per second of REST. If your product owns state, a pricing screen, a trading backend, anything that renders the book rather than reporting events, raw frames are the right input. The add-on is $99 per 30 days and is eligible on Core 10, Core 10 + alerts and Core 30; it is not available on Drop alerts or on the free key.
When to stay on REST
If your reads are simple and your volume is low, REST is the better tool. A handful of events, minute-level freshness, a cron-driven job: the free key's 20 requests per minute and 100 requests per day can cover evaluation, and Core 10 covers most production dashboards, with nothing to maintain between calls. The capacity planning guide walks through turning sports, markets and intervals into the request rate you need.
WebSocket earns its add-on when you genuinely own live state: sub-second awareness across a meaningful slate, many markets per event, a product that renders the book continuously. At that point the $99 per 30 days add-on on Core 10 and up replaces poll-interval math with frame-rate math, and the plan comparison shows the eligible tiers side by side.