By default, Front's API rate limit starts at 50 requests per minute and varies depending on your plan. Rate limits are enforced on a per-company basis rather than a per-token basis.
|50 rpm||100 rpm||200 rpm|
Rate limit increases beyond the default limits require the Scale plan, and may incur an additional charge. Rate limits are in place to protect our infrastructure and ensure the reliability of the platform for all customers.
Note that API requests made by a partner integration on behalf of a company via OAuth have a separate rate limit of 120 rpm (enforced on a per-company basis). This means that API requests made by integrations installed by a customer do not count against the customer’s rate limit (the only exception to this is the Zapier integration).
Front allows you to configure servers for authorization in your apps. The rate limit for making calls to these servers is 600 rpm.
Every API call response will contain three headers related to the rate-limiting:
|X-RateLimit-Limit||Maximum number of request allowed in the time window|
|X-RateLimit-Remaining||Current remaining number of requests in the current time window|
|X-RateLimit-Reset||Next timestamp when the number of remaining requests will be reset|
When the rate limit is exceeded, the server will respond with a 429 Too Many Requests HTTP code with the header
Retry-After to tell you how many seconds you need to wait before you can retry the request.
Refer to the Sample Application for an example of how to implement rate limiting in your integrations.
Some resource-intensive routes are subject to additional rate limiting to prevent strain on Front's infrastructure. This additional rate limit has a short TTL and only prevents sudden bursts of requests. The limit will depend on the resources needed to fulfill the request. Please see the list below.
Such resources have the header
X-Front-Tier. If you are rate limited at the resource level, you will receive the header
Retry-After, even though
X-RateLimit-Remaining may be greater than 0. This is because the limits do not affect each other.
Retry-After seconds before safely retrying the request. If you send subsequent requests before the
Retry-After window transpires, the delay is reset and slides further into the future, potentially increasing in length. The bottom line is you should never run up against rate limits as a default strategy, and if you do happen upon a rate limit unexpectedly, you need to honor the longest
Retry-After window without making any further requests.
Tier 1 - limited to 1 request / sec
Tier 2 - limited to 5 requests per resource per sec
Note that the Tier 2 rate limits are per resource and per endpoint — for example in the case of
POST /channels/:channel_id/messages you may POST up to 5 messages per conversation per second, and requests to
POST /channels/:channel_id/messages would not count against requests to
Some resource-intensive routes are subject to a additional rate limiting to prevent strain on Front's infrastructure. The proportional rate limiting reduces the rate limit for these particular endpoints to 40% of your company's global rate limit.
The following endpoints are affected:
Updated 7 days ago