Lightning v3.1

Lightning TTS requests now accept a content_filter object that checks the submitted text against a profanity word list before synthesis:

{
  "text": "...",
  "voice_id": "avery",
  "content_filter": { "enabled": true, "action": "reject" }
}

Off by default. Omitting the object, or sending anything other than the literal true for enabled, leaves behaviour unchanged. There is no account-level default that switches it on.

action: "reject" fails the request with HTTP 400 and error_code: "CONTENT_FILTER_BLOCKED", reporting the locale checked and a match_count. No audio is produced and the request never reaches the worker. action: "flag" synthesizes normally and records the match, which is the way to measure the false-positive rate on your own traffic before enforcing.

The filter never rewrites your text. Matching is whole-word rather than substring, so ordinary words containing a listed term are unaffected. The lists consulted are the one for the request’s locale plus English, which is always checked because English profanity is common in code-mixed text. The matched terms are never returned in the response or written to logs.

Available on lightning_v3.1 and lightning_v3.1_pro across sync HTTP, SSE and WebSocket.

See Content filter for the full request shape, the rejection response body, and behaviour during a normalization outage.