Skip to main content

3.3 Creating an Asynchronous Stream

A new asynchronous stream may be started by connecting a WebSocket to:

wss://api.mollybet.com/v1/stream/?token=TOKEN

where TOKEN is the session identifier returned by login.

As soon as a stream is connected, the client will automatically receive some initial state, which includes the current currency exchange rates, the connected customer's MollyBet balance, and a list of all the events we have offers for. This end of this operation is marked by the sync message.

It should be noted that that all connected WebSockets are completely independent from each other. Registering for offers on an event in one WebSocket causes the offers to be received only in that WebSocket, not in any other WebSockets. Different WebSockets can register to different events. Moreover, the list_registered_events command returns only the events registered in that WebSocket.

But keep in mind that, for the purpose of registered events limits checking, what counts is the aggregate number of registered across for a MollyBet group, regardless of how many users and how many WebSockets the event registrations are spread over.

Note: as explained in login, API sessions expire automatically after 24 hours of no activity, and websocket commands do not count as activity for this purpose. If you create a session just for websocket usage, you should send a normal HTTP request at least once every 24 hours.

Note 2: there is a hard limit of 16 websocket connections per username.

3.3.1 Refused connections

If the stream cannot be opened, the WebSocket handshake fails with a plain HTTP response instead of an upgrade.

StatusBodyWhat to do
400missing_credentialsAdd the token query parameter.
401auth_rejectedThe session does not exist or has expired. Log in again for a new token. Reconnecting with the same token will fail again.
403forbiddenThe token is not an API session. Use a token returned by the API login.
503unavailableA temporary failure on our side. Retry after a short delay.

Most WebSocket libraries report a failed handshake together with the HTTP status. Check that status before reconnecting, so that an expired session does not turn into a reconnect loop.