folk’s API uses rate limits to safeguard against bursts of incoming traffic and help maximise its stability.

Rate limits are applied on a per-user basis. That means multiple API keys for the same user will share the same rate limit amount and reset window.

Every API response includes the following headers that you can use to track your current rate limit status:

  • X-RateLimit-Limit: The maximum number of requests you can make per minute.
  • X-RateLimit-Remaining: The number of requests remaining in the current rate limit window.
  • X-RateLimit-Reset: The time at which the rate limit will be reset in seconds since epoch.

If you exceed your rate limit, you will receive a 429 HTTP status code response and a Rate limit error containing the rate limit details.
A Retry-After header is also included in the response, indicating the number of seconds you should wait before making another request.

We currently apply a rate limit of 200 requests per minute to any API endpoint. We reserve the right to change this limit at any time.
You should always rely on the X-RateLimit-Limit and X-RateLimit-Remaining headers to track your rate limit status and handle rate limit errors gracefully.

​
Handling limiting gracefully

A basic technique for integrations to gracefully handle limiting is to watch for 429 status codes and build a retry mechanism using the Retry-After response header or the details.retryAfter property in the error response body. The retry mechanism should follow an exponential backoff schedule to reduce request volume when necessary. We’d also recommend building some randomness into the backoff schedule to avoid a thundering herd effect.