Skip to main content
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.

Placeholders

The snippets below use these placeholders. Replace them before running the code.
Pronunciation dictionaries currently support rewrite mode. SLNG 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 SLNG key. Requests from another organization cannot read or use it. The basic flow is:
  1. Create a dictionary with rewrite rules.
  2. Reference that dictionary by name or dictionary_id.
  3. Send a TTS request with a pronunciation object.
Only one active pronunciation dictionary can apply to a request or WebSocket turn.

Create a dictionary

Create dictionaries with the pronunciation dictionary API reference:
A successful response includes the dictionary id, normalized name, metadata, modes, content hash, and creation timestamp:
Dictionary names must be unique within your organization. Names can contain letters, numbers, ., _, and -, and can be up to 128 characters.

Hear the difference

Use the same text with and without the dictionary:

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:
Get one dictionary by name:
Delete a dictionary:

Use a dictionary with HTTP TTS

Add a pronunciation object to the TTS request body:
You can also reference the dictionary by immutable ID:
Rules for the request object:
  • mode must be "rewrite"
  • provide exactly one of name or dictionary_id
  • use only one active dictionary per request
With the example dictionary above, the selected model receives this rewritten text:

Use a dictionary with WebSocket TTS

Set a default dictionary when you initialize the session:
Then send text normally:
To change dictionaries for a later turn, include 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 same pronunciation 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
For example, this dictionary prefers ACH transfer over the shorter ACH match:
Input:
Rewritten result:

Limits and errors

Current limits: Pronunciation resolution fails closed. If the dictionary cannot be found or resolved, the request or WebSocket turn is not sent to the selected TTS model. Common HTTP errors: Common WebSocket failures return an error frame:

Current limitations

  • Only mode: "rewrite" is executable today.
  • modes.ipa can be stored but is not executed.
  • There is no automatic fallback from IPA to rewrite.
  • Provider-native pronunciation dictionary uploads are not supported through SLNG.
For most applications, create a stable dictionary such as support-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.