Vapi Has No End-of-Chat Webhook. Here Is What To Do Instead.

Vapi has no end-of-chat webhook. Voice calls get end-of-call-report, which arrives once the call is over with the final transcript attached. Chat has no equivalent event. Nothing tells you a conversation finished, and nothing hands you what was said.

This is not an oversight waiting to be patched. A phone call has a hangup, which is an unambiguous moment the platform can detect and report. A chat session has no such moment. Someone reads the answer they wanted and closes the tab, or leaves it open in a background tab for two days, or comes back an hour later and asks one more thing. There is no event because there is no ending.

Once you accept that, the design problem changes shape. You stop asking how to be notified and start asking what you cannot afford to lose.

Why the obvious workarounds do not hold

Three approaches get suggested every time this comes up, and each one fails in a way worth understanding before you build on it.

• Wait for chat.deleted. It fires, but it carries no transcript and no summary. It also describes a data lifecycle event rather than a conversation ending, and almost nobody deletes a chat they have finished with.
• Send every message to your server. This works, in the sense that the data arrives. You now handle a webhook per message and still have no way to know which message was the last one, which is the thing you were trying to find out.
• Detect the end in the browser. Unload and visibility events are best effort by design, they are least reliable on mobile, and the visitor who closes the tab without warning is disproportionately the one you needed to capture.

All three share the same flaw. They are trying to recover the conversation after the person has gone, which is the one moment when you have no leverage left.

Two traps that will cost you an afternoon

Before the pattern, two things that are genuinely hard to discover, because in both cases the tooling tells you everything is fine.

Liquid variables do not resolve in chat-mode tool fields. Values like assistant.id and chat.id are how you would normally avoid hardcoding identity into a tool. In the dashboard they render as neat pills, exactly as they do for voice, so the configuration looks correct. In chat mode they never resolve, and your endpoint receives them unsubstituted. The workable answer is to stop fighting it: keep tools per assistant with the identifier written in directly, and generate that configuration programmatically later if you are onboarding clients at volume.

The list endpoint omits message content. Listing recent chats gives you ids, timestamps and metadata, and no record of what anyone said. The messages only appear when you fetch a chat individually. So a reconciliation job is not one call, it is one call to find candidates and then one call per candidate to hydrate it. This matters for how you schedule it, and it is not obvious until you have already written the loop that does not work.

The pattern that holds up

Split the problem in two, by how much each half matters.

Capture during the conversation, not after it. Give the assistant a save tool and instruct it to call the tool as soon as it has the things you actually need, typically a name, a way to reach the person, and why they came. The model calls it mid-conversation, while the visitor is still there. If they close the tab immediately afterwards, you already have the lead. This half is not allowed to fail, so it runs on the only mechanism under your control: the assistant's own behaviour during the session.

Reconcile afterwards, on a delay. A scheduled job runs roughly ten minutes behind, lists recent chats, hydrates each one, and attaches the full transcript to the record the tool already created. Ten minutes is not a magic number. It is long enough that a conversation which looked finished usually is, and short enough that someone checking the dashboard over a coffee sees the whole thing. This half is allowed to fail, because failing means a lead with a slightly thinner record rather than no lead at all.

One consequence of the first trap: because the tool call and the chat record do not share an identifier you can rely on, the two halves get matched on content instead, using the contact details that appear in both. It is less elegant than joining on an id and it is what actually works.

A note on which model runs the chat

Worth knowing if you are running voice and chat from one configuration. A small, fast model is the right default on the phone, where every extra hundred milliseconds is audible and telephony has already spent most of your latency budget getting the audio there.

That same model is the wrong choice for chat. Chat has no latency pressure, nobody notices an extra second of typing indicator, and the small model skipped tool calls often enough to matter. Since the entire capture strategy depends on the assistant reliably calling one tool, that is not a trade worth making. Separate assistants, separate models, separate prompts per channel.

The general shape of this

Vapi is a specific instance of a problem that turns up whenever you integrate with a platform you do not control. The event you need does not exist, and the events that do exist sit adjacent to it.

The instinct is to find a clever proxy for the missing event. The better move is to sort your requirements by what you cannot afford to lose, capture that during the window when you still have influence, and let everything else arrive late and imperfectly on a job that is permitted to fail.

Applied here, that means the lead is captured by the assistant mid-conversation and the transcript catches up later. The version that waits for an end-of-chat webhook captures nothing at all.

If you are building on a platform whose docs stop exactly where your problem starts, that is most of what custom app development actually is. The scoping engagement that works out what you are really up against, before anyone commits to a number, is the MVP Roadmap.