Stream disconnects or errors
Why a stream closes or returns 401, 402, or 429, why it can seem to skip events, and how to recover from each — including after a dropped connection.
The matches are flowing but the connection misbehaves. Match the symptom below.
The stream closes after a few minutes
This is normal. A stream closes with an end event once it hits timeout (default 300s, max 300)
or the limit you set:
event: end
data: {}Fix: reconnect to continue. Send the last event's id: back as the Last-Event-ID header to resume
from the next event — within the ~24h replay buffer you won't miss anything in between. See
Streaming.
I get a 401 from a browser EventSource
The native browser EventSource API cannot send custom headers, so it can't pass the
Authorization: Bearer token — every request comes back 401.
Fix: use the eventsource npm package or a fetch-based SSE client that supports headers. See the
code examples.
I get a 402 opening the stream
A 402 means the organization's prepaid balance is exhausted — new stream connections are refused
until you add credit.
Fix: top up from the Billing page. See How billing works for how matches draw down credit.
I get a 429
A 429 means a per-tap rate limit was exceeded: 30 stream connections/min and 60 rule
requests/min.
Fix: back off and retry. One long-lived connection that you reconnect on end is the intended
pattern — don't reconnect in a tight loop. See Errors & limits.
I dropped a connection and think I missed events
Events are buffered for roughly 24 hours, so a brief drop loses nothing if you resume correctly.
Fix: reconnect with the Last-Event-ID header (the browser EventSource does this automatically).
To deliberately catch up, use since (e.g. ?since=1h) or an exact offset.
Precedence is Last-Event-ID > offset > since > live tail.
Next steps
Streaming reference
Event types, parameters, and the full reconnection contract.
Errors & limits
Every status code and rate limit.