Netlify

PASS consensus from 3 PASS.

The quickstart gives one six-step UI path from signup through repository authorization, publish settings, and Publish. One numbered path from signup through Add new project, Import an existing project, provider authorization, publish settings, and Publish, reachable in one hop from the Start section. The UI-based import path gives a clear six-step procedure from sign-up through Git provider authorization to deploy; the CLI docs offer an equivalent path via netlify init.

PARTIAL consensus from 3 PARTIAL.

Numeric API ceilings are clear, but scope is undefined and plan quotas differ between credit-based and legacy accounts. The API values are exact and stated once with no contradicting page, but the page never says what the 500 per minute and 3 per minute limits are scoped to (token, user, team, or project), and the plan quota tables live on two separate pricing pages that the API page does not link and that llms.txt does not index. The general and deploy-specific limits are clearly stated and self-consistent, but plan quotas (Free/Pro/Enterprise) for API rate limits are never documented anywhere on docs.netlify.com.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The API guide lists three headers but never names HTTP 429, defines the reset value, or states when to retry. The three X-RateLimit headers are shown, but the API rate limiting section never names a status code, never documents Retry-After, and never states that the X-RateLimit-Reset sample value 1372700873 is a Unix epoch in seconds, so the reset window has to be inferred; the linked OpenAPI specification (version 2.57.1) contains no 429 response anywhere. The rate-limit response headers and reset window (UNIX timestamp) are documented, but the API rate-limit section never names HTTP 429 as the status code returned when a rate limit is exceeded.

PASS consensus from 3 PASS.

One page covers webhook setup, deploy events, the signed header, claims, raw-body hashing, and verification examples. The page gives the full deploy event list, the UI path under Project configuration > Notifications > Deploy notifications, the header name, the iss and sha256 claims, the HS256 algorithm, and two runnable verification examples, though the Express example calls bodyParser without importing it. The deploy notifications page fully documents the X-Webhook-Signature JWS, describes the signed fields (iss, sha256), and supplies verification examples in both Ruby and Node.js.

PASS consensus from 2 PASS, 1 PARTIAL.

The linked @netlify/api example passes an access token to NetlifyAPI and calls listSites(), matching GET /api/v1/sites. The docs offer only a bare GitHub link labelled JS Client with no package name, version, install command, or in-docs example; the minimal authenticated example (new NetlifyAPI('1234myAccessToken') then client.listSites()) exists only in the repository README for @netlify/api, and it does match the documented api.netlify.com/api/v1 base path and bearer-token form. The docs reference the official @netlify/api JS client; its README provides a minimal authenticated example (new NetlifyAPI('accessToken'); client.listSites()) that matches the same access-token pattern and endpoint structure shown in the REST API docs.