# Pronunciation dictionaries

Respelling rules applied to your text before synthesis.

## How it works

A pronunciation dictionary is a list of per-organisation respelling rules applied to your text before synthesis. Create one in the console (Pronunciation), collect its id, and pass that id with any speech request — every rule in the dictionary applies to that request.

```http
POST /v1/audio/speech
```

```
{
  "voice": "sv_enhdbrj5",
  "input": "Your SQL dashboard and HDFC statement are ready.",
  "pronunciation_dictionary_id": "fbdb2572-a0ed-4bf0-b83a-897411f95090"
}
```

## Rules are respellings, not phonetics

The model reads letters, so rules are written the way the word should be read — `SQL` as `sequel` (or `S Q L` to spell it out), `NASA` as `नासा`. IPA and phoneme notation are not accepted; a rule pasted as `/ˈnæsə/` is refused with an explanation of what to write instead.

> Respellings can cross scripts: an English acronym can be respelled in Devanagari, and rules still match inside code-mixed sentences.

## Match options & language scope

- `case_sensitive` — match only with exact casing (default off: `nasa` matches `NASA`).
- `word_boundaries` — match whole words only (default on), Devanagari-aware.
- `only_languages` / `except_languages` — scope a rule to (or away from) specific request languages. One term may carry different rules at different scopes: HDFC read as `एच डी एफ सी` in Hindi and as `H D F C` everywhere else.

## Using a dictionary in a request

Pass `pronunciation_dictionary_id` on [speech requests](https://docs.kenpathlabs.com/text-to-speech.md) or as a query parameter on the [input-streaming WebSocket](https://docs.kenpathlabs.com/input-streaming.md). Rules apply before normalization, and edits propagate to running infrastructure within seconds — no redeploys.
