# Example with a rate limit of 60 (note default is 500)
$ curl https://api.intercom.io/users/56e1e5d4a40df1cc57000101 -v -H 'Accept: application/json' -H 'Authorization:Bearer <Your access token>' | python -m json.tool
HTTP/1.1 200 OK
Content-Type: application/json
ate: Fri, 17 Feb 2017 11:55:03 GMT
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 10
X-RateLimit-Reset: 1487332510
# After another request:
HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 17 Feb 2017 11:55:06 GMT
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 9
X-RateLimit-Reset: 1487332510
# 10 seconds later after window resets
HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 17 Feb 2017 11:55:14 GMT
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 10
X-RateLimit-Reset: 1487332520
# And if you make more than the 10 requests in 10 seconds
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Date: Fri, 17 Feb 2017 11:55:18 GMT
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1487332520
intercom.rate_limit_details
#=> {:limit=>180, :remaining=>179, :reset_at=>2014-10-07 14:58:00 +0100}
The API may rate limit submission of requests for your application. Such limits are managed as an allowed number of operations per time window, where an operation might be read or an update. In that case a '429 Too Many Requests' response code will be returned along with the following headers -
Rate Limit Headers
X-RateLimit-Limit: Maximum number of operations allowed in the current window
X-RateLimit-Remaining: Number of operations left in the current window.
X-RateLimit-Reset: Time when rate limit window will be reset as a Unix timestamp.
Note
- The default rate limit is 500 operations per minute per app.
- It is possible that some requests do not return Rate Limit Headers when we expire them (currently set at once a month). When this happens just send a subsequent request and the headers will be present
Update to rate limits
We recently updated our rate limiting monitoring process. The maximum number of operations you can perform in 1 minute has not changed (it is still 500). However, to prevent large spikes in traffic this total is now distributed over 10 second periods. This means for a rate limit of 500 per minute you can send a maximum of 83 operations per 10 second period (500/6).
If you have a large number of operations to perform you should break these into groups of 83 or less (assuming your rate limit is 500 per minute) and send these groups every 10 seconds. You can look at the example headers on the right to see how you can use these to know the remaining time and request you have in your current 10 second window
As of Feb, 2018 we've introduced a limit of 60 conversation_part creations per minute to avoid abuse in conversation replies.
For more information on how to best handle rate limits please see this blog post