Reconnection
hypernode WebSocket connections can drop due to server restarts, network issues, or idle timeouts. Your client must handle reconnection.Basic pattern
Python
Key rules
Re-subscribe on every reconnect
Subscriptions are not persisted across connections. After reconnecting, you must send your subscribe messages again. Keep your subscription configs in a variable so you can replay them.No replay or gap-fill
hypernode does not replay missed events during a disconnection. If your connection drops for 5 seconds, events during that window are lost. Design your application to tolerate gaps. If you need guaranteed delivery, combine the stream with periodic REST API polling:Exponential backoff with jitter
Don’t reconnect immediately in a tight loop. Use exponential backoff (1s, 2s, 4s, 8s, …) with random jitter to avoid thundering herd problems.Error responses
HTTP errors during handshake
WebSocket errors after connection
Subscription errors are delivered as JSON messages:Rate limits
- Connections per key: determined by your tier (1 for free, 5 for starter, up to 500 for enterprise)
- Subscriptions per connection: determined by your tier
- Messages: no rate limit on inbound subscribe/unsubscribe messages
- Events delivered: no throttling, you get everything matching your filters
Health checks
If you need to verify the service is up before connecting:{"status":"ok"} when the stream service is running.