WebSocket tier limits are stream-specific capacity guidance: subscription count, replay speed, concurrency, message volume, and reconnection behavior. WebSocket limits depend on the plan envelope, channel mix, symbol count, replay speed, data family, and client processing capacity. A client can be inside account limits and still produce bad output if it cannot consume messages in order.Documentation Index
Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
Use this file to discover all available pages before exploring further.
Per-Tier Limits
| Tier | Max subscriptions | Max replay speed | Max connections | Bulk streaming | L3 / L4 channels |
|---|---|---|---|---|---|
| Build | 25 | 50× | 2 | — | — |
| Pro | 100 | 100× | 5 | ✓ | ✓ |
| Enterprise | 200 | 1000× | 10 | ✓ | ✓ |
Stream Limit Dimensions
| Dimension | What to watch |
|---|---|
| Subscription count | Number of active channel-symbol pairs |
| Replay speed | How fast historical events are emitted |
| Venue activity | Busy markets produce more messages |
| Data depth | L3 and L4 workflows are heavier than simple status checks |
| Consumer lag | Local queue depth and message processing delay |
| Reconnect behavior | Duplicate subscriptions or reconnect storms |
| Output storage | Whether replay output can be written fast enough |
Design Rules
Start with one channel
Confirm connection, auth, message handling, gap policy, and unsubscribe behavior with one channel-symbol pair.
Track active subscriptions
Store channel and symbol state so reconnects do not duplicate or lose subscriptions.
Measure consumer lag
Watch queue depth, processing time, and dropped UI updates before increasing channel count.
Plan Interaction
Use Rate Limits for current public plan envelopes and account-specific terms. Then design WebSocket clients as bounded consumers. The plan may allow a number of subscriptions, but your application still needs to process messages, rebuild after gaps, and avoid reconnect storms. If the workflow mixes REST preflights, WebSocket subscriptions, replay jobs, and SDK reconstruction, budget them as one product workflow. Do not size WebSocket in isolation from the data-quality and recovery calls that make the stream trustworthy.Agent Review Rule
Generated WebSocket code should not default to maximum subscriptions or maximum replay speed. It should ask for the channel set, symbol set, output destination, gap tolerance, and stop condition. If those are missing, generate a bounded sample instead of a broad run.Capacity Packet
Use this packet before raising stream limits or asking for a larger plan.| Field | Capture |
|---|---|
| Channel-symbol count | Active subscriptions and planned maximum |
| Replay speed | Requested speed, replay window size, and output destination |
| Consumer capacity | Queue depth, processing time, storage write rate, and dropped-message behavior |
| Recovery behavior | Reconnect cap, resubscribe list, gap policy, and rebuild path |
| Related calls | REST preflights, data-quality checks, SDK reconstruction, and export writes |
| Stop condition | Lag threshold, retry budget, storage failure, or data-quality failure |