To ensure reliable performance for all users and help protect our system from overload, we apply rate limiting to our incoming channels by controlling the number of requests that can be made to a channel within a specific time period. This allows us to maintain stability, prevent abuse, and ensure fair usage across all integrations.
In this article, we’ll explain how our rate limiting works and what limit options there are.
HTTP channels
HTTP channels use a token bucket rate-limiting system. When the bucket is full, it can process a burst of messages up to a defined limit. Tokens are gradually replenished over time at a fixed rate, allowing a steady flow of messages.
If the number of incoming messages exceeds the available tokens, the excess messages will be rejected until more tokens become available.
Rejected messages will return a 429 Too Many Requests response.
To avoid the 429 error, a queue can be enabled. When active, it allows messages that would otherwise be rejected to be held temporarily and processed once tokens are replenished. The maximum queue size depends on how many requests your current throughput level allows within one hour.
Queued messages will return a 202 Accepted response.
When sending HTTP requests, you can see your current values in the following headers:
x-rate-limit-limit
x-rate-limit-queue-limit
x-rate-limit-queue-queued
x-rate-limit-remaining
x-rate-limit-windowHTTP throughput limits
Three different limit sizes can be enabled for each channel: small, medium, and large. The table below shows the current limits.
| Limit | Messages per minute | Replenish rate | Maximum queue size |
| Small | 60 | 10 every 10 seconds | 3 600 |
| Medium | 300 | 50 every 10 seconds | 18 000 |
| Large | 600 | 100 every 10 seconds | 36 000 |
Other channels
While HTTP channels use a bucket token system, other channels use a fixed window rate-limiting system, where message processing is divided into 10-second intervals. In each interval, the channel can handle up to a number of messages decided by your current limits.
The queue will be enabled by default for these channels and follows the same rules as the queue for HTTP channels; the maximum size of the queue is relative to how many requests your current throughput limits allow in one hour.
Messages that exceed the window- and queue limits are rejected.
Other throughput limits
| Limit | Messages per minute | Replenish rate | Maximum queue size |
| Small | 60 | 10 every 10 seconds | 3 600 |
| Medium | 300 | 50 every 10 seconds | 18 000 |
| Large | 600 | 100 every 10 seconds | 36 000 |