Skip to main content
Register many events on one socket. Do not open a socket per event.

Register in bulk

Each registration answers with an offer snapshot and an ok response. Registering an event with no prices returns an empty snapshot, not an error.

The cap

The registered-event cap is counted across all your connections, not per socket. Exceeding it returns customer_event_limit_exceeded in-band. Unregister events you no longer need:
The server also sends an info entry every few seconds. Its registered_events field is the count on this connection. Registering an event you already hold returns already_registered.

Read fast

If you read too slowly, the server closes the connection with code 1008. A client that has stopped reading never receives that frame and sees only a raw TCP close. If you do heavy work per message, hand frames to a queue and process them off the read loop.

Reconnect and re-register

Registrations do not survive a reconnect. A silent drop looks like a clean EOF, so treat any exit from the read loop as a reconnect trigger.
Rebuild your book from the fresh snapshot after each reconnect. Do not assume your cached state survived.

clear_events

If the server loses its upstream feed it sends clear_events. Drop every event, offer and in-play state you hold. A fresh snapshot and sync follow when the feed recovers. If offers for an event do not resume after that sync, send list_registered_events and register the event again.

Multiple processes

All your sockets share one registered-event cap. REST calls from every process share one rate-limit budget for the account. The stream itself has no message-rate limit. If you run several processes, give each its own API key so you can revoke one without stopping the rest, and coordinate registrations so they do not fight over the cap. The runnable version of this pattern lives in the Claude skill repository as 06-multi-stream.py.