Runpod

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The sequence reaches success, but its requirements omit the Docker Hub account and login needed for the push. The nine-step quickstart is complete and unambiguous from empty directory to a COMPLETED response, but the first request example on the linked send-requests page uses curl's proxy flag -x instead of -X, and that page sends the key as "authorization: Bearer RUNPOD_API_KEY" while the operation reference it links to sends it bare as "authorization: $RUNPOD_API_KEY", with the API keys page never stating which header form is correct. Eight-step workflow with dedicated pages for each step and working code examples.

PARTIAL consensus from 3 PARTIAL.

The docs give all requested scopes, but sync retention appears as both one minute and up to five minutes. Rate limits, concurrency, payload size, execution timeout, TTL and the $80/hour spend limit are all published with concrete numbers, but they are spread across five pages with no limits page in the index, and the operation reference contradicts itself on sync result retention by stating that ?wait does not affect retention and then that ?wait extends retention to five minutes. Rate limits, concurrency, timeout, TTL, and retention are documented, but /runsync retention is inconsistently stated as '1 minute' vs '1 minute (5 minutes max)' and spending limits are only indirectly covered via balance-based max worker tiers.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The docs cover queue checks, 429 backoff, timeout changes and retry, plus unavailable-worker recovery. Every failure mode in the battery is covered with a documented recovery action, including /retry, /cancel, /purge-queue and /health, but the troubleshooting page attributes throttled workers to rate limits while the workers overview defines Throttled as host machine resource constraints, which points an agent at request backoff instead of widening GPU types or data centers. Each failure mode has documented recovery steps, but they are scattered across send-requests, troubleshooting, job-states, and operation-reference pages with no unified diagnostic flow.

FAIL consensus from 1 PARTIAL, 2 FAIL.

The docs describe submission, acknowledgment, and retries, but give no payload schema or authenticity check. Submission and acknowledgement are documented in these two sentences, but the entire corpus, including the 1.8 MB llms-full.txt, contains no signature, HMAC, shared secret, or verification header for webhooks and never documents the JSON body or headers Runpod sends, so authenticity cannot be determined from the docs at all. Submission, acknowledgement (return 200), and retry behavior are documented, but the webhook payload format and any authenticity verification mechanism (signing, HMAC, shared secret) are entirely absent.

PASS consensus from 2 PASS, 1 PARTIAL.

The SDK page documents installation and key configuration, while the operation reference provides a matching minimum request. Install and API key configuration are clean and correct, but the same operation reference page shows the Python SDK called both without the input wrapper in the /run and /runsync tabs and with it in the /status and /stream tabs, so the minimum working request cannot be settled, and the SDK page points to Send API requests for examples when that page contains only curl. Complete installation, API key configuration, and serverless request submission instructions are presented in a clear single path reinforced by the operation reference and GitHub README.