Skip to main content

Quotas & Limits

BEAM® Data API offers two modes of access: real-time (REST) and asynchronous (WebSocket). The real-time API operates through quotas, while the asynchronous API has no such restrictions. This allows us to allocate fast (and expensive) compute resources based on predictable demand (based on your app's allocated quota), while our spare capacity can be used to serve asynchronous clients.

The Data API supports Webhooks, but these are also subject to quotas and offer a limited set of events to subscribe to. Instead, you should subscribe to events using the asynchronous API once you know when to expect them. For example, use Webhooks to listen for stream starting, then use a WebSocket to connect to the Data API and subscribe to all stream-related events.

Which One is Right for Me?​

If you need to take immediate action based on the Data API response (e.g., your app resolves a BEAM username and displays the channel name and profile picture) or you need to change the state in response to a user action (e.g., change stream title, send a chat message), then you should use the real-time API.

For all other use cases (e.g., waiting for the channel to go live, keeping track of the number of viewers, collecting the number of followers, reacting to an incoming tip, sending bot messages to chat) you should use the asynchronous API.

Quotas​

Quotas will be announced when we release the Data API out of private beta.

Limits​

Precise numbers will be announced when we release the Data API out of private beta.

Despite having no quotas, the asynchronous API is still subject to fair use and common sense policies. While BEAM could certainly push 5 Gbps worth of events through a WebSocket to your server, common sense tells us that it won't happen.

There will be special events sent to warn you about detected congestion on a WebSocket connection. Overflowing the sending buffer on our end will result in responses to your requests being silently discarded, so make sure you don't overcommit and subscribe to too many events over a starved WebSocket connection.

Similarly, opening 1,000 WebSocket connections is possible but should be avoided unless you are saturating them all.

When we have to restart the instance you are connected to, your client will receive an advanced notice and you will have some time to open a new connection, which will automatically start receiving all the events you have previously subscribed to.