Railway

PASS consensus from 3 PASS.

The quick start names a sample repository, deployment steps, and the domain action in one dashboard path. The quick start supplies a concrete forkable sample repo (railwayapp-templates/nextjs-basic), names each dashboard control verbatim, and offers three independent paths (GitHub, CLI, Docker image), with the domain step spelled out on the linked networking page. Quick Start provides a step-by-step path from zero to deployed app with a Railway-provided domain via three deployment options (GitHub, CLI, Docker image).

PARTIAL consensus from 1 PASS, 2 PARTIAL.

Both tables are findable, but the API page defines X-RateLimit-Limit as daily beside hourly limits. The plans page states Pro allows 1,000 vCPU and 1 TB RAM per service and that these 'include replica multiplication', while the scaling page states each Pro replica gets 24 vCPU / 24 GB and that two replicas cap at 48 vCPU / 48 GB, so the two pages return different answers for the same service-level ceiling; separately the API rate-limit list omits the Trial plan that the plans page defines and gives no requests-per-second figure for Free. API rate limits are tabulated by plan in one page; per-service resource quotas (RAM, CPU, replicas, ephemeral storage, volume storage, image size) are tabulated by plan in a separate Plans page. The values are consistent across both pages.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The page says when to retry, but it never identifies 429 or defines the header value's unit or format. Retry-After is defined in a single table row and is the only Retry-After reference in the entire documentation corpus, but no page documents the HTTP 429 status code for the Railway API, the units of the Retry-After value, the shape of the throttled response, or any backoff guidance, and the same table describes X-RateLimit-Limit as a per-day maximum while the limits above it are stated per hour and per second. The API documentation explains rate-limit response headers including Retry-After, which tells the caller how long to wait before the next request.

FAIL consensus from 1 PARTIAL, 2 FAIL.

Setup, payload, and testing are documented, but the page provides no signature or authenticity-verification method. Creation and payload shape are documented, but the docs describe no signing secret, signature header, or any other authenticity mechanism for Railway-sent webhooks anywhere in the corpus, so a receiver cannot distinguish a genuine Railway delivery from a forged POST, and the documented test-payload path is itself disclosed as likely to fail. Webhook setup and test-payload button are documented, but there is no documented HMAC signature, shared secret, or any mechanism to verify the authenticity of Railway's own webhook payloads. The 'Example payload' heading exists but contains no example body.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The quick start uses RAILWAY_API_TOKEN and RAILWAY_ENVIRONMENT_ID, while the API page explains account-token authentication. An official SDK exists (npm package `railway`, repo railwayapp/railway-ts-sdk) with runnable authenticated examples, but it is never mentioned on any Public API page, it covers only sandboxes, feature flags and infrastructure-as-code rather than the GraphQL concepts the API docs teach (projects, services, deployments, variables, domains, volumes), and its two documented entry points disagree on which environment variable authenticates. The railway npm package is a full TypeScript SDK with Sandbox and IaC APIs, detailed README, and configuration that matches the GraphQL endpoint and token types documented on docs.railway.com. However, docs.railway.com does not link to or mention this SDK, so an agent starting from the docs site would not discover it.