Runware

PASS consensus from 3 PASS.

The introduction provides signup, key creation, Bearer authentication, a complete image request, and an imageURL response. Introduction gives a four-step signup-to-key path and a complete cURL request whose documented response contains imageURL, and Authentication states the endpoint, method, header auth, and array payload shape without ambiguity. The auth page walks from sign-up through API-key creation to a working curl command; the text-to-image page returns the generated imageURL in the response.

SPLIT consensus from 1 PASS, 1 PARTIAL, 1 FAIL.

The page states no hard rate limits and recommends 2-4 requests, but it gives no numeric queue capacity. Recommended concurrency is a concrete 2-4, but no queue-capacity number is published anywhere and the page lists 'Real-time capacity metrics - API endpoints showing current queue depth and estimated processing times' as unshipped future work, so two of the three requested values do not exist and the 2-4 figure never states whether its scope is per key, per account, or per model. No numeric rate-limit or queue-depth values are published, but the docs are internally consistent: no hard limits, shared finite queues, recommended 2-4 concurrent requests.

PASS consensus from 2 PASS, 1 PARTIAL.

The backoff example is specific, but queue capacity is unnumbered and the errors page gives a different 429 cause. Runnable TypeScript and Python retry helpers give the exact policy (retry on 429 and 503 only, 1s/2s/4s doubling, maxRetries 3, rethrow everything else), and the docs explain that the applicable threshold is dynamic rather than fixed, offering sub-30s latency as the health signal instead. HTTP 429, 503, and 504 are listed as transient retryable errors; TypeScript and Python code examples implement exponential backoff starting at 1s.

PASS consensus from 3 PASS.

One page covers webhookURL, query-token validation, POST handling, a five-second response target, retries, and taskUUID deduplication. All five steps are covered in one page with working code: webhookURL on the request, the full POST body, an Express handler that rejects on a mismatched query token, the 2xx and 5s window, and a taskUUID Set for deduplication, though the 'Receiving notifications' code tabs are miswired and render the webhook response payload as arguments to a client.run() generation call. Complete walkthrough: set webhookURL, verify via token query param, return 2xx within 5 seconds, deduplicate with processed.has(taskUUID), and exponential-backoff retry delivery.

PASS consensus from 2 PASS, 1 PARTIAL.

The @runware/sdk quick start uses REST and the core REST fields, then prints images[0].imageURL. The TypeScript SDK page alone is excellent and its quick start maps field-for-field onto the REST body, but the site's own llms.txt names the legacy package @runware/sdk-js as the official SDK, so an agent entering through the machine-readable index installs the wrong package and only recovers by cross-referencing the javascript-legacy page. Install @runware/sdk, create a REST client with createClient, call client.run() with imageInference params, and read imageURL from the result.