A couple call id's that show: 019d7bda-9adf-7000-8576-4687ab38b6dc > Apr 11, 02:23:37.454 2a596f99-82bb-4dab-90fc-b7910b9dc7b0 > Apr 10, 22:05:00.435 assistant snippet: MessageEvents json "clientMessages": [ "transcript", "hang", "function-call", "speech-update", "metadata", "conversation-update" ], "serverMessages": [ "end-of-call-report", # this is what I am listening for "status-update", "hang", "conversation-update" ], You can see that the end-of-call-report exists but never gets sent to my webhook. This used to work as I used it to trigger my db with the full report of what happened. I am instantiating the assistant through my webpage with javascript api (not phone call) 1. Can you please let me know if this is the expected way to work with how I am using it 2. If not, what is the best event to read in my system to know the call is completed and all of the analysis and structured data has completed. My goal is to get an event when the entire analysys/structured data has completed and I can query the call log and extract data. Thank you

Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team

You’re not doing anything wrong this usually breaks because end-of-call-report isn’t consistently emitted for web-initiated sessions (it’s more reliable on telephony flows). Instead, listen for the final conversation-update or status-update where the call state is marked completed, then add a short delay before pulling the call log — that’s when the structured analysis is actually ready. Relying on end-of-call-report alone will be flaky in your setup. I’ve handled this exact pattern before and can help you wire a more reliable trigger if you want. Quick one are you currently persisting the call ID and polling the API after completion, or only relying on webhooks? @chris.happy.dad

I have tried it both ways but for a while the end-of-call worked so I changed over so I didn't have to hold my lambda function open. I can make a sqs queue that checks every 30 seconds. What would I be checking for if I use the api? would it be an analysis endpoint or something?

Yeah I get why you moved to end-of-call-report, it’s cleaner, but right now it’s not reliable for web sessions so you’ll need a hybrid approach. Best practice is to trigger off status-update when it shows completed, then push the callId to SQS and poll the call details endpoint until you see analysis and usage fields populated, that’s your true “done” state. You’re not looking for a separate analysis endpoint, everything like transcript, structured data, and token usage resolves on the call object once processing finishes. This way you avoid holding your lambda open and keep things deterministic instead of guessing timing. If you want I can help you design a clean retry and backoff flow so you’re not doing messy polling, how are you currently fetching the call object from Vapi? @chris.happy.dad

Thanks for the offer. I will remove all of the structured data and analysis from the vapi side and handle it on my side. This should speed up the call resolution so I can get token usage. Thanks for the clarification.

Hi, Thanks for reaching out.