Rate limits

Standard rate limits

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.

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.

Rate limits for the integrations you use / Partner rate limits

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).

Rate limits for the servers you connect to your apps

Front allows you to configure servers for authorization in your apps. The rate limit for making calls to these servers is 600 rpm.

Monitor your rate limit with API headers

Every API call response will contain three headers related to the rate-limiting:

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.

Example

Refer to the Sample Application for an example of how to implement rate limiting in your integrations.

Additional "burst" rate-limiting

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.

Please wait 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

• POST /analytics/exports
• POST /analytics/reports

Tier 2 - limited to 5 requests per resource per sec

• PATCH /conversations/:conversation_id
• PUT /conversations/:conversation_id/assignee
• POST /channels/:channel_id/messages
• POST /conversations/:conversation_id/messages
• POST /channels/:channel_id/incoming_messages
• POST /channels/:channel_id/inbound_messages
• POST /channels/:channel_id/outbound_messages
• POST /inboxes/:inbox_id/imported_messages
• PATCH /teammates/:teammate_id

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 POST /inboxes/:inbox_id/imported_messages.

Additional proportional limiting

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:

• GET /conversations/search/:query