Azure batch: 95% of outputs within 120 seconds; Sume TTS waits 30

Azure's batch synthesis page states approximate latency: 50% of synthesized outputs within 10 to 20 seconds and 95% within 120 seconds. Sume TTS 1.0 does not publish a latency figure. Its sync mode waits at most 30 seconds, and if the job is not done it returns the queued or processing state with a status_url instead of an error.

Azure's numbers are from its batch synthesis page, read 2026-10-01; Sume's from the OpenAPI schema behind the API reference.

What do the two waiting models look like?

Azure is poll-only; Sume has a short bounded wait.

Will a 30-second sync wait cover Azure-like timings?

For about half of Azure's outputs, probably. For the slow tail, no, and Sume's own docs say the 30 seconds bounds the HTTP wait, not the job. Treat any latency number as an assumption until you time your own script. A short line may finish inside the wait; a long one will not.

What is the safe client pattern?

Submit with sync and a Idempotency-Key. If the response is already complete, use it. If not, poll status_url and respect next_poll_after_seconds. Never post the same line again to get an answer; with a key a retry returns the original job.

curl -X POST https://api.sume.com/v1/tts-1.0/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: greeting-001" \
  -d '{
    "transcript": "Welcome back.",
    "avatar_handle": "@narrator",
    "mode": "sync",
    "wait_timeout_seconds": 30
  }'

When should I skip sync entirely?

For long scripts and for batches. Use async or a webhook so no HTTP connection is held open. Sync is for a single short line where you want one round trip.