Kinde Management API Rate Limits

Kinde rate limits incoming traffic to maximise API stability and prevent bursts of requests from destabilizing API functions.

If you send too many requests in quick succession, you’ll see error responses with status 429.

For advice on handling these errors, read the sections below. If you suddenly see a rising number of rate-limited requests, contact Kinde support.

What limiters does the Kinde API use?

Link to this section

Kinde applies two types of limiters: a rate limiter and a concurrency limiter.

Rate limiter

Link to this section

The rate limiter caps both request frequency and payload size. Key constraints:

• Page size: Maximum of 500 results per request on GET endpoints that accept a page_size parameter. Use page_size and next_token to paginate through additional results (e.g. GET /api/v1/subscribers).
• Bulk updates: Maximum of 100 objects per request on bulk POST/PATCH endpoints (e.g. PATCH /api/v1/organizations/{org_code}/users).

If your integration requires a higher limit for an extended period, contact Kinde support.

Concurrency limiter

Link to this section

The concurrency limiter caps the number of requests that can be in-flight at the same time. When this limit is reached, new incoming requests are shed and return a 429 response.

Resource-intensive requests — such as large list queries or requests that include expansions — consume more server resources and take longer to complete, which reduces available concurrency slots for other requests.

What causes rate limiting?

Link to this section

Rate limiting most commonly occurs in these scenarios:

• High request volume. Running a large number of closely-spaced requests — often as part of an analytical or migration operation — can trigger rate limiting. Control the request rate on the client-side when doing this.
• Long-lived or resource-intensive requests. Requests that consume significant server resources take longer to complete, leaving fewer concurrency slots available for new requests.
• List requests and expansions. These generally use more resources and run longer than other request types. Profile your Kinde API request durations and watch for unexpected timeouts.
• Sudden traffic spikes. Bulk operations like adding a large number of users at once can push you over the limit. If you anticipate an upcoming spike, contact Kinde support in advance to have limits increased.

How do I handle rate limiting gracefully?

Link to this section

When a request is rate limited, the API returns a 429 status code. The response includes a RateLimit-Reset header with the number of seconds until the rate limit resets:

HTTP/1.1 429 Too Many Requests
RateLimit-Reset: 30

Exponential backoff with jitter is the recommended retry approach. Wait progressively longer between retries and add randomness to avoid a thundering herd effect where many clients retry simultaneously:

async function fetchWithBackoff(url, options, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);

    if (response.status !== 429) return response;
    if (attempt === maxRetries) throw new Error('Max retries reached');

    const resetAfter = parseInt(response.headers.get('RateLimit-Reset') || '1', 10);
    const jitter = Math.random() * 1000;
    const delay = Math.max(resetAfter * 1000, Math.pow(2, attempt) * 1000) + jitter;

    await new Promise((resolve) => setTimeout(resolve, delay));
  }
}

Token bucket (global throttle): An alternative is to manage traffic at a global level using a token bucket algorithm on the client-side. This lets you cap your own outbound request rate before hitting the API. Mature token bucket implementations are available in most programming languages.