Skip to main content
The Reap API is shared infrastructure. To keep it reliable for everyone, requests are rate-limited per project on rolling per-second, per-minute, and per-day windows. Limits apply to the project as a whole, not per API key.

​
Limits

Most endpoints share the default limit. A small set of write endpoints have tighter limits based on the downstream operations they trigger.
TierPer secondPer minutePer day
Default2030050,000
Card issuance101005,000
Card operations1525010,000
Company verification51502,000
SumSub token sync31805,000
Card issuance covers:
  • POST /cards
Card operations covers:
  • POST /cards/:id/freeze
  • POST /cards/:id/unfreeze
  • DELETE /cards/:id
  • POST /cards/:id/reveal
  • PUT /cards/:id/pin
Company verification covers:
  • POST /companies
  • POST /companies/:id/applications
SumSub token sync applies to specific SumSub integration endpoints. All other endpoints fall under the default limit.

​
Response headers

Every response includes the following headers so you can track usage without making extra requests.
HeaderDescription
RateLimit-LimitMaximum requests allowed in the current window
RateLimit-RemainingRequests remaining in the current window
RateLimit-ResetUnix timestamp (seconds) when the current window resets
RateLimit-PolicyIdentifier for the limit applied to this request
Legacy X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers are also returned for compatibility with older HTTP clients.

​
Exceeding the limit

When a request exceeds your limit, the API responds with 429 Too Many Requests:
  • The error body uses code: RATE_LIMIT_EXCEEDED.
  • A Retry-After header is set to the number of seconds to wait before retrying.
{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded. See the Retry-After header for when to retry."
  }
}
Wait at least the number of seconds in Retry-After before retrying. Earlier retries will simply receive another 429 until the window resets.

​
Best practices

  • Read the headers. Track RateLimit-Remaining to back off proactively before the limit hits zero.
  • Honor Retry-After. When you receive a 429, wait at least the indicated number of seconds before retrying.
  • Use exponential backoff with jitter. If you must retry beyond the first attempt, increase the wait between retries and add randomness to avoid thundering herds.
  • Spread out bulk operations. When onboarding many users or issuing many cards, pace requests against the per-minute and per-day limits rather than firing them as fast as possible.
  • Need higher limits? Contact the Reap team if your use case genuinely requires more headroom. We tune limits per project where it makes sense.