Developers Kept Asking for a Voibe Speech-to-Text API. We Kept Saying No — Until Today

For months now, the most common email in our inbox hasn't been a support ticket. It's been developers asking the same question: "Can I get Voibe transcription as an API?"

We kept saying no. Not because it was hard to build — because every transcription API we could point to works the same way: your audio gets piped to a Big Tech AI lab, transcribed, and parked on someone's servers under a retention policy nobody reads. Whether it's your customers' voice or your own meetings, someone trusts you with that audio — and most voice stacks quietly ship it to a third party. We refused to be that third party.

TL;DR: Today the answer is yes. The Voibe speech-to-text API is officially live (August 2026), built the same way we built Voibe: open models only, on our own inference stack — no Big Tech AI lab in the loop — with zero retention: the recording is deleted the moment the transcript exists, never used to train models, and every read is scoped to your key. Your audio is nobody's data. Including ours. The surface is three REST endpoints and a bearer token: send an audio file, get back a diarized transcript with per-segment timestamps, a flat text string, and a summary you steer with a prompt of up to 2,000 characters. Billing is per second, and only on DONE — queued, processing and failed jobs cost nothing. Prepaid packs run $10 for 2,000 minutes ($0.30/hour) down to $100 for 24,000 minutes ($0.25/hour), minutes never expire, and new accounts get 15 free minutes with no card.

This post covers why we said no for so long, the two ways people are already using the API, the two decisions in it we'd defend hardest — the billing model and the no-SDK surface — and what it deliberately is not.

The whole launch in one table, then each row in detail.

The standard way to ship a transcription API is to not really ship one: you wrap a Big Tech AI lab's speech endpoint, mark it up, and pass your users' audio through servers you don't control, governed by a retention policy you didn't write and they'll never read. Some of those providers run opt-out training programs on that audio, store it for up to 12 months, or bill every failed attempt — sometimes all three. We weren't willing to put our name on that pipeline, so the answer stayed no.

What changed is that we built our way out of the objection. When we launched Voibe for Windows in July, the constraint we set was that no third-party AI lab would ever be in the audio path — which meant building and operating our own inference stack: open-source models, our servers, transcribe-then-destroy. That left us holding the thing every one of those emails was actually asking for: a transcription pipeline whose privacy terms fit in one breath.

So we built the API the same way we built Voibe:

• Open models only, on our own inference stack. No Big Tech AI lab in the loop — not for transcription, not for cleanup.
• Zero data retention. Your audio is deleted the moment the transcript exists, and nothing you send is ever used for training.
• Your audio is nobody's data. Including ours. Every read is scoped to your key.

The same cloud, the same models, the same retention terms as the dictation app — with an HTTP surface instead of a hotkey.

The early usage splits cleanly into two camps, and the API was shaped for both:

1. Give ears to your agents

Claude Code, Claude Cowork, Codex, Cursor, OpenClaw, Hermes — anything that speaks MCP can hear with one command:

claude mcp add --transport http voibe https://api.getvoibe.com/mcp \
  --header "Authorization: Bearer $VOIBE_KEY"

The shape of the workflow: a standup recording lands in your folder or bucket → your agent transcribes it, posts decisions-only notes, and opens the follow-ups. No connector to build, no plugin to maintain — the Zoom-recording walkthrough shows the whole loop end to end, including the setup for each client.

2. Build voice into your product

Plain HTTP, no SDK. Send audio, get back JSON your app can act on: who spoke, when they spoke, and what it all meant — speaker labels, per-segment timestamps, and a summary shaped by your own prompt. You're building on the same infrastructure we run Voibe's own dictation on, with the retention terms already handled, so the privacy story you tell your users is one you can actually keep.

Both camps get the same deal underneath: per-second billing that only counts delivered transcripts, and audio that's gone the moment the text exists. Now the detail.

The API surface fits in a sentence: POST /transcripts creates a job and returns a signed upload URL, you PUT your audio file to that URL, and GET /transcripts/{job_id} returns the status and, on completion, the transcript and summary. A fourth call, GET /transcripts, lists your jobs, up to 200 per page. Auth is a bearer token in a header. Here's a job from a terminal:

