Quickstart notes
When to move your script from polling to the drop stream
If your polling loop exists to spot price falls, the drop stream already does that work. The signs you should switch, and what you give up.
The tipping point is easy to spot in your own code: if your polling loop spends most of its lines diffing consecutive snapshots to find price falls, you are re-implementing detection the drop stream already does. Move that part to the stream. Keep polling only for what polling is actually for: complete board state on a schedule.
The signal in your own code
Open your poller and count the lines that have nothing to do with fetching. If most of the work after each response is comparing the new board against the old one, keeping only the falls, and applying a threshold, your script is a drop detector with a polling problem attached. Every line of that diff is code the stream deletes.
The other signal is the cadence mismatch. You poll faster and faster to catch moves earlier, and each step up in frequency multiplies requests while your hit rate stays flat.
What the stream gives you
One HTTP request that stays open, and a data: line for each batch of drops at or above your min_drop, as the Python quickstart shows the same listener. The detection happens on the feed side: the fall, the threshold and the timing are decided before the alert reaches you. Your code shrinks to parse, filter, react.
The first line you receive is a control object, and it doubles as the plan check: a key whose plan has no stream gets plan_lacks_sse instead of alerts, per the same quickstart, checked 2026-10-03.
What you give up
The stream only sends drops. It will not tell you the price that did not move, the board for a match you suddenly care about, or the current state after a restart. If your application renders complete boards or feeds a model that needs every selection, keep the polling loop for state and let the stream handle the moves.
Many projects end up with both: a slow poller for state, the stream for moves. The pricing page lists which plans include the stream and which are polling-only, checked 2026-10-03, so the combination you pick is a plan decision as much as a code decision.
The migration in one afternoon
Keep the poller running, add the stream listener next to it, and log both for a day. When the stream's alerts match the moves your diff would have found, delete the diff. The fetch code, the cursor handling and the error paths you already have carry over unchanged.
Poll for state, stream for moves. The day your diff logic disappears is the day the integration got simpler and faster at once.