Understand Ory Network rate limits

Rate limit changes

The way Ory calculates rate limits is changing. Customers who joined before March 1, 2026, keep their existing rate limits. New customers are subject to the updated calculation.

Ory uses rate limiting 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.
• 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.

Project rate limits use a bucket system to group endpoints and apply thresholds. Understanding how buckets work will help you interpret the project rate limit table below.

Project rate limits

Each project has a set of rate limit buckets. A bucket is a named group of API endpoints that share the same rate limit thresholds. When a request comes in, Ory resolves which bucket the endpoint belongs to and applies the threshold for that bucket.

Bucket thresholds are determined by two factors:

• Subscription tier: The project's subscription tier (Developer, Production, Growth, or Enterprise).
• Project environment: The project's environment (Production, Staging, or Development).

For a detailed explanation of tiers and environments, see our Workspaces and environments guide.

Bucket naming

Buckets follow a {service}-{access}-{cost} naming pattern. For example:

• kratos-public-low — lightweight public endpoints like GET /sessions/whoami
• kratos-admin-high — expensive admin operations like POST /admin/identities
• hydra-public-medium — moderate-cost endpoints like POST /oauth2/token

info

A bucket counter is shared across all endpoints in the same bucket. For example, POST /admin/relation-tuples and  DELETE /admin/relation-tuples both belong to keto-admin-high, so every call to either endpoint counts against the same limit. Plan your request volumes accordingly.

Rate limit structure

You will see two rate limits for each bucket:

1. Burst limit: Maximum requests per second (rps), allowing for short traffic spikes.
2. Sustained limit: Maximum requests per minute (rpm), ensuring consistent performance over time.

Monitor rate limit headers

Ory Network includes rate limit information in API response headers for project rate-limits. 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.

See How to handle 429 responses for an example of how to deal with potential 429 responses.

Calculate the rate limits that apply to your project

In the Project rate limit table below:

1. Select your subscription tier from the Tier dropdown. Options are Developer, Production, Growth, or Enterprise.
2. Select your project environment from the Environment dropdown. Options are Production, Staging, or Development.
3. To search by API path, enter the API path into the Search API path box. The endpoint appears highlighted. Look to see which bucket it belongs to for its rate limit.

Project rate limit table

Loading rate limits data…

Endpoint-based rate limits

Endpoint-based rate limits apply to individual API endpoints regardless of your project rate limits. They protect specific endpoints against brute-force and credential stuffing attacks, which typically originate from a limited set of IP addresses or JA4 fingerprints.

Benefits:

• Enhanced security: Restricts requests from specific sources, making attacks significantly harder to succeed
• Bot protection: Differentiates genuine users from harmful automated activity
• Granular control: Fine-tunes security for individual endpoints without compromising user experience

Types of endpoint-based protection

Ory implements two layers of endpoint-based protection:

Volumetric rate limits

Volumetric rate limits analyze incoming request patterns based on:

• Source identification: IP addresses and JA3/JA4 fingerprints
• Request frequency: Detects volumetric attacks and system overwhelm attempts
• Authentication status: Different limits for authenticated vs. unauthenticated requests
• HTTP method: Varying limits based on GET, POST, etc.

Inflight rate limits

Inflight rate limits protect critical endpoints from concurrent request attacks. By preventing multiple requests to the same resource at once, they eliminate race conditions, ensure data consistency, and let critical operations complete safely.

Protected endpoints

The following endpoints are protected by volumetric or inflight rate limits.

Type	Endpoint	HTTP Methods	Ratelimit Key	Action: enforced vs report-only
Volumetric				To be added later
Inflight	/admin/identities	POST, PATCH	{project_id} + {full_path}	Blocks concurrent requests (enforced)
Inflight	/admin/identities/{id}	PUT, PATCH, DELETE	{project_id} + {full_path}	Blocks concurrent requests (enforced)
Inflight	/admin/identities/{id}/credentials/{type}	DELETE	{project_id} + {full_path}	Blocks concurrent requests (enforced)
Inflight	/admin/identities/{id}/sessions	DELETE	{project_id} + {full_path}	Blocks concurrent requests (enforced)
Inflight	/admin/sessions/{id}	DELETE	{project_id} + {full_path}	Logs concurrent requests (report-only)
Inflight	/admin/sessions/{id}/extend	PATCH	{project_id} + {full_path}	Logs concurrent requests (report-only)
Inflight	/self-service/recovery	POST	{project_id} + {path} + "/" + {email|flow_id}	Logs concurrent requests (report-only)

Enforced-endpoints return HTTP 429 when the rate limit is exceeded. Report-only-endpoints currently only log rate limit

violations; they don't block requests. GET, OPTIONS, and HEAD requests are exempt from rate limiting. :::

Configuration and rule management

The endpoint-based rate limit rules are set and managed by Ory. These rules aren't directly configurable by customers.

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.
• Implement exponential backoff: When receiving a 429, pause and retry with increasing delays (for example: 1s, 2s, 4s, 8s).
• Respect rate limit headers: Check x-ratelimit-remaining and x-ratelimit-reset, when available, to throttle requests proactively.
• Avoid retry storms: Don't retry failed requests in a tight loop.

Exponential backoff strategy

Implement an exponential backoff strategy to proactively avoid hitting rate limits.

async function callApiWithBackoff(request, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(request)
    if (response.status === 429) {
      const delay = Math.pow(2, attempt) * 1000 // 1s, 2s, 4s, 8s, 16s
      await new Promise((resolve) => setTimeout(resolve, delay))
      continue
    }
    return response
  }
  throw new Error("Max retries exceeded")
}

See Monitor rate limit headers for information about how to monitor rate limit headers and throttle requests proactively.

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 and performance testing

Load testing, stress testing, and performance testing against Ory Network require prior written approval. Unauthorized load testing may be detected as abusive traffic and result in temporary blocking of your project or IP addresses.

For eligibility, request procedures, and requirements, see the Load Testing Policy.