Firehose
Troubleshooting

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.

View as Markdown

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