OpenRouter base64 input_audio vs Sume STT 1.0 audio_url

Sume does not take base64 audio in the request body for STT 1.0. You send audio_url, a link to the file, to POST /v1/stt-1.0/transcribe; OpenRouter's /api/v1/audio/transcriptions instead takes the audio as base64 in input_audio.data with a format field. Moving over means uploading or hosting the file first.

OpenRouter facts are from its speech-to-text guide; Sume facts from the OpenAPI file, read 2026-10-01.

How does OpenRouter take the audio?

The guide says to send a JSON body with base64-encoded audio and get JSON back with the text and usage statistics. input_audio.data is raw base64, not a data URI, and input_audio.format is required. language is an ISO-639-1 code and is auto-detected if omitted. It also accepts OpenAI-style multipart requests.

How does Sume STT 1.0 take it?

The OpenAPI description calls it the primary Sume STT 1.0 route, with the public model id sume/stt-1.0. Its example body is audio_url set to a media.sume.com artifact, an optional language_code such as ko, duration_seconds and mode: "async". A second example omits the language for auto-detection. Completed results include text and words[] word timings in seconds.

curl https://api.sume.com/v1/stt-1.0/transcribe \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"audio_url":"https://media.sume.com/artifacts/example/clip.m4a","language_code":"ko","mode":"async"}'

What changes in my code?

What about large files?

A URL keeps the request body small, but Sume must be able to fetch the link. The OpenAPI schema asks for a public HTTPS URL (a Sume media or attachment URL is preferred), and duration_seconds, if you omit it, reserves usage for 1 minute, so pass the real length for longer clips. Then poll status_url as described in Jobs and results. For a full pipeline, see the dubbing pipeline post.