Ory

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The main page's required code blocks are empty, its .md URL returned 404, and linked GitHub files complete the path. The prose names ORY_SDK_URL but the .env code block immediately below it sets NEXT_PUBLIC_ORY_SDK_URL, and the recovery and verification pages import "@/components/custom-card-header", a file the quickstart never tells you to create, so following the steps literally fails to build. The quickstart provides a complete 7-step path from blank project to running registration and login pages using Ory Elements with the App Router. Every file, command, and route is specified.

PARTIAL consensus from 3 PARTIAL.

New and legacy values differ by declared policy, but exact thresholds, shared counters, and 429 handling span four resources. The only page carrying exact per-tier, per-environment numbers renders them from client-side JavaScript, so a plain HTTP fetch returns the loading placeholder and no limits, while the still-published legacy table gives conflicting numbers for identical endpoints. The pricing page shows Unlimited users on all plans and aDAU-based billing, but no exact rate-limit numbers (burst RPS, sustained RPM) are published in the docs. The rate-limits blog post describes a bucket-based model without specific thresholds. An agent cannot find exact numeric limits.

PARTIAL consensus from 3 PARTIAL.

The fallback page failed extraction, and the main guide conflicts on id versus error without identifying safe display fields. The redirect, the fetch by id, and the browser-versus-API-client distinction are all documented, but the same page shows three incompatible response shapes for the same endpoint and never says which fields are safe to expose to an end user despite defining a debug key. The ory.config.ts includes an error_ui_url field pointing to /auth/error, but the documentation has no dedicated error-handling page explaining how to handle the redirect, read the error ID, expose safe fields, or distinguish browser errors from API-client errors. The error-handling pattern is documented only in a 2021 blog post and GitHub source code, not in the official developer portal.

PASS consensus from 3 PASS.

One guide covers after-registration setup, payload templating, Basic or API-key authentication, parsed responses, retries, and identity replacement. One page carries the whole path: Console creation steps, the YAML config keys, the Jsonnet request body, both auth types with mandatory fields, response ignore/parse/flow-interrupting handling, and the three-attempt retry policy. The webhook guide covers the full lifecycle: configuring an after-registration webhook via Ory Console, Jsonnet body templating with ctx.identity and ctx.flow, API key or Basic Auth for outgoing authentication, response parsing for identity modification, async fire-and-forget mode, flow interruption, and a retry policy of three attempts with 30-second timeout.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The SDK page installs @ory/client, and session guidance matches the toSession method documented for /sessions/whoami. The call and the cookie-versus-token distinction match the flow guidance, but no npm install command appears on the SDK page or the session page, and the same session page requires @ory/client-fetch in one tab and @ory/client in the next without saying which to install. The main SDK page at /docs/sdk lists the @ory/client npm package and links to the SDK reference, but does not show a code example for toSession(). The toSession() call is documented only in the OpenAPI reference at /docs/reference/openapi/to-session, which demonstrates server-side and token-based usage. An agent must cross-reference two pages to assemble the full call pattern.