Rate Limiting
Rate Limiting
All API requests are subject to rate limits that exist independently of your API key's monthly usage allowance. FullContact APIs use HTTP headers to communicate to your application what its rate limit is and how quickly it’s being used.
The value returned in the response header X-FullContact-RateDelay is the number of milliseconds your request was delayed before it was processed in order to stay in your configured rate limit. If you begin to exceed your configured requests in a second, your responses will be delayed up to a maximum of 1000 milliseconds and the X-FullContact-RateDelay header will reflect how long it was delayed. If the time your request would need to be delayed in order to stay within your limit exceeds 1000 milliseconds a ‘429 Too Many Requests’ error will be returned. The '429' response code will be delayed by the maximum possible rate limiting latency. This delay allows you to safely, immediately retry the request.
In order to make this rate limiting feature backwards compatible, we will still return legacy HTTP headers but they will include static default values.
Our default rate limit is 6,000 QPM but should you need a higher rate limit contact our Sales team to get you setup.
| Rate Limit Headers | |
|---|---|
| X-FullContact-RateDelay | Indication of how much latency was added to the request to adhere to your rate limit in milliseconds.Example: 5 |
| X-Rate-Limit | The static rate limit ceiling for your request. Present to maintain backwards compatibility on older libraries.Example: 600 |
| X-Rate-Limit-Remaining | The static number of requests left in the 60-second window. Present to maintain backwards compatibility on older libraries.Example: 10 |
| X-Rate-Limit-Reset |
The static number of UTC epoch seconds remaining until the 60 second window resets. Present to maintain backwards compatibility on older libraries.
Example: 20 |
Updated about 3 years ago