You're encountering a 429 "Too Many Requests" error when calling the

ToSession()

function in the Ory Go client SDK. This indicates you've hit the rate limits for your Ory Network project. ## Understanding the Rate Limits Ory Network implements two types of rate limits: 1. Project rate limits: Based on your subscription plan and project environment 2. Endpoint-based rate limits: Specific to individual endpoints like

/sessions/whoami

(which is what the

ToSession()

function calls) For the

/sessions/whoami

endpoint specifically, the rate limits vary by subscription plan: - Developer plan: 10 requests per second (burst), 300 requests per minute (sustained) - Production plan: 80 rps (burst), 1800 rpm (sustained) for Production environments - Growth plan: 800 rps (burst), 18000 rpm (sustained) for Production environments - Enterprise plan: 1200 rps (burst), 36000 rpm (sustained) for Production environments Note that Staging and Development environments have lower limits than Production environments. [Understand Ory Network rate limiting](https://www.ory.sh/docs/guides/rate-limits) ## Solutions to Address Rate Limiting 1. Implement caching: Add a caching mechanism to reduce the number of calls to the

/sessions/whoami

endpoint. Even a short TTL (~1s) can significantly reduce the number of requests. 2. Upgrade your subscription plan: If you consistently need higher limits, consider upgrading to a higher tier plan (Production, Growth, or Enterprise). 3. IP Whitelisting (for Enterprise and Growth plans): You can whitelist internal IPs to get higher rate limits for legitimate high-volume traffic. To do this, create a support ticket with Ory through the [Ory Console](https://console.ory.sh/support). 4. Check your environment: Ensure your project is in the correct environment (Production vs. Staging/Development) as this affects your rate limits. 5. Optimize your code: Review your implementation to ensure you're not making unnecessary calls to the

ToSession()

function. [Project Rate Limits in Workspaces](https://www.ory.sh/docs/guides/rate-limits#project-rate-limits-in-workspaces) If you're using Oathkeeper with the

cookie_session

authenticator, note that there's a known issue where Oathkeeper returns a misleading 401 error when the

/sessions/whoami

endpoint returns a 429 status due to rate limiting. This might be relevant to your situation if you're using Oathkeeper. [Oathkeeper returns a 401 when exceeding rate limiting](https://github.com/ory/oathkeeper/issues/1167)

Enabling Edge Sessions (the caching strategy) can significantly reduce the likelihood of hitting rate limits for the

/sessions/whoami

endpoint, but it doesn't completely eliminate the possibility. ## How Edge Sessions Help with Rate Limits When you enable Edge Sessions, Ory implements a planet-scale network edge cache for the

/sessions/whoami

endpoint that: - Serves cached session data immediately when session credentials are known and cached - Refreshes the cache in the background - Respects the

Cache-Control: max-age=60

header - Automatically refreshes the session in the cache when users update their profile or add authentication factors This caching mechanism can dramatically reduce the number of actual API calls that count against your rate limits because many requests will be served from the cache rather than hitting the backend API. [Low latency with Edge Sessions](https://www.ory.sh/docs/concepts/cache) ## Performance Benefits With Edge Sessions enabled, you can expect: - P95 latency of ~35ms - P99 latency of ~45ms across the globe ## Configuration By default, Edge Sessions is turned off for all projects. You need to enable it in your configuration:

yaml feature_flags:   cacheable_sessions: true   cacheable_sessions_max_age: "1m"

The default cache time is 2 minutes and 30 seconds, but you can modify this value. Longer cache times mean faster API responses but potentially outdated session data. [Edge Sessions Configuration](https://www.ory.sh/docs/concepts/cache#configuration) ## Important Considerations Even with Edge Sessions enabled: 1. You're still subject to rate limits, but you'll hit them less frequently 2. For requests that bypass the cache (e.g., using

Cache-Control: max-age=0

), you'll still be counting against your rate limits 3. Initial requests that populate the cache will count against rate limits If you're experiencing extremely high traffic volumes, you might still need to consider upgrading your subscription plan or implementing additional caching strategies in your application. Remember that you can force refresh the cache when needed by setting

Cache-Control: max-age=0

, but this will increase your API calls and could contribute to hitting rate limits.

Based on the knowledge sources provided, there isn't specific information about the maximum allowed TTL (time-to-live) value for Edge Sessions in Ory Network. The documentation mentions that the default cache time is set to 2 minutes and 30 seconds (which would be "2m30s" in configuration format), but it doesn't explicitly state an upper limit for this value. The documentation does indicate that you can modify this value either through the Ory Console or using the Ory CLI by configuring the

cacheable_sessions_max_age

parameter:

yaml feature_flags:   cacheable_sessions: true   cacheable_sessions_max_age: "1m"

In this example, the cache TTL is set to 1 minute [Low latency with Edge Sessions](https://www.ory.sh/docs/concepts/cache#configuration). The documentation also explains the trade-off with cache TTL settings: - Longer cache times: Faster API responses but potentially outdated session data - Shorter cache times: More up-to-date session data but slower API responses If you need to know the absolute maximum allowed value for the Edge Session cache TTL, I would recommend: 1. Checking the latest Ory documentation 2. Contacting Ory support directly 3. Testing with increasingly larger values in your configuration to determine any practical limits Remember that you can always force a cache refresh by using the

Cache-Control: max-age=0

header with your requests when you need the most up-to-date session data.

Based on the knowledge sources provided, there isn't specific information about viewing logs specifically for edge session caching in Ory. However, I can provide some general information about logging in Ory that might be relevant to your question. Ory's logging system sends output to stdout/stderr and can be configured to provide different levels of detail and formats. The logs include an "audience" field that distinguishes between "application" logs (for operators and developers) and "audit" logs (for authentication events, authorizations, etc.). For general logging in Ory self-hosted deployments, you can configure: - Log level (panic, fatal, error, warn, info, debug, trace) - Log format (text or JSON) - Whether to leak sensitive values (should be false in production) [Logs and audit trails](https://www.ory.sh/docs/self-hosted/operations/logging) If you're specifically looking to monitor edge session caching behavior, you might want to: 1. Set your log level to "debug" or "trace" to get more detailed information 2. Look for logs related to session operations 3. Check for HTTP request context in the logs which might indicate cache hits/misses There's also a feature for distributed tracing that could help visualize request paths, which might provide insights into caching behavior: [Distributed tracing](https://www.ory.sh/docs/self-hosted/operations/tracing) For more specific information about viewing edge session caching logs, you might need to contact Ory support directly as this information doesn't appear to be covered in detail in the provided knowledge sources.

Based on the knowledge sources, edge session caching doesn't reuse existing session cookies after a user logs out and then logs back in. When a user logs out, their session is terminated, and a new session cookie is created when they log in again. When a user logs out, Ory invalidates the session, marking it as inactive. The edge session cache might still return the session as active for a short period (until the cache expires or is refreshed), but the session itself is terminated. As mentioned in the documentation: > When revoking a session using the Ory Console or the admin API, the session will be marked as inactive immediately. However, the

/session/whoami

endpoint might still return the session as active for a short period of time. [Low latency with Edge Sessions](https://www.ory.sh/docs/concepts/cache#impact-on-business-logic) When a user logs in again after logging out, a completely new session is created with a new session cookie. This is evident from the login flow documentation which shows that upon successful login, Ory issues a new session cookie:

HTTP/1.1 303 See Other Cache-Control: 0 Location: <http://127.0.0.1:4455/> Set-Cookie: csrf_token=b8OebRPTPr5ow23mA5gIZmFNLeuMbv8pZz1jT1Ex7ys=; Path=/; Domain=127.0.0.1; Max-Age=31536000; HttpOnly Set-Cookie: ory_kratos_session=MTU5OTE2ODc2N3xEdi1CQkFFQ180SUFBUkFCRUFBQVJfLUNBQUVHYzNSeWFXNW5EQThBRFhObGMzTnBiMjVmZEc5clpXNEdjM1J5YVc1bkRDSUFJR055VlROMGRteHhSakJrUzBkbmRUUjBlVFY1V0RCRWFVTnJXVmR6V25oaHx2DICsB6IMbaHSQwnYITUZqr7Qx7CxUlnaneJWH495wQ==; Path=/; Expires=Fri, 04 Sep 2020 21:32:47 GMT; Max-Age=86400; HttpOnly; SameSite=Lax

[Successful login](https://www.ory.sh/docs/kratos/self-service/flows/user-login#successful-login) The edge session caching mechanism is designed to cache the current active session for performance reasons, but it doesn't persist or reuse terminated sessions after logout and new login events.