curl -s -X POST "https://api.getvoibe.com/v1/transcripts" \
  -H "Authorization: Bearer $VOIBE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"diarize": true, "prompt": "Summarise as decisions, owners and deadlines."}'

All three body fields are optional: diarize defaults to true, prompt steers the summary (more on that below), and webhook_url gets the finished payload POSTed to you instead of polled.

There is no SDK, and that's a decision, not a gap. Every client library is a dependency someone has to update, a version that can drift, a framework choice made on your behalf. Three HTTP endpoints need none of that — which matters most in the place we expect this API to live: inside agent loops, where every added dependency is a potential breaking change. Keys come from the API keys page; the full reference lives in the API docs.

Most transcription APIs bill on audio submitted. Send a file, hit a timeout, retry, hit a 5xx, retry again — every one of those attempts meters, whether or not you ever see a transcript. When we audited eight speech-to-text APIs for agent workloads, that failure-billing gap turned out to matter more than any headline rate.

So the billing model here is the one we wished the rest of the field had:

• Jobs are charged only on DONE. A job's status runs QUEUED → PROCESSING → DONE or FAILED, and only DONE costs anything. On FAILED, the error field tells you why and nothing is billed.
• Billing is per second. A 3 minute 24 second file bills 3.4 minutes, not 4. There's no per-request minimum punishing short clips.
• Minutes never expire. Buy a pack, use it whenever — which matters when your volume is lumpy, as agent volume always is.

The retry math is where this stops being philosophy. Four attempts on that 3:24 file bill 13.6 minutes on a submission-billed vendor and 3.4 minutes here. At that retry rate, a $0.258/hour sticker price becomes roughly $1.00 per effective delivered hour — against $0.25 to $0.30 here, where the failures were free.

The packs: $10 for 2,000 minutes ($0.30/hour), $25 for 5,250 ($0.29/hour), $50 for 11,000 ($0.27/hour), $100 for 24,000 ($0.25/hour). A one-hour meeting costs 30 cents at the entry pack. New accounts start with 15 free minutes, no card.

The response is one JSON object carrying three things an agent — or a script, or you — usually needs next:

• A diarized transcript array — speaker label plus start and end in seconds for every segment. Diarization is a diarize parameter that defaults to true, with no separate charge. Keep the original recording around and those timestamps double as seek positions.
• A flat transcript_text string — the same content as one block, ready for search, pasting, or feeding to a model.
• A summary shaped by your prompt — up to 2,000 characters of instruction, passed when you create the job. "Summarise as bullet points, focus on decisions" comes back as exactly that, which removes a separate language-model call from the loop.

One boundary in that design we'd defend anywhere: the prompt changes the summary only, never the transcript. The transcript stays a verbatim record you can quote and audit; the summary is the disposable, steerable part you feed downstream. Most APIs give you the transcript and leave summarisation to a second, separately billed call — here it's the same response.

For the full end-to-end walkthrough with the curl calls, the response shape, and a batch script, we've already written it up: how to transcribe a Zoom recording takes the most common first job — a meeting file sitting in a folder — from disk to finished notes.

This is the part we care most that you hold us to. The API inherits the architecture from the July launch unchanged:

• The recording is deleted the moment the transcript exists. It is not archived and not kept for review. There is no audio library on our side to breach, leak, or hand over.
• Never used to train models. Nothing you send is fed into model training — ours or anyone else's.
• Open-source models on our own infrastructure. No third-party AI provider is in the audio path.
• Every read is scoped to your key. A job can only be read by the key that created it; one customer's transcripts are never visible to another.

And the clause that makes it a standard rather than a perk: this is the default on every tier. It applies to the free 15 minutes exactly as it applies to the $100 pack. There's no retention setting to find, no zero-retention mode to request, no enterprise plan to reach. Elsewhere in this market, zero retention is a mode you apply for, a custom policy against a 12-month default, or a program you opt out of per request — we documented the pattern vendor by vendor in the API roundup, and what the fine print does to such promises generally in zero data retention, explained.

