Common integration questions
This product is explicit about async orchestration, upload recovery and result guarantees. The help surface mirrors that philosophy.
Why should production integrations use async jobs?
Create an upload session with POST /v1/audio/uploads or let POST /v1/audio/ingest create one, upload the bytes, then create an explicit async job. This keeps retries, status polling, webhooks and long audio in one durable flow.
What if upload succeeded but complete failed?
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.
Are word timestamps guaranteed?
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.
Can I demo the API without an account?
Yes. Use the anonymous 90-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.
Where do I see VTT and timestamps?
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.
How do I retry a weak-network upload?
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.