Skip to main content

Speech Recognition Dictionaries

Dictionaries are short lists of domain-specific terms — brand names, product SKUs, technical jargon, people, places — that you attach to an agent. The speech-to-text engine biases its transcription toward those terms, so the agent hears “Vocobase” instead of “Vocal base” and “SKU-4471” instead of “skew four thousand four hundred seventy one”.
Dictionaries only affect agents on a transcription configuration that supports vocabulary biasing. If you are not sure whether your account is enabled for dictionaries, contact Vocobase support.
V2 API (v2) only. These endpoints live under https://api.vocobase.com/api/v2 and are reached with a rg_live_... Bearer token.

When dictionaries help most

  • Proper nouns the model has never seen (your company name, product names, internal codes)
  • Ambiguous homophones where context alone does not disambiguate (e.g., “Mira” vs “Meera”)
  • Alphanumeric identifiers the user speaks slowly (serial numbers, reference codes)
  • Non-English-origin words embedded in an English call (e.g., Indian names, Spanish towns)
They do not help with:
  • Accent adaptation (that is handled by the language model itself)
  • Entire sentences or long phrases (dictionaries are a per-term bias, not a grammar)
  • Replacing STT output with a canonical form (use your own post-processing for that)

Limits

The 10,000-character cap is enforced at attachment time and on PATCH, so you cannot accidentally push an agent over the limit.

Create a dictionary

Creation is agent-agnostic. POST /api/v2/dictionaries does not take an agent_id — dictionaries are reusable across agents. To make a dictionary actually bias an agent’s STT, attach it in a separate step with PUT /api/v2/agent/{agent_id}/dictionaries.
Terms are normalized server-side: whitespace is trimmed, empty strings are dropped, non-string entries are silently skipped, and the dedupe is case-insensitive but preserves the first-occurrence casing. Passing ["Vocobase", "vocobase", " Vocobase "] stores ["Vocobase"], and term_count reflects the normalized list.
A blank or whitespace-only description is stored as null.

Attach dictionaries to an agent

Attachment is a set-replace. PUT /agent/{agent_id}/dictionaries overwrites the agent’s entire dictionary set with the dictionary_ids array you send. There is no separate attach/detach endpoint — to add one, send the current ids plus the new one; to detach one, send the current ids minus the one to remove; to detach everything, send []. The swap is wrapped in a transaction, so the agent is never briefly in a partial state.
Every id in dictionary_ids must exist and belong to the calling account; otherwise the whole request fails with 400 VALIDATION_ERROR. Duplicate ids are deduped silently. If the combined char_count across the requested set would exceed 10,000 characters, the request fails with 400 DICTIONARY_CHAR_LIMIT_EXCEEDED:
Detach a less-relevant dictionary, or split a large dictionary into smaller, more targeted ones.
Bigger is not better. A focused 200-term dictionary biases the STT engine more effectively than a 2,000-term grab-bag because the engine has fewer distractors to weigh. Keep dictionaries narrow.

Manage dictionaries

Dictionaries are ordinary CRUD resources — see the API Reference for full schemas. Four behaviours that are easy to get wrong:
  • terms replaces the whole list. There is no incremental add or remove. Merge client-side, then send the full array.
  • Updates are validated against every agent. If the new char_count would push an attached agent over the 10,000-character combined limit, the request fails with 400 DICTIONARY_CHAR_LIMIT_EXCEEDED and the details name the offending agent_id.
  • Changes apply to the next session. In-flight calls keep the snapshot taken when they started.
  • Deleting detaches everywhere. DELETE /dictionaries/{id} returns 204 No Content and removes the dictionary from every agent it was attached to. Nothing else is touched.

Tips for authoring good dictionaries

  • Write terms the way they are pronounced, not the way they are written. If your product “GraphQL” is pronounced “graph Q L”, add both GraphQL and graph Q L.
  • Group by domain, not by size. One dictionary per product line, region, or use case is more useful than one mega-dictionary.
  • Audit with real transcripts. Pull a week of call recordings and look for consistent mis-transcriptions — those are your dictionary candidates.
  • Remove, don’t just add. Terms that never appear in your actual conversations add noise. Trim after two weeks of usage.

Troubleshooting