One honest precision: deleting the audio is not the same as storing nothing. Transcripts persist — that's what makes them fetchable by job ID — under the key-scoping above. If even that is too much for a given recording, the right answer isn't our API; it's a local model on your own machine, and we've argued that case for years.

Three endpoints and a bearer token is already a small enough surface for an agent to drive raw. But the MCP server at https://api.getvoibe.com/mcp — the one-command connect from the agents section above — narrows it further, to four tools: create_transcription_job, get_transcript, list_transcripts, and get_balance. From there, "transcribe my latest Zoom recording and summarise the decisions and action items" is the whole integration, in Claude Code, Claude Cowork, Claude desktop, Cursor, Codex, or anything else that speaks remote MCP — the per-client setup is in the Zoom guide.

The scope is deliberately narrow: an agent with this connected can start jobs, read results, list them, and check the balance. It cannot see or create API keys, and it cannot buy minutes. Connect it to a shared workspace without thinking twice.

Three limits, stated plainly, because a launch post that hides them is an ad:

• It's not streaming. This is a batch API for audio that already exists as a file — recordings, uploads, queued jobs. If a human is waiting on partial text mid-utterance, you want a streaming vendor, and in our own roundup we name Deepgram as the pick for that job, not us.
• It doesn't publish a data-residency option. Zero retention is the privacy model; if your requirement is "processed in the EU" specifically, vendors like Gladia and ElevenLabs publish regional options and we currently don't.
• The free tier is for verifying, not evaluating. Fifteen minutes is enough to confirm the response format and run a short file end to end. A full accuracy bake-off on your own audio needs a $10 pack — which is, deliberately, the cheapest commitment in this market.

If any of those rules you out, the roundup compares eight providers honestly, including the ones that beat us on price. We'd rather you pick the right tool with clear eyes than churn off the wrong one.

The basics

What is the Voibe speech-to-text API? A batch transcription API, live as of August 2026: create a job, upload an audio file, and get back a diarized transcript, a flat text string, and a prompt-steered summary — from the same zero-retention private cloud behind the Voibe dictation app.

Is there an SDK? No, by design. It's three REST endpoints with a bearer token; anything that can make an HTTP request can use it, and MCP clients can connect the server at api.getvoibe.com/mcp instead.

Does it do real-time transcription? No. It transcribes files, not live audio. For streaming, use a streaming vendor.

Pricing

What does it cost? $10 for 2,000 minutes ($0.30/hour), $25 for 5,250 ($0.29/hour), $50 for 11,000 ($0.27/hour), $100 for 24,000 ($0.25/hour). Per-second billing, only on DONE, and minutes never expire.

Is there a free tier? 15 free minutes on a new account, no card — with the same deletion behaviour as paid usage.

Do I need a Voibe dictation subscription? No. The API is prepaid and separate; the $7.50/month, $59/year and $149 lifetime plans cover the desktop app.

Privacy and your audio

What happens to my recording? It's deleted the moment the transcript exists, never archived, and never used to train models. Every read is scoped to the key that created the job.

Is that a setting? No — it's the default on every tier, including the free minutes. There is nothing to configure.

Is anything stored at all? Transcripts are — that's what makes them fetchable by job ID, scoped to your key. The audio is not.

Every one of those emails deserved a yes. It just had to be a yes we could stand behind: open models on our own inference stack, zero retention, and an audio path with no Big Tech AI lab anywhere in it. Your audio is nobody's data — including ours. Add the mechanics we'd want as customers — three endpoints, a bearer token, per-second billing that only counts delivered transcripts — and that's the launch.

If you've got a folder of recordings waiting, the fastest path is the Zoom-recording walkthrough. If you're choosing a vendor properly, start with the eight-API comparison — we wrote it before this launch, and it names the workloads where we're not the pick. And if you just want to try it: grab a key and spend your 15 free minutes → No card required. Private, smooth, fast — like all things Voibe.