Tavus live interaction events vs Sume terminal-only webhooks

Tavus sends events while a conversation is live, over the call's data channel, including utterances, speaking start and stop, tool calls and participant joins. Sume sends terminal job events only: job.completed, job.failed or job.canceled. There are no progress or partial webhooks, delivery is retried up to 10 times, 30 seconds apart by default, and each attempt times out after 10 seconds.

The two are different tools for different shapes of work: one is a stream, the other a receipt.

What Tavus emits

Tavus says the PAL broadcasts events back to your app, and lists utterance and utterance-streaming events, tool call and perception tool call events, perception analysis events, Canvas interaction events, started and stopped speaking events with speaker identification, participant joined and left events, and wake and sleep phrase detection events. They travel over Daily's sendAppMessage data channel with timestamp, seq and optional turn_idx and inference_id for ordering and correlation (Tavus docs: Interaction Events).

What Sume sends

A Sume webhook is a signed POST when a job reaches a terminal state, with the signature in x-sume-webhook-signature as sume-v1=<hex>. Use job_id as the dedupe key, and keep status_url polling as the recovery path, because ten refused attempts leave a failed delivery while the job itself still finished (Webhooks).

Design consequences

Build the Sume receiver to be fast and idempotent: verify the signature over the raw body, store job_id, return 2xx at once and process afterwards. A slow handler burns the 10 second budget and gets retried.

If you need a progress bar for a Sume job, a webhook cannot give you one. Poll the job status or read the job events when available, and treat webhooks as the signal to fetch the finished result.

• Reject an empty signing secret in your verifier rather than treating it as valid.
• A terminal event can be redelivered with a fresh timestamp and signature after automatic attempts are exhausted, and that does not use one of the ten.

A minimal receiver

A receiver should do four things in order: read the raw body, check the signature header against your secret, refuse if the secret is empty, and respond 2xx before slow work. Store job_id first so a repeated delivery is ignored.

Then fetch the job result from the status URL rather than trusting the body alone, and write the result to your own storage. If your endpoint was down for longer than the retry window, list recent jobs and reconcile, since the job reached its terminal state either way.