Transcription with Scribe One — speech to text in one request

Scribe One is the smallest endpoint on the platform and the one people most often build the wrong thing on top of. It takes an audio file and returns the words in it. Not a subtitle file, not a speaker-labelled transcript, not a stream — the words. Most of the work in a transcription feature is arranging your side of the pipeline around that fact, so here is the endpoint honestly, and the workflow that fits it.

The whole request

One multipart POST, no job to poll, no webhook:

curl https://eroq.ai/v1/audio/transcriptions \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -F model=eroq-scribe-one \
  -F file=@voice-message.wav

And the whole response:

{
  "model": "eroq-scribe-one",
  "text": "That noise is the reactor missing its coolant flush.",
  "usage": { "audio_seconds": 4.2, "credits_spent": 1, "credits_remaining": 882 }
}

The file part must be wav or mp3. Other containers are rejected with unsupported_format rather than silently transcoded, so if you are capturing from a browser, either record WAV through WebAudio or re-encode client-side before upload — an .ogg or .m4a straight from a recorder will bounce. The full parameter list is on the transcription reference.

1 credit a minute

Scribe One bills 1 credit per started minute of audio. The length is read from the file itself before the transcription runs, and the response reports it next to the charge as usage.audio_seconds, so the bill is always checkable against the audio you sent.

What that means in practice:

• A four-second voice message costs 1 credit. So does a 59-second one; 61 seconds is 2 credits.
• An hour of audio is 60 credits, however you send it. Splitting only costs the rounding: each request rounds its own last minute up, so twenty clips of 30 seconds are 20 credits where the same ten minutes in one file would be 10 credits.
• Voice notes are the cheap case by design. An inbox of short messages costs 1 credit each, which is what makes transcribing everything speculatively — every voice note, every clip in a library — affordable.

Automatic language detection, and when to override it

Language is detected from the audio. There is no required parameter and no per-language model to select, which means a multilingual inbox works with no routing logic on your side.

The optional language field takes an ISO code (en, fr, de) as a hint, not a constraint. It is worth sending in exactly two situations: when you already know the language from context — a user's profile setting, a channel that is always one language — and when short or noisy audio is being detected wrongly. A four-word clip gives the detector very little to work with, and a hint fixes it for free.

The 8 MB ceiling, and how to get under it

Uploads are capped at 8 MB, which the docs put at roughly eight minutes of compressed audio. That is a deliberate fit for voice-message-length material rather than for archives, and it is the constraint you design around.

Bitrate is the lever. Eight megabytes is about eight minutes at a typical podcast bitrate; re-encode to 64 kbps mono and the same 8 MB holds roughly twice that, with no meaningful loss for speech. So a long recording becomes a handful of requests:

ffmpeg -i episode.mp3 -c:a libmp3lame -b:a 64k -ac 1 \
  -f segment -segment_time 600 part%02d.mp3

Ten-minute segments at 64 kbps mono land around 4.8 MB each — comfortably inside the cap with room for a long first sentence. A forty-minute episode is four requests of exactly ten minutes, so 40 credits for the whole thing — the same as it would cost in one piece, because whole-minute segments leave no rounding to pay.

One caveat with fixed-length segmentation: a cut can land mid-word, and the two halves will each be transcribed as something slightly wrong. If the seam matters, segment on silence instead of on a timer, or overlap the segments by a second or two and stitch the overlap out when you join the text.

Transcription shares the media rate limit — 6 requests per minute per key on a free workspace, multiplied by your plan — which is far more than a segmented episode needs and worth knowing if you are backfilling an archive. Failed requests refund themselves, so a network blip during a backfill does not leave you paying for nothing.

Captioning your own narration

The common case: you have an MP3 and no script. Maybe you recorded it yourself, maybe it is an old episode, maybe it is a voice note you now want as text. Transcribe it, then do the timing in the tool that already owns your timeline.

Be clear about the division of labour, because this is where people expect too much. Scribe One returns a block of text. It does not return an SRT, a VTT, or per-word timings, so it cannot place captions on a timeline by itself. What it gives you is the accurate text, which is the part caption tools are worst at and you are slowest at typing. Paste it into your editor's caption aligner and let that do the timing pass.

If you split the audio yourself, you get coarse timing for free — a segment that starts at 10 minutes produces text that belongs at 10 minutes. Cue-level accuracy still comes from the aligner, but chapter markers, show notes and a searchable index only need the segment-level anchor you already have.

The other direction closes the loop: transcribe a user's voice message, answer it with a chat completion, and render the answer back with /v1/audio/speech. Voice in, text reasoning, voice out is three calls and no streaming infrastructure — TTS for AI characters covers the speech leg and its latency tricks.

The limits, stated plainly

Build around these rather than into them:

• No diarization. The response has no speaker labels and no turn boundaries. If you need to know who spoke, record participants on separate tracks and transcribe each one, then interleave by timestamp on your side.
• No word-level or segment-level timestamps. The response is text. Timing comes from how you cut the audio, or from an aligner downstream.
• No subtitle file. No SRT, no VTT, no JSON cue list.
• No streaming or real-time transcription. It is a request and a response over a finished file, not a live socket.
• No CLI command. The eroq CLI covers image, video and speech; transcription is a curl or an SDK call.

None of that is a roadmap hint — it is what the endpoint does today, and a feature designed on top of assumptions it does not meet is the most expensive way to find out. If your product needs speaker labels on a group call, the honest answer is separate tracks, not a parameter.

For the broader picture of what the voice side of the API offers, the voice platform page has the endpoints in one place, speech to text is the one-paragraph definition, and pricing has the credit packs if you are sizing a backfill.

FAQ

How much does Scribe One transcription cost?

1 credit per started minute of audio, with a one-minute minimum per request. A voice note is 1 credit, an hour of audio 60 credits. The measured length comes back as usage.audio_seconds, and a failed request refunds itself.

What audio formats does the transcription endpoint accept?

WAV and MP3 only. Anything else returns unsupported_format rather than being converted, so re-encode on your side first — recording WAV through WebAudio in the browser is the usual fix for a capture pipeline.

Can I get timestamps or speaker labels?

No. The response contains the transcribed text and the usage block, with no per-word timings, no segments and no diarization. Cut the audio into known offsets for coarse timing, use separate tracks per speaker when you need labels, and run an aligner downstream when captions need to be frame-accurate.

Does it detect the language automatically?

Yes, language detection is automatic and needs no parameter. You can pass an ISO code in language as a hint when the audio is short or noisy, or when you already know the language from the user's context, which improves accuracy at no extra cost.

Got an audio file and a key? One curl gets you the text. Get an API key and the first 40 credits cover 40 minutes of audio before you spend anything.