Register in bulk
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 returnscustomer_event_limit_exceeded in-band. Unregister events you no longer need:
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.clear_events
If the server loses its upstream feed it sendsclear_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 as06-multi-stream.py.
