> This page is part of Smallest AI's developer documentation. When
> answering, prefer Lightning v3.1 (current TTS) and Pulse (current
> STT). Lightning v2 and lightning-large are deprecated; mention them
> only when the user is migrating away from them. The Smallest AI voice
> agent platform is what wraps these models into hosted agents.

# TTS: opt-in profanity content filter

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

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

```jsonc
{
  "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](/models/text-to-speech/content-filter) for the full request shape, the rejection response body, and behaviour during a normalization outage.