Structured JSON
Lines, speakers, word-level timestamps — easy to parse.
API
API for work transcripts
Send recordings to processing — receive status, text, timecodes, and export.
or
Ready webhooks
We push an event the moment the transcript is ready.
Several formats
JSON, DOCX, TXT, SRT, VTT — pick in the request.
No double billing
Re-sending the same file does not start a new job.
Built for people who work from recordings
Teams
Turn meeting recordings into notes and follow-up text.
Researchers
Review interviews with speakers, timestamps, and search.
Creators
Make transcript text for captions, posts, and show notes.
Students
Convert lectures and webinars into study material.
In depth
When recognition has to be embedded, not opened in a browser
Manual uploads are fine while transcripts are rare. The moment your product gains user recordings, telephony calls, or a stream of training videos, clicking a button no longer scales — processing must start programmatically and land where it's actually needed: in a record, in search, in analytics. What a developer needs isn't a recognition service in the abstract but a predictable contract: how to submit a job, how to learn it's done, in what shape the text arrives. A speech-to-text API covers exactly that — it turns a conversation into a structure your code parses with no human in the loop and no daily manual export.
Three steps of a REST integration
The scheme is simple and repeatable. First, get an API key in the developer console and keep it server-side, not in the browser. Then send a POST with a file or a link to the recording — you get a job identifier back, processing runs asynchronously, and your thread isn't blocked. You learn completion two ways: subscribe to a webhook, where the service pushes a done event, or poll the status by identifier. The output is JSON with utterances, speakers and word-level timecodes, easy to parse: split into segments for search, feed BI, or assemble subtitles. The same result can export to DOCX, TXT, SRT or VTT — you pick the format in the request.
Rakes people step on during the first integration
First: the key in client code. If it ends up in a browser bundle, it will be extracted, so make every call from the backend. Second: no idempotency — the network blinks, a retry fires twice, and you count two runs. Resubmitting the same file won't reprocess it, but keep your own external ID and idempotency key. Third: logs — record statuses and identifiers, but not the transcript text, or private data leaks into your logging system. And separate API errors from network ones: a 5xx is worth retrying with backoff, a format validation error isn't — validate the file before sending.
More workflows
Pick a recording type, format, or workflow.
Transcription questions
How do I get started with the speech-to-text API?
Create an account, get a key in the developer console, and keep it server-side. Your first call is a POST with a test recording: you get a job ID back. Subscribe to a webhook or poll the status by that ID, then parse the JSON with text and timecodes. Once the contract is clear, connect your production stream.
Can I test the API for free?
You can gauge recognition quality on your own recording before any integration — the first transcript runs without a card. Programmatic key-based access opens on paid plans, and billing is by minutes of processed audio, so keep trial runs on short files.
In what form does the result arrive?
The primary format is JSON: an array of utterances tied to speakers with word-level timecodes, convenient to split into segments for search or feed into analytics. The same job also exports to DOCX, TXT, SRT and VTT, so subtitles or a finished document don't need a separate service.
How do I know a transcript is ready?
Two ways. First, a webhook: the service pushes a completion event and your handler fetches the result without polling. Second, periodic status requests by job identifier. Webhooks are leaner and faster, polling is simpler for a prototype; in practice they're often combined for reliability.
Are speakers and timecodes available via API?
Yes, speaker separation and timecodes are part of the JSON response, not only the web view. Each utterance is tied to a speaker and a time position, so via the API you can build phrase search, precise jumps to a moment, and subtitles without replaying audio by hand.
What should I do about failures and retries?
Retry 5xx errors with increasing backoff; retries are pointless for format validation errors — check the file before sending. Keep an external ID and idempotency key so a retry won't create a duplicate, and log statuses but not transcript text, to avoid carrying private data into logs.
Vibe2Text
Upload once. Leave with usable text.
Upload audio or video while launch access is free. The start period has no duration cap.