Rate limiting

Check's API is gated by a standard rate limiting policy. By default, Partners can make a combined 10,000 requests/hr to the API. This limit is shared by all API keys issued to a given Partner. As described in the Error codes section, a request that has been limited will return a message indicating as such along with a 429 HTTP response status code. The response will detail when throttling will subside. For example:

{
    "error": {
        "type": "throttled",
        "message": "Request was throttled. Expected available in 53 seconds."
    }
}

The response will also include a Retry-After header with the raw expected availability value (this is the easier place to locate that value for automatic retries rather than parsing the message string itself).

The goal of this limit is to protect Check and its Partners from programatic errors and/or malicious activity. API clients should account for the rate limit, likely in one of two ways. Clients can internally track number of requests over time and attempt to throttle themselves to stay under the limit. Or, clients can simply implement automatic retries for 429 responses that ideally take into account the provided availability timeframe. In either case, accounting for automatic retries is ideal, as it may be difficult to perfectly track usage rates internally in circumstances where requests originate from multiple sources. Rate limits may also change over time, so programmatically preparing for that ahead of time may save maintenance cost in the future.

Should the default limit be insufficient for your valid use, please contact support to request a limit increase.