Select your Platform:
Client SDKs
Backend SDKs
Rate Limits
Confused about "Rate Limits"?
Let us know how we can improve our documentation:
Stream powers chat and activity feeds for a billion end users. The tech is based on Go, RocksDB & Raft, and it scales well for some of the largest sites and apps. That being said, Stream does have rate limits to:
Prevent integration issues or abuse from impacting your application, as making many API requests also triggers client-side events and excessive calls could easily degrade your app's performance.
Prevent integration issues or abuse from using more capacity than is provisioned for your plan. This protects Stream infrastructure.
Identify integration issues early, like opening more than one WebSocket for a single user, long before cost or scale impacts become a significant challenge. This is equally helpful if your application experiences abuse, like bots generating users
Every Application has rate limits applied based on a combination of API endpoint and platform: these limits are set on a 1-minute time window. For example, reading a channel has a different limit than sending a message. Likewise, different platforms such as iOS, Android or your server-side infrastructure have independent counters for each API endpoint's rate limit.
What To Do When You've Hit a Rate Limit
Copied!Confused about "What To Do When You've Hit a Rate Limit"?
Let us know how we can improve our documentation:
You should always review responses from Stream to watch for error conditions. If you receive 429 status, this means your API request was rate-limited and you will need to retry. We recommend implementing an exponential back-off retry mechanism.
Here are a few things to keep in mind to avoid rate limits:
1. Slow down your scripts: This is the most common cause of rate limits. You're running a cronjob or script that runs many API calls in succession. Adding a small timeout in between API calls typically solves the issue.
2. Use batch endpoints: Batch update endpoints exist for many operations. So instead of doing 100 calls to update 1 user each, call the batch endpoint for updating many users.
3. (Re)render logic in your apps: Sometimes things like infinite pagination or other client-side logic goes wrong and ends up sending an endless number of API calls. Watch out for these mistakes.
4. Query only when needed: Sometimes apps will call QueryChannels
to see if a channel exists before creating it. This isn't needed you can simply create the channel since the endpoint behaves in an upsert fashion.
If rate limits are still a problem, Stream can set higher limits for certain pricing plans:
For Enterprise plans, Stream will review your architecture, and set higher rate limits for your production application.
For Standard plans, Stream may also raise rate limits in certain instances, an integration review is required to ensure your integration is making optimal use of the default rate limits before any increase will be applied.
Types of Rate Limits
Copied!Confused about "Types of Rate Limits"?
Let us know how we can improve our documentation:
There are two kinds of rate limits for Chat: app rate limits and user rate limits. App rate limits are calculated per endpoint and platform for your application.
Stream supports four different platforms via our official SDKs:
Server-side, like Go or Ruby clients
Android, including Flutter and React Native for Android clients
iOS, including Swift, Flutter, and React Native for iOS clients
Web, like React, or vanilla JavaScript clients
Rate limits quotas are not shared across different platforms. This way if by accident a server-side script hits a rate limit, you will not have any impact on your mobile and web applications.
When the limit is hit, all calls from the same app, platform, and endpoint will result in an error with a 429
HTTP status code. To avoid individual users consuming your entire quota, every single user is limited to at most 60 requests per minute (per API endpoint and platform). When the limit is exceeded, only requests from that user and platform will be rejected.
Rate Limit Headers
Copied!Confused about "Rate Limit Headers"?
Let us know how we can improve our documentation:
Header | description |
---|---|
X-RateLimit-Limit | the total limit allowed for the resource requested (i.e. 5000) |
X-RateLimit-Remaining | the remaining limit (i.e. 4999) |
X-RateLimit-Reset | when the current limit will reset (Unix timestamp) |
Inspecting rate limits
Copied!Confused about "Inspecting rate limits"?
Let us know how we can improve our documentation:
Stream offers the ability to inspect an App's current rate limit quotas and usage in your App's dashboard. Alternatively you can also retrieve the API Limits for your application using the API directly.
The Get Rate Limits endpoint includes the 1-minute limit, the remaining quota and the timestamp of the window reset.
1
2
3
4
5
6
7
8
// 1. Get Rate limits, server-side platform
limits, _ := client.GetRateLimits(stream_chat.WithServerSide())
// 2. Get Rate limits, all platforms
limits, _ := client.GetRateLimits()
// 3. Get Rate limits, iOS and Android
limits, _ := client.GetRateLimits(stream_chat.WithIOS(), stream_chat.WithAndroid())
// 4. Get Rate limits for specific endpoints
limits, _ := client.GetRateLimits(stream_chat.WithEndpoints("QueryChannels", "SendMessage"))
1
2
3
4
5
6
7
8
// 1. Get Rate limits, server-side platform
limits = await client.getRateLimits({ serverSide: true })
// 2. Get Rate limits, all platforms
limits = await client.getRateLimits()
// 3. Get Rate limits, iOS and Android
limits = await client.getRateLimits({ ios: true, android: true })
// 4. Get Rate limits for specific endpoints
limits = await client.getRateLimits({ endpoints: ["QueryChannels", "SendMessage"] })
1
2
3
4
5
6
7
8
# 1. Get Rate limits, server-side platform
limits = client.get_rate_limits(serverSide: true)
# 2. Get Rate limits, all platforms
limits = client.get_rate_limits()
# 3. Get Rate limits, iOS and Android
limits = client.get_rate_limits(ios: true, android: true)
# 4. Get Rate limits for specific endpoints
limits = client.get_rate_limits(endpoints: ['QueryChannels', 'SendMessage'])
1
2
3
4
5
6
7
8
// 1. Get Rate limits, server-side platform
$limits = $client->getRateLimits(true)
// 2. Get Rate limits, all platforms
$limits = $client->getRateLimits()
// 3. Get Rate limits, iOS and Android
$limits = $client->getRateLimits(false, true, true)
// 4. Get Rate limits for specific endpoints
$limits = $client->getRateLimits(false, false, false, array("QueryChannels", "SendMessage"))
1
2
3
4
5
6
7
8
// 1. Get Rate limits, server-side platform
var limits = await client.GetRateLimits(new GetRateLimitsOptions().WithServerSide())
// 2. Get Rate limits, all platforms
var limits = await client.GetRateLimits(new GetRateLimitsOptions())
// 3. Get Rate limits, iOS and Android
var limits = await client.GetRateLimits(new GetRateLimitsOptions().WithIOS().WithAndroid())
// 4. Get Rate limits for specific endpoints
var limits = await client.GetRateLimits(new GetRateLimitsOptions().WithIOS().WithAndroid().WithEndpoint("QueryChannels").WithEndpoint("SendMessage"))
1
2
3
4
5
6
7
8
# 1. Get Rate limits, server-side platform
limits = client.get_rate_limits(server_side=True)
# 2. Get Rate limits, all platforms
limits = client.get_rate_limits()
# 3. Get Rate limits, iOS and Android
limits = client.get_rate_limits(ios=True, android=True)
# 4. Get Rate limits for specific endpoints
limits = client.get_rate_limits(endpoints=["QueryChannels", "SendMessage"])