Ory Network rate limits - new

info

There is a new project rate limit policy, which applies to all new Ory Network customers and to existing customers after they've been migrated. If you're an existing customer and haven't received a migration notice yet, see the rate limits - legacy. See Rate limits to learn about both policies and the migration plan. Endpoint-based rate limits have not changed.

Ory uses rate limits to protect your applications against abuse, attacks, and service disruptions, and to maintain fair resource allocation and network stability.

Types of rate limits

Ory uses two types of rate limits:

• Project rate limits: Control the overall request volume your projects can make to Ory APIs, based on your subscription tier and project environment. See Project rate limits for more information.
• Endpoint-based rate limits: Control traffic to individual endpoints to protect against volumetric attacks, brute-force attempts, and concurrent request abuse—regardless of your project rate limits. See Endpoint-based rate limits for more information.

Monitor rate limit headers

Ory Network includes rate limit information in API response headers. Use these headers to avoid exceeding the applicable rate limit. Your client must handle these responses to maintain service quality.

Header	Description
x-ratelimit-limit	The rate limit ceiling(s) for the current request, including burst and sustained limits
x-ratelimit-remaining	Number of requests remaining in the current window
x-ratelimit-reset	Number of seconds until the rate limit window resets

Example header values:

x-ratelimit-limit: 10, 10;w=1, 300;w=60
x-ratelimit-remaining: 8
x-ratelimit-reset: 1

The x-ratelimit-limit header follows the IETF RateLimit header fields draft, where w=1 indicates a 1-second window and w=60 indicates a 60-second window. Use these headers to throttle requests proactively and reduce the likelihood of hitting 429 errors.

How to handle 429 responses

When your client receives a 429 Too Many Requests response, you've exceeded the applicable rate limit. Your client must handle these responses to maintain service quality.

Your implementation must:

• Detect 429 responses: Monitor for HTTP 429 status codes on all API calls.
• Back off before retrying: Prefer the server's x-ratelimit-reset header when available; fall back to exponential backoff capped at 30 seconds. Always add jitter so concurrent clients don't retry in lockstep.
• Throttle proactively: Check x-ratelimit-remaining and x-ratelimit-reset to slow down before you hit a 429.
• Avoid retry storms: Don't retry failed requests in a tight loop.

Exponential backoff strategy

When a request returns 429, back off before retrying. Prefer the server's x-ratelimit-reset header when it's present, fall back to exponential backoff capped at 30 seconds otherwise, and always add jitter so concurrent clients don't retry in lockstep.

async function callApiWithBackoff(request, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(request)
    if (response.status !== 429) return response

    const resetAfter = response.headers.get("x-ratelimit-reset")
    const baseDelay = resetAfter ? parseInt(resetAfter, 10) * 1000 : Math.min(Math.pow(2, attempt) * 1000, 30000) // cap at 30s

    const jitter = Math.random() * 1000
    await new Promise((resolve) => setTimeout(resolve, baseDelay + jitter))
  }
  throw new Error("Max retries exceeded")
}

You can also throttle proactively using x-ratelimit-remaining to slow down before hitting a 429:

async function callApiWithThrottle(request) {
  const response = await fetch(request)
  const remaining = parseInt(response.headers.get("x-ratelimit-remaining"), 10)
  const resetIn = parseInt(response.headers.get("x-ratelimit-reset"), 10)

  if (remaining < 5 && resetIn > 0) {
    const paceDelay = (resetIn * 1000) / Math.max(remaining, 1)
    await new Promise((resolve) => setTimeout(resolve, paceDelay))
  }
  return response
}

Clients that repeatedly exceed rate limits without proper backoff may have their API access temporarily blocked. For high-volume use cases that exceed your plan's limits, open a support ticket via the Ory Console or email support@ory.sh.

Load testing

Load testing against the Ory Network requires prior written approval. Unauthorized tests will be detected and may result in temporary blocking. To request an approved window, open a support ticket via the Ory Console or email support@ory.sh.