Errors

A successful response is the resource itself — never wrapped in { "data": ... }. There is no top-level success field to check; the HTTP status is the signal.

A failed request returns a non-2xx status and a body shaped like this:

{
  "code": "PAYMENT_REQUIRED",
  "message": "Add a card to schedule and publish. Drafts keep working.",
  "data": {}
}

data is only present for the codes that carry structured detail (for example POST_QUOTA_EXCEEDED includes the platform, the limit, and how many you have used). It is absent otherwise.

Branch on code, not message

message is English prose for a log line or a fallback string. It can change wording between releases. code is the contract: every operation declares the exact set of codes it can return, so it reaches the OpenAPI document, this page, and any generated client's typed error union from one declaration. Match on code.

Codes you will see across most operations

Operations that write posts add their own codes on top of these — POST_QUOTA_EXCEEDED, CONTENT_TOO_LONG, MEDIA_RULE_VIOLATED, VIDEO_TOO_LONG, SCHEDULE_IN_PAST, and others. The reference lists the exact set for each operation.

What never happens

• No error is translated on the wire. message is always English. If you show it to an end user, map code to your own copy instead.
• No code is invented per response. An operation only ever returns a code from its declared set, so a client can exhaustively handle every case instead of falling back to a generic catch.