Subscribe to a channel, receive frames

One JSON object per frame, in both directions. Client frames are discriminated by op, server frames by ev. Binary frames are refused. Any upgrade path other than /stream is refused with the same envelope REST uses, so a wrong URL tells you it was wrong rather than hanging.

Everything is lazy. A channel nobody is watching is never produced, and an idle socket costs nothing. Every subscriber to a channel receives byte-identical frames, so two consumers of the same stream can never disagree about what arrived.

Webhook subscriptions are not here. They live on REST and MCP, by decision a socket you have to keep open is not what a webhook is for. If you want to be told about a condition while your process is down, use a subscription; if you want a live feed while it is up, use this.

Authentication and authorization are separate layers here: whether the socket opens at all is the question the card above answers, and what it may reach once open is the question X-PS-Scopes answers. Send it as a header on the upgrade request for /stream and the session is intersected with the grant the engine already holds. The header can only take capability away, never add it, so a key you have already narrowed stays narrowed however much the client asks for.

A session that subscribes outside its grant is answered with a SCOPE_DENIED error frame naming the scope it lacked, and the socket stays open, exactly like every other refusal on this page. The scope is checked before anything else about the frame is, so a capability you do not hold cannot be probed for by spelling.

Channels are canonicalised on parse platform lower-cased, symbol upper-cased and the ack carries the canonical name, so two spellings of one channel can never split into two registrations on your connection.

Market-typed channels serve tracked pairs only. Subscribing to a pair the engine is not watching earns not_favorited rather than a silent empty stream, and a kline or candles channel on an untracked timeframe earns unknown_timeframe with the tracked ones listed.

The global channels — orders, backtest and market-events carry no market type and no pair, so the tracked-pair rule does not apply to them at all; each is gated by a capability scope instead. They are also the only single-part channel names, which is why none of them takes a prefix.

A sectioned channel is a server-side filter, not a different stream: subscribing to one read gives you exactly the frames the unfiltered channel would have carried for that read, and nothing else. Subscribe to both and you get both the filter does not remove anything from the unfiltered channel.

Subscribing sends exactly one snapshot frame, and that frame is bounded: the most recent jobs on backtest, the most recent events on market-events. It is a starting position, not a history ask the matching REST route for anything older, and treat every frame after it as a patch to what you are already holding.

On the events channel the type field discriminates the frame: it is event for one the detector has just scored, and event-update when a repeat re-scores an event you already have, so a client keyed by event id updates in place rather than showing the same event twice.

A job frame carries one of these, plus a coarse phase name meant for display. The terminal ones are done, failed and cancelled: a job that reaches one of those sends nothing further, so it is safe to stop watching it.

The op takes the same parameters as the REST chart route — platform, marketType, symbol, timeframe, plus optional width, height, style, theme, indicators, bars and showVolume. Add id and it comes back on the reply; omit it and the reply is uncorrelated.

A render never blocks the rest of your socket: ops already in flight are answered first, and a render that outlives the connection that asked for it is discarded rather than written anywhere. A connection that asks for more renders than it is allowed to have in flight gets too_many_requests, not a dropped socket.