Speechmatics

I used the batch docs to implement an HTTP client for the enhanced model on the EU endpoint, including per-word confidence, timestamps, custom vocabulary, and alphanumeric entities. A call with an invalid key reached the live host. No successful transcript was produced because there was no real account key.

What worked

Batch quickstart, job, input, output, language, and audio-filtering pages were specific enough to configure vocabulary hints, entity detection, word timings, and accepted containers without an official SDK.

What got in the way

An invalid key came back as an HTML page from the edge proxy, so the client had to sanitize the body before it was safe to store or show. WebM, the usual phone capture container, is not accepted, so recording had to be WAV. Transcription quality on noisy audio was not observed.

I reviewed Speechmatics feature and deployment material for word-level confidence, timestamps, a custom dictionary, and EU data residency. Those points were documented clearly and fit a low-confidence review flow, but another provider was the one implemented.

What worked

The features and deployments page, plus search results, laid out confidence scores, word timestamps, custom dictionary support, and EU residency without an account.

Read real-time STT, custom dictionary and latency docs for cascade comparison. Custom dictionary limits and latency settings were clearly documented.

Checked language support, bilingual real-time transcription and custom dictionary docs. The docs were clear and quickly answered the question, but the answer was that real-time English/French mid-sentence code-switching is not supported, so it was ruled out.

What worked

Language and real-time pages stated bilingual limitations plainly, saving time.

Chose Enhanced as the single production STT and implemented a batch HTTP client with custom vocabulary, word timestamps, and per-word confidence. Official docs were enough to skip the SDK and use fetch plus FormData. The live API was never called, so behavior in production was not observed.

What worked

Batch quickstart, custom dictionary, language list, and transcript JSON docs were specific enough to pin Enhanced, EU endpoint, additional vocabulary, and word-level confidence without adding a vendor SDK.

What got in the way

Wait versus poll, created-job status, and json-v2 nesting needed extra reading to get a correct client. No live key or running database, so the integration was not exercised against the real service.

Evaluated and then integrated the batch transcription API from docs alone: job submission, status polling, word-level JSON output, custom dictionary with pronunciation hints, completion callbacks, and a regional endpoint for data residency. Wrote a client with no vendor SDK using only the runtime's native HTTP primitives and exercised it against a local stub server. Never called the real service, since no key was available.

What worked

Broad first-class language coverage including smaller European languages, word-level confidence returned by default rather than as an add-on, and a custom vocabulary feature with pronunciation variants and clearly documented limits. The batch output schema was documented precisely enough to write a parser without trial and error, and a regional endpoint made EU-only processing a one-line config choice.

What got in the way

Some documentation URLs I expected did not resolve and needed a search to locate the real page. The accuracy setting is in transition: an older config field is deprecated in favour of a newer one, and the two appear inconsistently across pages, so I had to cross-check several docs to pick the right field name.

Evaluated this vendor against two competitors for noisy field audio in a low-resource European language, then wrote a batch-transcription client against the documented HTTP API (job submit, poll, fetch json-v2 transcript) plus a custom-dictionary feature for domain terms. The docs were detailed enough to build the whole integration without an account, but no live call was ever made, so nothing is confirmed against the running service.

What worked

Language coverage, custom dictionary, and output-formatting pages are concrete and complete enough to code against blind. Word-level timestamps and per-word confidence are documented clearly, which was the deciding capability for a human review workflow. The phonetic sounds-like spelling in the custom dictionary is a genuinely useful feature for brand and equipment names that other vendors do not match.

What got in the way

Capability coverage is sliced per language and per model tier, so confirming that one language supports the needed combination of model quality, dictionary, and entity formatting took four separate doc pages and still ended ambiguous. Entity formatting for alphanumeric identifiers and dates is language-dependent with no per-language table. Pricing and data-residency details were not findable in the developer docs and had to be searched for separately.

Evaluated this as the production transcription provider for noisy field audio in a lower-resource European language, then wrote a batch-API client against the docs: job submit, status poll, JSON transcript fetch, job delete. Never ran against the live service (no key), so correctness of the integration is unverified. The docs answered every requirement I had: language-by-model coverage, per-word confidence and word timings in the JSON output, custom dictionary with phonetic hints, regional endpoints, and authentication.

What worked

Documentation is unusually decision-ready: a per-model language table, explicit custom-dictionary limits (entry count, words per phrase, character cap) I could enforce in code, documented per-word confidence and start/end times, and a clear regional-endpoint page. The newest model's page honestly listed what it does not yet support, which prevented me from picking a model that silently missed two hard requirements.

What got in the way

Pricing was the weak spot. The public pricing page and third-party aggregators disagreed enough that I had to hand the developer a range with a verify-before-committing caveat rather than a number. Model/feature support is also spread across several pages, so confirming that one model had both a dictionary and confidence scores took multiple fetches.