Mux

PASS consensus from 3 PASS.

One quickstart covers token creation, URL ingest, readiness, the playback ID, and browser playback. One numbered page carries token generation with the required Mux Video Read and Write permissions, a runnable curl POST whose rendered body is {"inputs": [{"url": ...}]}, demo source URLs, the preparing-to-ready status wait, and the https://stream.mux.com/{PLAYBACK_ID}.m3u8 playback URL. The guide steps from Access Token creation through POST /assets to playback URL construction in one linear path; a minor discrepancy (guide says singular input but REST API uses plural inputs) does not block the path.

PARTIAL consensus from 3 PARTIAL.

API and pricing values agree, but the organization-wide cap and Data burst sizes remain unquantified. The API rate limits are stated exactly as a four-row table (POST high 20 requests at 1 req/sec, POST low 4 at 1 req/sec, all other methods high 100 at 5 req/sec, low 20 at 1 req/sec) plus 1 RPS sustained for Monitoring Data and 5 RPS sustained for General Data, but plan quotas such as the Free plan's "Up to 10 videos stored" appear only on the pricing page, and a search of the whole llms-full.txt docs corpus returns zero matches for quota, usage limit, or free trial. API request-bucket rate limits are documented with exact numbers; account-level plan quotas (10 stored videos on Free, 100K delivery minutes) are only on the separate pricing page with no cross-reference from the API docs, forcing an agent to find and reconcile two documentation areas.

PARTIAL consensus from 3 PARTIAL.

The headers expose capacity and remaining requests, but no reset or retry header gives an exact retry time. The docs name only x-ratelimit-limit and x-ratelimit-remaining, document no Retry-After or reset header, and give no backoff algorithm, so the wait must be computed by hand from the fill-rate table after inferring the bucket from the request method. The x-ratelimit-limit and x-ratelimit-remaining headers are documented and the fill-rate table gives the refill speed, but no Retry-After header is mentioned and no explicit retry algorithm (e.g. how long to wait, exponential backoff) is provided; agents must infer the delay from the bucket size and fill rate.

PASS consensus from 3 PASS.

Creation, delivery, and HMAC-SHA256 verification are complete; the webhook-reference fetch exceeded the tool's 5 MB limit. The path is complete end to end: create the endpoint in the Dashboard or with a documented curl POST to https://api.mux.com/system/v1/webhooks that returns a one-time signing_secret, receive the POST within the stated 5 second timeout, tunnel locally with the Mux CLI, then follow four numbered verification steps and the 5 minute default timestamp tolerance. Full end-to-end path: create webhooks via Dashboard or API, signing secret delivered in create response, mux-signature header format documented, HMAC-SHA256 verification steps shown, Node SDK provides mux.webhooks.unwrap helper; webhook events guide links directly to verification guide.

PARTIAL consensus from 3 PARTIAL.

The npm fetch returned 403, the API Markdown fetch returned 404, and the integration page conflicts with current sources. The SDK is easy to find and the example runs, but it uses input and playback_policy, which the API reference schema marks deprecated in favour of the inputs and playback_policies fields that the same site's quickstart curl and the create-asset request example both use. The Node SDK (@mux/mux-node) has a working example on GitHub that uses inputs (plural) matching the REST API OpenAPI spec example; however the Mux docs integration page for Node returns HTTP 404, and the quickstart guide describes setting input (singular) while the SDK and REST API both require inputs (plural array), creating a cross-reference gap.