This product is explicit about sync limits, async orchestration and result guarantees. The help surface mirrors that philosophy.
Do this in order: 1) stop retrying the sync endpoint, 2) create an upload session with POST /v1/audio/uploads or ask POST /v1/audio/ingest for the right route first, 3) create an explicit async job. Sync is intentionally capped so oversized files do not enter an unreliable gray zone.
1) Query GET /v1/audio/uploads/:id. 2) If the session is completed and has no consumed_by_job_id, replay the completion step. 3) If a job id is already attached, stop retrying upload and open the job instead. The completion path is intentionally idempotent.
No. Design around text, segments, and vtt. Word timestamps are only preserved when the upstream provider returns them, so they remain optional enrichment rather than a stable contract.
Yes. Use the anonymous 30-second demo route on the public site. It is isolated from paid workloads, independently rate-limited, and intentionally capped so trial traffic does not compete with production jobs.
Open the async job detail page in the console. That page exposes transcript text, segment timing, VTT downloads, and timestamp metadata. The same shape also appears in the final result payload for clients integrating directly against the API.
Keep the upload id. Check the session state with GET /v1/audio/uploads/:id. Only replay completion once the upload reports completed. If the upload has already been consumed, follow the linked job id instead of sending the bytes again.