Pronunciation dictionaries let you control how text is spoken before it reaches the selected TTS model. Create a dictionary once, then reference it from HTTP, WebSocket, or Unified TTS requests. Use them when a voice needs to pronounce acronyms, product names, customer names, jargon, or multilingual terms consistently across TTS models.Documentation Index
Fetch the complete documentation index at: https://docs.slng.ai/llms.txt
Use this file to discover all available pages before exploring further.
Pronunciation dictionaries currently support rewrite mode. The SLNG API rewrites matching words or phrases before synthesis, and the rewritten text is what the selected model receives.
How it works
Each dictionary belongs to the organization resolved from your API key. Requests from another organization cannot read or use it. The basic flow is:- Create a dictionary with rewrite rules.
- Reference that dictionary by
nameordictionary_id. - Send a TTS request with a
pronunciationobject.
Create a dictionary
Create dictionaries with the pronunciation dictionary API reference:id, normalized name, metadata, modes, content hash, and creation timestamp:
., _, and -, and can be up to 128 characters.
Manage dictionaries
For request and response schemas, see the generated API reference pages for listing dictionaries, reading one dictionary, and deleting a dictionary. List dictionaries:Use a dictionary with HTTP TTS
Add apronunciation object to the TTS request body:
modemust be"rewrite"- provide exactly one of
nameordictionary_id - use only one active dictionary per request
Use a dictionary with WebSocket TTS
Set a default dictionary when you initialize the session:pronunciation on the text message:
init.config.pronunciation sets the session default. text.pronunciation replaces the active dictionary for that turn, and later text turns reuse the most recent active dictionary.
Use a dictionary with Unified TTS
Use the samepronunciation shape with Unified TTS bridge requests:
Rewrite matching
Rewrite mode is deterministic:- matching is case-insensitive
- only whole words or whole phrases are matched
- longer phrases win before shorter matches
- rewriting is single-pass and non-recursive
B2B portal over the shorter B2B match:
Limits and errors
Current limits:| Limit | Value |
|---|---|
| Dictionary name | 128 characters |
| Rewrite rules per dictionary | 256 |
| IPA rules per dictionary | 256 |
match length | 128 characters |
replace length | 256 characters |
ipa length | 256 characters |
| Runtime text input for rewrite | 20,000 characters |
| Runtime rewritten output | 100,000 characters |
| Status and code | Meaning |
|---|---|
400 invalid_pronunciation | Malformed object, invalid name, unsupported mode, or dictionary not found |
401 pronunciation_unauthenticated | Missing or unresolved organization context |
409 pronunciation_conflict | Dictionary name already exists in the organization |
503 pronunciation_unavailable | Gateway storage or dependency failure during dictionary resolution |
Current limitations
- Only
mode: "rewrite"is executable today. modes.ipacan be stored but is not executed.- There is no automatic fallback from IPA to rewrite.
- Provider-native pronunciation dictionary uploads are not supported through the SLNG API.
Recommended pattern
For most applications, create a stable dictionary such asbrand-pronunciations and reuse it by name. Use dictionary_id only when your application needs an immutable machine reference.
Keep dictionaries scoped to a domain, product line, or voice style. For WebSocket sessions, set the default dictionary in init, then override individual turns only when needed.