Skip to main content
WebSocket connections drop. Networks fail. Rate limits hit. This guide covers how to build a resilient client.

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:
Handle these in your message handler:

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:
Returns {"status":"ok"} when the stream service is running.

Browser clients

If running in a browser, handle tab visibility to avoid wasting resources: