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 Professional plan or higher. See our API rate limit add-on documentation for further details.

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. You will additionally receive the following headers:

Rate limited API response

If you exceed an API rate limit, you should expect to receive a JSON object response with a structure similar to this example;

{
  "_error": {
    "status": 429,
    "title": "Too Many Requests",
    "message": "Rate limit exceeded. Please retry in 44148 milliseconds."
  }
}

Example

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

Additional rate-limiting

Some resource-intensive routes are subject to additional rate guards to prevent strain on Front's infrastructure. These guards typically have short TTLs and limit sudden bursts of requests. The limit will depend on the resources needed to fulfill the request. Please see the list below.

Responses for rate-guarded requests carry the X-Front-Tier header. If a guard causes a request to be rejected, you will receive a 429 response with 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. Your integration should not intentionally encounter rate limits; if you do get rate-limited, you should observe the Retry-After header and avoid subsequent requests to the same guard bucket.

You can find more details about the per-resource guards below. The "Grouped By" column explains any additional group keys beyond the route and resource.