content_blocked — text is on the blocklist

The order was not created. Body: {"success": false, "message": "…", "reason": "content_blocked"} — WITHOUT errors, because the request shape has nothing to do with it. Single-chunk retry and chunk regeneration return the same reason.

A fragment of the text has already been rejected by the content policy of the service and added to the global blocklist. Matching is done PER CHUNK and by exact match of the fragment text — so in a long text, it is one specific piece that trips the check, not the whole text.

Retrying is pointless and costly: the outcome is deterministic, and every attempt consumes resources and moves the counter toward policy_cooldown_active. The only action that works is to edit the offending fragment; because matching is per chunk, it is enough to fix that one fragment without rewriting the whole text. The API does not tell you why the policy triggered: that is admin-only, there is no reason field in the response and there will not be one — do not look for it.

POST /orders with the edited input_text. You can check in advance how the text is split into chunks with POST /orders/chunks/preview — it does not check the blocklist itself, but it shows the fragment boundaries that matching is based on, and it is free.

• policy_cooldown_active — what a series leads to
• policy_flagged — the same thing, but on a chunk of an existing order
• Guide: voiceover text
• Guide: retries and idempotency
• POST /orders/chunks/preview
• POST /orders