Rate limiting

Check's API is gated by a standard throttling policy. By default, Partners can make 25 requests/second 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 1 second."
    }
}

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

In addition to the requests/hr limit, Check also enforces a concurrency limit of 50 open requests per Partner. Similar to the above, this will also result in a 429 HTTP response status code, though the message will contain a static 60 second Retry-After header as the true known next availability period is non-deterministic (60s is the max time for all in-flight requests to time out). In practice this threshold is only reached when doing significant bulk operations, backfills, or data syncs. To avoid this behavior, Partners should rely on webhooks whenever possible to keep local data in sync with changes made in Check.

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 throttle, 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 Retry-After 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. Throttles 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 developer support to request a limit increase.