---
title: "Resumable real-time event stream (SSE)"
method: GET
path: "/api/v1/stream"
tags: ["Streaming"]
---

# Resumable real-time event stream (SSE)

`GET /api/v1/stream`

Server-Sent Events stream of the live feed envelopes the platform already broadcasts (whale-trade pulses and other public/Pro feed events). Forwards the same backend-owned envelope shape as the internal feed; no provider data is recomputed. Authenticated via the oxi_sk Bearer key like every other /api/v1 endpoint, and limited to a small number of concurrent connections per API key and a cluster-wide ceiling across all keys (HTTP 429 with Retry-After when either cap is exceeded; HTTP 503 with Retry-After if the admission backend is briefly unavailable). Each delivered frame carries an SSE id equal to the envelope sequence; reconnect with the Last-Event-ID header (or the last_event_id / seq query fallback) to replay the missed window before resuming live. When the requested resume point predates the retained window the stream emits one resync marker event (event: resync) instead of silently skipping frames. Idle connections receive periodic ': keep-alive' comment lines. This is a long-lived response: keep the connection open and read frames as they arrive.

## Query parameters

- `last_event_id` string
- `seq` string
- `event` string
- `condition_id` string
- `min_grade` 'S' | 'A' | 'B' | 'C' | 'D' | 'F'

## Headers

- `Last-Event-ID` string

## Response `200`

Open Server-Sent Events stream. The body is an unbounded text/event-stream of frames; each data frame is a JSON feed envelope (with seq, published_at, type, and event-specific fields) and carries an SSE id equal to seq. resync marker frames use event: resync.

## Other responses

- `400` — Invalid request parameter
- `401` — Missing or invalid API key
- `402` — Active Pro subscription required
- `403` — Account access denied
- `423` — Account is locked
- `429` — Rate limit exceeded. Two independent budgets. (1) 100 requests/minute per user (sliding window), on every authenticated route. (2) On the BATCH routes only: 2500 batch item units/minute per user, reserved before any item is executed. A batch with N requested items costs N item units, including duplicate and invalid items. 2500 = 100 requests x 25 items per batch, which is the most item work a key can buy through the request limiter at all: a caller may spend their entire 100-request minute on full 25-item batches without the item budget being what stops them. The REQUEST budget is the effective ceiling, and batching is never the more expensive choice. The item budget can still deny at a sliding-window boundary (both counters carry the previous window forward with a floor, and the item counter runs 25x the request counter), so honor a 429 from either. Over-quota batches return 429 with Retry-After before any item work is done.
- `503` — Redis-backed authenticated rate limiter unavailable; retry after the per-process outage cooldown

---

[API](https://skmtc.net/0xinsider/apis/0xinsider-api.md) · [All operations](https://skmtc.net/0xinsider/apis/0xinsider-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/0xinsider/0xinsider-api/versions/918e082b045a/schema)