Every error, and what to do about it.

Send the key as `Authorization: Bearer wk_live_...`. A key that was copied without its prefix, or with a trailing newline, arrives as this error rather than as a key we can recognise.

The key was revoked from the dashboard and will never work again. Issue a new one and deploy it. Revocation takes effect on the next request, so a running deployment stops immediately.

Keys carry the set of endpoints they may call. Widen it from the dashboard, or use the key that was issued for this endpoint. Retrying does not help.

The payload could not be read. The `detail` field says which field and why. Send JSON, with the field the endpoint documents.

Too many calls in one minute. `Retry-After` says how long to wait, and `limit` is the ceiling on your plan. Wait, then retry: this one is safe to back off on.

The monthly allowance for this endpoint is spent, and `resets_at` says when it returns. Retrying will not help before then, which is why this is 402 and not 429. Change plan or wait.

A single batch is capped. `submitted` and `limit` are in the payload. Split the list and submit it as several jobs.

No job with that id belongs to this account. The same answer covers a job that never existed, one that passed its 48 hour retention, and one belonging to somebody else, because telling those apart would confirm which job ids are real.

The request reached us but could not be served as sent: a method or a route that does not exist. Check the URL and the verb against the reference.

Something we depend on is down. It is not your request, and it is not permanent. `Retry-After` says when to come back, and retrying is the correct response.

Our bug. The detail is deliberately empty because the message would leak internals; the specifics are in our logs. Retrying is reasonable once. If it persists, the response and the time it happened are enough for us to find it.