Stytch

PASS consensus from 2 PASS, 1 PARTIAL.

One React page covers the public token, authorized domain, provider, UI, redirect route, and active-session lookup without a gap. The React quickstart's config object passes products: [Products.emailMagicLinks, Products.oauth] with no emailMagicLinksOptions block, contradicting the configuration reference it links to, and three current pages initialize the same React client three different ways (createStytchClient(), new StytchClient(), new StytchUIClient()). Five-step guide for React covers project setup, SDK install, StytchProvider wrapping, StytchLogin component with config, and login-page routing with session redirect.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The page supplies both quotas and identifiers, but its second-to-day intervals conflict with its universal “top of the hour” rule. All four items sit on one page and agree: 60/hour/Project for Test SMS OTP sends, one request per second per email across the Send, Login or Create, and Invite email magic link endpoints, non-rolling top-of-the-hour intervals, and identifiers stated per limit (phone number and phone number prefix for SMS OTP, project_id for Create User, email for magic links), with each number appearing exactly once across the whole llms-full.txt corpus. SMS OTP quota (60/hour/Project) is explicitly Test-only, but the email magic link limit (1 req/sec/email across Send/LoginOrCreate/Invite) is stated without environment qualification, forcing the reader to guess whether it applies to Test, Live, or both.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The error pages cover diagnosis, backoff, and test values, but omit retry timing and explicit post-429 user messaging. Diagnosis via Dashboard Event logs, Test-environment guidance, and user-facing fallback-factor advice are all documented, but no Retry-After header or per-limit wait time is published, the 429 page's own sandbox-values link (/docs/docs#resources_testing) resolves to a login wall at https://stytch.com/docs/login?redirect=%2Fdocs, and the published backoff snippet disables the button with setOTPButtonDisabled(true) and re-enables it with setButtonDisabled(false), so as written the button never re-enables. Covers diagnosis (Event logs), exponential backoff with jitter (code example), test-environment/sandbox use, and user-facing UI cooldowns with alternative auth methods.

PARTIAL consensus from 3 PARTIAL.

Stytch covers registration, test delivery, and ordering, but signature verification and retry handling require linked Svix pages. Registration and ordering are documented well, but signature verification is delegated entirely off-site with no Stytch-side signing secret location, no svix-id/svix-timestamp/svix-signature header names and no code sample, the retry schedule is never stated (only Svix's 5-day auto-disable), and every trigger and payload example on the page is B2B (organization, member, saml_connection) with the Consumer user payload examples living instead on the migrations page at https://stytch.com/docs/resources/migrations/additional-migration-considerations, whose own "webhooks guide" link points at the API overview rather than the webhooks page. Registration, triggering, retries (5-day auto-disable), and ordering disclaimer are well-documented, but signature verification requires leaving Stytch docs to follow the Svix guide, the process is not self-contained.

PASS consensus from 3 PASS.

One Node quickstart sends and authenticates the link, stores session_jwt, and passes documented parameter names to session authentication. One page carries the whole flow including the redirect-URL prerequisite, npm install, .env keys, per-step snippets and a full runnable file, and every parameter matches the API reference schemas: email, login_magic_link_url and signup_magic_link_url on login_or_create, token and session_duration_minutes on magic_links/authenticate, and session_jwt on sessions/authenticate. End-to-end Express example matches the documented API parameters: loginOrCreate takes email + optional redirect URLs, authenticate returns session_jwt, and the route guard uses sessions.authenticate with the stored JWT.