Skip to main content
How many streams to open, Drop Copy resume tokens, and the reconnect-cancel loop: Streaming Best Practices. Not every stream starts with a snapshot. Drop Copy has no snapshot; reconnect with resume_token.

​
Streaming Semantics

Streaming APIs provide real-time updates over long-lived HTTP connections.

​
Delivery Guarantees

Are streaming APIs exactly-once? No. Delivery is at-least-once. This means messages may be delivered more than once, clients must be idempotent (handle duplicates), and you should use message IDs to deduplicate. Example deduplication:

​
Snapshots and Deltas

Do streams always start with a snapshot? No. Order stream and market data send a snapshot, then updates. Drop Copy, trade capture, and position change do not — they replay from resume_token or start live. See Streaming Best Practices. Example:

​
Stream Types

Market Data Streams: Order book updates, BBO (best bid/offer), instrument state changes Order Streams: Order status changes, execution reports, order lifecycle events Position Streams: Position changes, realized/unrealized P&L updates, risk metric changes Drop Copy Streams: Authoritative post-trade feed, executions and trades, settlement updates

​
Connection Management

Persistent connections: Streams use long-lived HTTP connections, not WebSockets (standard HTTP streaming), server pushes updates as they occur. Reconnection: Connections can drop due to network issues; implement automatic reconnection with exponential backoff. Example reconnection:

​
Resume Capability

Some streams are resumable: Persist resume state (token or sequence number), resume from last processed event after disconnect, avoid missing events during disconnection. Example resume:
Not all streams support resume. Check API documentation for each endpoint.

​
Message Ordering

Messages on a single stream are delivered in order. Messages across different streams may not be ordered relative to each other. If you need cross-stream ordering, use timestamps in messages, implement local ordering logic, and use sequence numbers where available.

​
Idempotency

Why is idempotency important? With at-least-once delivery, you may process the same message twice and your logic must handle duplicates gracefully. How to be idempotent: Track processed message IDs, use database unique constraints on IDs, design operations to be repeatable (e.g., “set to X” not “add Y”). Example idempotent order processing:

​
Rate Limiting on Streams

Client-to-server messages: Limited to 100 messages per second per firm (across all streams), averaged over a 1-minute window. Short bursts above this rate are allowed. Applies to requests you send (subscriptions, commands), does not apply to server-pushed updates. Connection limits: Maximum 20 concurrent streams per firm; plan your subscription strategy accordingly.

​
Snapshot Refresh

Some streams send periodic snapshots even if state hasn’t changed to help detect missed messages, allow clients to reconcile state, typically every few minutes. When you receive a snapshot, replace your entire local state with the snapshot; don’t try to merge or diff against previous state.

​
Troubleshooting

Missing messages: Possible causes include connection dropped (implement reconnection), resume state lost (persist resume tokens), at-least-once delivery issue (check for duplicates elsewhere). Solution: Use resumable streams and persist state. Duplicate messages: Expected behavior. Implement deduplication using message IDs. Stream stops sending updates: Check if the connection is still alive, send periodic heartbeats or test messages, implement connection timeout detection, reconnect if no messages received for X seconds. State inconsistency: If your local state doesn’t match server state, unsubscribe and resubscribe (forces new snapshot), reconcile with REST API query, or check for processing errors in your code.

​
Best Practices

Always handle reconnections: Network issues are inevitable. Auto-reconnect with backoff. Deduplicate messages: Track processed message IDs and skip duplicates. Persist resume state: Save tokens/sequence numbers to resume after restart. Monitor stream health: Detect stale connections and reconnect. Process snapshots correctly: Replace state, don’t merge. Use appropriate connection counts: Stay within the 20 concurrent-stream limit. See Rate Limits. Handle snapshot + delta pattern: Apply initial snapshot, then process deltas.