Unstructured

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The quickstart gives a complete flow, but the create-job reference appends /api/v1 to a variable that already ends with /api/v1. The quickstart alone is a complete, unambiguous three-step path with curl and Python tabs plus a full end-to-end script, but the REST reference pages for the same three calls compose the URL as "${UNSTRUCTURED_API_URL}/api/v1/jobs/" while the quickstart and Pipelines overview define that variable as already ending in /api/v1 and call "$UNSTRUCTURED_API_URL/jobs/", so cross-referencing yields a doubled /api/v1/api/v1 path. The quickstart provides three numbered steps (create, poll, download) plus a standalone end-to-end script in both curl and Python, forming one unambiguous path from zero to downloaded JSON.

PASS consensus from 3 PASS.

Four quickstarts and the Pipeline API overview all state 10 files, 50 MB, one second, and five running jobs. All four limits (10 files, 50 MB, one second between launches, five concurrent jobs) sit in one callout and are repeated byte-identically on five pages, and the Transform MCP get-started pages restate three of the four consistently with no contradicting value anywhere in the corpus. All four exact limits (10 files, 50 MB per file, 1-second interval, 5 concurrent jobs) appear together in a single note reused consistently across the quickstart and create-job pages.

PASS consensus from 3 PASS.

The quickstart links rapid successive launches to the error and requires at least one second between requests. The exact cause and the exact waiting correction are stated in the same step that creates the job, though the dedicated rate-limiting troubleshooting page never names the one-second rule and the Errors page documents no HTTP 429 case at all. The docs identify the cause (launching jobs too rapidly) and give the exact correction (wait at least one second between launch requests) in the same sentence.

PASS consensus from 3 PASS.

The workflow endpoint documents channel creation and secrets, while the webhook page supplies the POST schema and raw-body verification code. The chain is complete end to end: the workflow-scoped channel endpoint documents the secret constraint of 24 to 75 bytes and its write-only behavior, the payload schema lists every field and which events carry it, and the Python verifier gives the header names, the "{msg_id}.{timestamp}.{raw_body}" signing string, base64 HMAC-SHA256, versioned v1 signature parsing, a 300-second tolerance, and a constant-time compare. The webhooks page provides a complete HMAC-SHA256 verification function (import hashlib, hmac, base64; reads webhook-id/webhook-timestamp/webhook-signature headers; signs '{msg_id}.{timestamp}.{raw_body}'; compares with hmac.compare_digest). Webhook creation is documented through both the Pipelines UI and the create-notification-channel API. Creating a workflow-scoped (job) webhook via the API requires inferring the request format from the workspace-scoped example.

PASS consensus from 2 PASS, 1 PARTIAL.

The end-to-end quickstart uses BodyCreateJob, but the create-job reference places request_data directly on CreateJobRequest. The official client is linked to its GitHub repo with a pinned install of unstructured-client>=0.30.6 and a documented server_url constructor parameter, and the quickstart's Python tab is a runnable minimum example whose jobs.create_job, jobs.get_job, and jobs.download_job_output calls map cleanly onto POST /jobs/, GET /jobs/{id}, and GET /jobs/{id}/download. The official SDK is 'unstructured-client' on PyPI. The Transform quickstart gives a complete create-poll-download Python example using client.jobs.create_job, client.jobs.get_job, and client.jobs.download_job_output, which match the REST API operations (POST /jobs/, GET /jobs/{id}, GET /jobs/{id}/download).