Tavus recording storage key_template vs Sume media URLs

Tavus lets conversation recordings land in your own cloud storage, and Sume works the other way: a finished artifact is a media.sume.com URL that a webhook or job result hands to you. You copy the file out if you want it in your own bucket.

Tavus facts are from its changelog, Sume facts from Webhooks, Generation admission and Jobs and results, all read 2026-10-01.

What does the Tavus changelog say about recording storage?

Two entries matter. Conversation recordings can be delivered to Google Cloud Storage and Azure Blob Storage, in addition to AWS S3. And setting key_template on an S3 recording_storage config makes Tavus write each recording under tavus/<your_workspace_id>/, so the recording role's permissions policy can be limited to your own prefix. Existing S3 setups continue to work unchanged.

Where does a Sume output file live?

On Sume's media host. A job.completed webhook carries payload.artifacts[], and each artifact has an id, a url such as https://media.sume.com/artifacts/..., a type and a content_type. The pages cited here do not describe delivery into a bucket you own, so plan on downloading the artifact yourself if you need a copy there.

How do I find out a Sume file is ready?

Use webhook mode. Sume sends terminal job events only (job.completed, job.failed, job.canceled); there are no progress or partial deliveries. Keep a polling fallback against the job, as Webhooks recommends. For production, the admission docs say to prefer async submit with an idempotency key. Our webhook security checklist covers signature checks.

Can I wait for the file in one call?

Only for short work. wait_timeout_seconds is clamped to 0..30, and that bounds how long the HTTP request blocks, not how long the job may take. Video jobs usually outlast it, so submit async and read the result when the webhook fires.