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