Reducto

PASS consensus from 3 PASS.

The quickstart covers account creation, key setup, SDK installation, local upload, synchronous parse, and result access in one page. The quickstart runs account signup, key creation, environment variable, SDK install, upload, parse call, and a field-by-field response table in one unbroken sequence, with a separate top-of-page shortcut path labeled for coding agents. Every step from API key creation to structured JSON output is documented in a single page with working code in four language ecosystems.

PASS consensus from 3 PASS.

The linked pages state 1,000 and 200 req/s limits, plus US/EU baselines of 200/60, 350/120, and 500+/275+. Edge limits are stated exactly per API key (1,000 req/s all endpoints, 200 req/s on GET /job/{job_id}) on the Rate Limits page, and the Concurrency Throttle page gives one table with side-by-side US and EU baselines (Standard 200/60, Growth 350/120, Enterprise 500+/275+ custom) in concurrent batches, with no conflicting numbers anywhere else in the corpus. Edge rate limits (1,000 req/s all endpoints, 200 req/s for GET /job) and per-tier concurrency baselines are stated in a single page each, with US and EU values in the same table.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The rate-limit page maps each 429 body to a fix, but the agent guide incorrectly describes 429 as concurrent-request throttling. The Rate Limits page diagnoses the condition precisely with distinct 429 body codes ([CODE 1000], [CODE 2000], and bodyless infra-shed 429s) plus a symptom-to-action table, but two other pages contradict it: the agent guide defines 429 as "Too many concurrent requests" when concurrency pressure returns 200 after a queue wait, and the Error Codes page claims async endpoints "have higher limits" when the edge cap is stated as applying to all endpoints. The How to Tell Which Limit You're Hitting table maps each 429 variant to its cause and action; the Error Codes page contributes code-level handling examples with SDK exception types.

PASS consensus from 3 PASS.

One page covers dashboard access, endpoint creation, async.update delivery, signing-secret retrieval, and three-header verification. One page covers the whole loop: reaching the Svix dashboard through Studio or POST /configure_webhook, adding the endpoint, submitting with async.webhook.mode set to svix, the exact payload shape, and runnable Python and TypeScript verification using the svix library with all three svix-id, svix-timestamp, and svix-signature headers. A single page covers dashboard access, endpoint configuration, job submission with webhook mode, payload format, and production-ready signature verification code in Python and TypeScript.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The SDK form matches REST, but the quickstart requires Python 3.8+ while the SDK page requires 3.9+. The package name, import path, and call form (pip install reductoai, from reducto import Reducto, client.parse.run(input=...)) match across the quickstart, the SDK section, and the agent guide, but the quickstart states the requirement as "Requires Python 3.8+." while the SDK overview states 3.9+, so the reader must guess which floor is real. The official SDK (PyPI package reductoai) has its own documentation section with a minimal upload-and-parse example that matches the API form used in the Quickstart and the REST API reference.