How to prevent rate limit errors

FAQs & Guides
1

Sendbird applications are rate-limited to ensure the best experience for all users. The rate limits vary depending on your plan’s allowed quota of monthly active users.Thus, the customer should abide carefully by their own rate limits. If you overlook this, you might encounter the error below.

Too many requests (scope: app, limit: 10;w=1, remaining: 0, retry_after: 0.069786548614502s, reset: 0.96978664398193s

To resolve the rate limit errors, you need to first be able to distinguish between the two types of rate limits: HTTP requests and SDK methods call.

HTTP requests:

  1. Your rate limit is decided based on your contract plan. You can validate your rate limit in each HTTP request.
  2. There are other stricter limits, which are applied on your applications regardless of your plan.

SDK methods call:

  1. An SDK function call can be regarded as a single limit of one user. This is because an SDK connection can be made once the user has been authenticated through WebSocket connection. Moreover, rate limits for SDK methods can be applied to all the customers regardless of their plans.
  2. To prevent abnormal user activity, we limit the number of messages per second to the channels with smart throttling by default(link). For example, if a user sends 10 messages to the channel at once(within one second), 5 out of 10 messages will be rate-limited. If 10 users send one message to the same channel at once (within one sec), 5 out of 10 messages will not be displayed in the chat, because we support smart throttling(link) for the channel.

Refer to the following best practices for rate limits.

  1. Delay each call request and retry to call based on the error message below when you have already hit the rate limit. It’s generally common to build three to five retry attempts.

Too many requests (scope: channel, limit: 10;w=1, remaining: 0, retry_after: 0.069786548614502s, reset: 0.96978664398193s)

  1. Optimize your code to eliminate unnecessary API/SDK calls, such as listing and looping through each instance.
  2. Avoid using a shared user. This will cause multiple concurrent requests.