Tavus callback_url payloads: what to check before you trust one

Tavus delivers conversation updates to a callback_url you set when you create a conversation, and the payload carries conversation_id, event_type, message_type and a timestamp. The Tavus page I read does not describe a signature or a retry policy, so treat the endpoint as untrusted until you have a check of your own, such as an unguessable path and a lookup of the conversation_id against conversations you actually created. Sume signs every job delivery and states its retry rule.

Facts about Tavus come from its Webhooks and callbacks and Create conversation pages, read 2026-10-10. The Sume facts are from Webhooks.

What Tavus sends

The events describe a live room, not a finished file.

What the same page leaves out

The page states that it does not specify webhook signatures, HMAC validation or retry logic. That is a gap in the page, not proof that none exists, so check the live reference before production use. Until then, design as if a callback could be forged or repeated: do not act on a callback whose conversation_id you did not create, and make every handler safe to run twice.

The create-conversation reference lists max_call_duration (integer seconds, default 3600) and participant_left_timeout under properties, and callback_url at the top level. Those are the fields that decide when a system.shutdown event shows up.

The Sume contrast

Sume has no live room, so it has no join or shutdown event. Its callbacks are terminal-only: job.completed, job.failed and job.canceled, one per finished job. The delivery is signed with HMAC SHA 256 over <timestamp>.<raw_body>, with x-sume-webhook-timestamp and x-sume-webhook-signature: sume-v1=<hex> headers, and Sume retries up to 10 attempts at a fixed 30 seconds with a 10-second timeout per attempt.

That suits a different job. A rendered avatar clip is a file you review before anyone sees it. A script of 4 to 60 seconds goes to POST /v1/avatar-1.0/talking-video with a webhook_url, and the callback tells you the MP4 exists. There is no interruption handling and no listening while speaking; Sume's docs describe Avatar 1.0 as script-driven and English-only.

A defensive receiver, for either vendor

• Put an unguessable token in the callback path, as a second factor beside any signature.
• Look up the id (conversation_id for Tavus, job_id for Sume) in your own table before acting.
• Return 2xx after a durable write, and do slow work from a queue.
• Store the raw body and headers of the first few deliveries, so you can compare them with the reference when it changes.
• Keep a polling path. For Sume avatar jobs that is GET /v1/jobs/{id}/status; the docs say to keep it even with webhooks on.

Which one fits which job

If you need an agent that listens, interrupts and answers in a live room, you want a conversational product, and the callbacks above are how you learn about the session afterwards. If you need a finished, reviewable file, such as a welcome message or a product explainer, a render job with a signed completion event is the simpler contract: one request, one terminal outcome, and nothing to reconcile mid-call.

Sume's honest limits are worth restating: Avatar 1.0 takes a script, it does not hold a conversation, it is English-only, and each clip runs 4 to 60 seconds by estimated duration. If your use case needs two-way conversation, say so before you compare prices.