Vercel

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The agent prompt gives a global npm path, but the page body and CLI overview instead show npm i vercel, so installation is not one consistent path. The step sequence is clear, but the same page tells the agent to run npm i -g vercel in its agent prompt and npm i vercel in its numbered install step, so the CLI lands globally or locally depending on which block is read. The main docs page and the getting-started page both present the identical three-command flow. The CLI detects the framework, builds, and deploys. Production promotion uses the --prod flag. No guessing required.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The rate-limit table gives plan values and scopes, but the general table says Enterprise deployments per day are Custom rather than 24000. Every rate limit carries an explicit limit, duration and scope, but the table repeats several descriptions verbatim with different values, so Domains retrieval per minute reads 200 in one row and 500 in the next with no way to tell which applies. The REST API page names the three rate-limit response headers and links to the limits page, which lists per-endpoint rate limits (limit per window) and deployment quotas per plan (Free/Pro/Enterprise). All values and scopes are consistent across the table.

PARTIAL consensus from 3 PARTIAL.

The error reference names rate_limited and returns reset timestamps, but the quickstart calls the 429 platform-wide and the dynamic-quota section names rate_limit_exceeded. The REST API error page names the rate_limited code and returns a reset epoch an agent can wait on, but it never states the HTTP status is 429, never mentions retry-after, and the 67 429 responses in the OpenAPI description carry empty description strings. The errors page names the 'Rate limited' condition and explains it is per-endpoint, and the REST API page documents the three response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). However, the docs never state the HTTP 429 status code explicitly, never mention a Retry-After header, and provide no retry or backoff guidance. An agent can detect the condition but cannot reach a complete correction from the docs alone.

PASS consensus from 2 PASS, 1 PARTIAL.

The setup, payload schema, raw-body HMAC, and constant-time comparison are documented, but the linked App Router validator exports GET while delivery uses POST. The path runs end to end without guessing: create the webhook and capture the one-time secret, receive a typed event payload, read x-vercel-signature, and compare an HMAC-SHA1 of the raw body using crypto.timingSafeEqual. The process is complete: create a webhook via Settings > Webhooks, select events and scope, supply an endpoint URL, receive a secret key shown once, then verify every incoming request by computing HMAC-SHA1 of the raw body with the secret and comparing it to the x-vercel-signature header. Both the webhooks page and request-headers page document this end-to-end.

PASS consensus from 2 PASS, 1 PARTIAL.

The page installs @vercel/sdk, initializes Vercel with VERCEL_TOKEN, and maps GET /v10/projects?limit=1 to vercel.projects.getProjects({ limit: '1' }). Every endpoint page carries a complete authenticated example using new Vercel({ bearerToken }) and the SDK method maps onto the same GET /v7/deployments route the REST reference lists, but the page's own install it link points at an anchor that does not exist and no install command appears anywhere on it. The SDK docs provide install (pnpm i @vercel/sdk) and a complete authentication example using a bearer token. This matches the REST API authentication form (Authorization: Bearer <TOKEN>). The SDK methods map one-to-one to REST API endpoints, and the grouping is consistent.