WorkOS

PASS consensus from 2 PASS, 1 PARTIAL.

The guide reaches a signed-in user, but it alternates between NEXT_PUBLIC_WORKOS_REDIRECT_URI and WORKOS_REDIRECT_URI for the callback setting. One numbered guide runs from API key and client ID through install, redirect URI, proxy, callback route, and withAuth() returning the signed-in user, and workos.com/auth.md lets an agent provision a working API key with no account at all. The authkit-nextjs SDK page walks through installing packages, setting env vars (including WORKOS_API_KEY from the dashboard), creating a callback route with handleAuth(), a sign-in route with getSignInUrl(), middleware with authkitMiddleware(), and retrieving the user with withAuth() all in one coherent guide.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The page gives exact general and AuthKit request limits but no numeric limit for the default email provider. General (6,000 requests per 60 seconds per API key) and AuthKit (1,000 reads and 500 writes per 10 seconds per environment) are exact and scoped, but the default email provider's sending limits are stated only qualitatively, with no number an agent can plan against. General endpoint limits (6,000 req/60s per API key) and AuthKit limits (1,000 reads/10s, 500 writes/10s per environment) are exact and clearly scoped. However, default email sending limits are deliberately non-exact, described as adaptive, scaling with sending history, and not quantified. An agent cannot find a precise number for email sending limits.

PASS consensus from 3 PASS.

The rate-limit page gives both the server retry signal and a fallback when that header is absent. The 429 entry in the error table links straight to Rate limits, which gives the retry signal, the backoff rule, and the per-API-key counting scope, and the Node SDK page documents matching automatic retries with idempotency keys; no example 429 body or rate-limit headers beyond Retry-After are documented. The rate limits page gives the retry signal (Retry-After header) and fallback strategy (exponential backoff with random delay). The Node SDK page adds that SDKs auto-retry with 3 attempts, exponential backoff, and jitter, honoring Retry-After up to 60 seconds. The errors page confirms 429 maps to 'Too Many Requests' and directs to the rate limits page.

PASS consensus from 2 PASS, 1 PARTIAL.

The guide covers registration, receipt, testing, and verification, but its JavaScript example parses JSON before a raw-body check. The guide covers endpoint setup, registration, the WorkOS-Signature header and its lowercase normalization, SDK verification, manual HMAC SHA256 verification, tolerance, retry behaviour, and an IP allowlist, and the API reference links back to it for implementation detail. The webhooks guide covers the full lifecycle: creating an HTTPS endpoint, registering it in the dashboard, responding 200 OK, and validating signatures via the SDK (workos.webhooks.constructEvent) or manually (HMAC-SHA256 over 'issued_timestamp.body' using the webhook secret). The API reference provides webhook endpoint CRUD and cross-links to the guide. Both pages agree on the protocol.

PASS consensus from 3 PASS.

The SDK page supplies installation, and the Organization reference maps getOrganization to GET /organizations/:id. The SDK page gives install, new WorkOS('sk_1234'), retry and timeout behaviour, and PKCE examples, and most API reference operations carry a matching JavaScript tab, though the webhook endpoint operations offer curl plus seven other languages and no Node example. The official Node SDK is documented with package name (@workos-inc/node), installation command (npm install), requirements (Node 22.11+), and a minimal working example (import, construct with API key, call methods). The API Reference client-libraries page shows the same install command and links to Node usage examples, agreeing on the SDK form.