Synthesia rejected status: moderation, error, and your handler

In Synthesia's webhook payload, status of rejected means the video was rejected during moderation due to inappropriate content, which is a different value from error, a processing failure. Sume uses one failure path with a machine-readable public_reason, and content_policy_rejected is the value for a provider rejecting generated content.

Synthesia details are from its webhook events page, read 2026-10-01. Sume details are from the OpenAPI document and Format errors.

How do the two vocabularies line up?

Synthesia lists four statuses. Sume's job events are terminal-only: job.completed, job.failed, job.canceled. The reason a Sume job failed is carried in public_reason, which the OpenAPI description calls machine-friendly so SDKs, agents and support tooling can group on it.

Can a valid request still be rejected on Sume?

Yes. For Avatar Video the OpenAPI text says a request within the 4-60 second window can still fail with public_reason content_policy_rejected when a provider rejects generated clip content. Other examples of public reasons are generation_rejected and image_content_rejected.

How is an unfunded run different?

insufficient_credits is a request error, not a moderation result. Retrying it unchanged returns the same answer until the wallet is funded, so a handler should route it to a billing path rather than a content-review path. Details: Format errors.

What should my handler do?

Branch on the specific reason, not on the word failed. Send moderation outcomes to a human or ask the user to change the input, retry transient failures with backoff, and show an add-funds prompt for 402. Related: job.failed webhooks with a callback URL.