Sume STT mode sync: transcribe a short clip in one request

To get a transcript back from one HTTP call on Sume, post to /v1/stt-1.0/transcribe with mode: "sync" and wait_timeout_seconds up to 30. If the job finishes inside the window you get 200 with the finished job. If it does not, you still get a 2xx (202) carrying the current queued or processing state and polling URLs, and you poll that job instead of submitting again. The rules come from the communication options in the Sume OpenAPI and Generation admission, read 2026-10-06.

What do the four modes do?

Every mode returns the job id in the first response. sync and subscribe are aliases for the same bounded wait. They are not a long-lived subscription, an event stream or a progress feed.

A sync call that handles both answers

wait_timeout_seconds bounds how long the HTTP request blocks, not how long the job may take. If the API has no waiter capacity, you also get the current job state with a 2xx. Always branch on the job status, never on the status code alone.

curl -sS -X POST https://api.sume.com/v1/stt-1.0/transcribe \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: stt-sync-demo-001" \
  -d '{
    "audio_url": "https://media.sume.com/example/clip.wav",
    "duration_seconds": 12,
    "mode": "sync",
    "wait_timeout_seconds": 30
  }'

When sync is the wrong choice

Sync holds a connection and a waiter slot. For a folder of clips, use async and poll, or webhook, so a slow job does not block your worker. On a timeout, keep the job id and call GET /v1/jobs/{id}/status; the docs are explicit that you should not submit a second paid job for the same intent. Sending the same Idempotency-Key makes the retry safe either way.

Completed results carry text, language fields when available, and words[] as { word, start, end } in seconds from the start of the audio. Word timings are always returned; there is no flag to enable them.