Streaming (WebSocket)

When a Worker runs in Server mode, AiSpinner maintains long-lived WebSocket connections to supported exchanges and serves cached state to your code at near-zero latency. You don't write WebSocket code — you call the same REST-style methods, and the SDK transparently returns cached values where available.

Why It Matters

Calling ctx.binance.get_ticker("BTCUSDT") in a tight loop over REST would burn through rate limits and add 80–250 ms per call. With the WebSocket cache, that same call returns from in-memory state in sub-millisecond time, and the cache stays fresh because the server-side WS feed continuously pushes updates.

This is automatic in Server execution mode. In Browser mode, the SDK falls back to REST.

Supported Exchanges

Exchange	WS support	Cached methods	Notes
Bybit	✅	4/5 cached at 0 ms (ticker, balance, positions, orders)	Demo public stream uses live URL
Binance	✅	3 cached at 0 ms (ticker, account, positions)	Spot + futures streams
Deribit	✅	4/4 cached at 0 ms (ticker, account summary, positions, orders)	JSON-RPC auth
OKX	✅	ticker, orderbook, positions, orders, balance
Coinbase	✅	ticker + orders cached
Kraken	✅	ticker, orderbook, orders, balance
IG Markets	✅ Lightstreamer	ACCOUNT streaming at 0 ms	PRICE/CHART require IG streaming permissions on your account
Hyperliquid	REST only	—	Coming soon
Bitget	REST only	—	Coming soon
IBKR	REST only	—	Streaming via local Gateway
Polymarket	REST only	—

How to Enable

1. Open your Worker block.
2. In the Control tab, set Execution mode to Server.
3. Click Deploy and Start.

The server-side runtime opens WS connections on your behalf as soon as it sees a connected exchange block. The next tick() already gets cached data.

Some blocks require Server mode

Deribit, OKX, Coinbase, Kraken, and IG Markets are flagged serverOnly — Browser execution is disabled because their APIs don't tolerate browser-origin requests.

IG Markets — Lightstreamer

IG uses the Lightstreamer protocol rather than plain WebSockets. The SDK handles the LS handshake and exposes streaming data through the same ctx.ig.* methods plus a few WS-first variants:

Method	Behavior
get_accounts, get_positions, get_orders, get_market_info	Check WS cache first, fall back to REST
get_streaming_market(epic)	Return last L1 tick from cache (no REST fallback)
get_streaming_candles(epic, scale="1MINUTE")	Streaming candle aggregation
get_streaming_ticks(epic)	Raw tick history
get_trade_confirms()	Pending deal confirmations
add_streaming_epics(epics)	Subscribe to additional instruments at runtime

Rate-limit shield

IG's REST API is capped at 60 req/min. Lightstreamer caching effectively eliminates REST traffic for cached data, so you can poll ctx.ig.get_positions() every second without hitting the limit.

Caveats

• The cache is eventually consistent. For truly real-time correctness (e.g., placing orders based on the absolute latest tick), prefer the dedicated place_order flows that go straight to the exchange.
• A WS reconnect can briefly return stale data. If your strategy is millisecond-sensitive, check last_update fields where exposed.
• WS connections are shared per workspace per exchange — your worker doesn't pay a connection cost on top of other workers in the same workspace.