Skip to main content

Connection Management

Best practices for maintaining reliable WebSocket connections.

Optional Handshake Headers

Sockets that will be used to submit signed transactions via the post method can opt into an alternative signature verifier on the WebSocket upgrade: Semantics:
  • Missing header: server uses the default raw canonical-binary verification path.
  • Invalid value: ignored safely (falls back to default raw verification).
  • Valid value: used only as an attempt-order hint. Signature validity still decides accept/reject.
  • The header is never trusted for authentication by itself.
  • Sockets posting transactions signed with the v0 Solana offchain envelope should set x-bulk-sig-mode: offchain.
The header has no effect on subscription-only sockets.

Subscription Management

Subscribe

Subscribe to one or multiple streams:
Response:
Save the topic strings for unsubscription.

Unsubscribe

Unsubscribe using the topic string:
Response:

Reconnection Strategy

WebSocket connections can drop due to network issues. Always implement reconnection logic.

Ping-Pong Keepalive (Required)

The server uses an explicit WebSocket ping/pong liveness check. You must respond to server pings with pongs or the connection will be closed. Client recommendations:
  • Respond immediately to ping frames with pong. Many WebSocket client libraries (e.g. Node.js ws) do this automatically; if yours does not, handle the ping event and send a pong.
  • Do not treat ping/pong as application messages -they are separate from subscribe, post, and data messages.
  • If you are disconnected due to a missed pong, reconnect and resubscribe to your topics.

Rate Limits

The public mainnet endpoint permits 15 concurrent connections per client IP and 45 new connection attempts/minute per IP. Each connection has a 32-action/second trading budget with a 96-action burst. Use reconnect backoff and prefer reusing connections. See Public API Rate Limits for full HTTP/WS limits and rejection handling.

Best Practices

Network issues are inevitable. Your application should automatically reconnect with exponential backoff.
After reconnecting, you must resubscribe to all channels. Store your subscription list.
Messages may arrive out of order during high load. Use timestamps and sequence numbers.
The server sends a ping every 30 seconds. If the client does not reply with a pong within 10 seconds, the server disconnects. Use a client that responds to ping (or handle it explicitly) and always implement reconnection.
If no application message is received for a long period, consider the connection stale and reconnect. Note: the server will already disconnect if pong is not sent within 10 seconds of a ping.
Enable per-message deflate for bandwidth savings on high-frequency streams.
Use one connection for market data and another for trading to avoid mixing concerns.

Connection States

Monitor connection state to handle different scenarios:

Error Codes

Common WebSocket close codes:

Monitoring Connection Health

Implement health checks to detect stale connections:

Multiple Connections

For high-throughput applications, consider using multiple connections:

Testing Connection

Test your WebSocket connection with a simple script: