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 [email protected]

And the whole response:

{
  "model": "eroq-scribe-one",
  "text": "That noise is the reactor missing its coolant flush.",
  "usage": { "credits_spent": 5, "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.

Five credits, whatever the length

Scribe One bills a flat 5 credits per request. Not per minute, not per character. That single line decides the shape of every workflow built on it, because it inverts the economics you learned on the speech side, where a short line still costs a whole 100-character block.

Here it is the request that is the unit, so:

• A four-second voice message costs 5 credits. So does a seven-minute one.
• Chopping audio into small pieces for tidiness is the most expensive thing you can do. Twenty one-minute clips is 100 credits; the same twenty minutes as three requests is 15.
• Conversely, the flat rate means you can afford to transcribe things speculatively — every voice note in an inbox, every clip in a library — without modelling per-minute cost.

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, so 20 credits for the whole thing.

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?

A flat 5 credits per request, regardless of the length of the audio. Since the request is the billing unit, the cheapest workflow sends the longest file that fits under the 8 MB cap rather than many small ones.

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 50 credits cover ten transcriptions before you spend anything.