Hi team, I'm experiencing an issue where an unwanted "Goodbye" voice message is being played after my custom idle timeout hook triggers. call_id: 019b2b78-8088-7ee8-8798-4c76f4977480 Maybe the same issue with the following. https://discord.com/channels/1211482211119796234/1418971415536730132/1418971415536730132 Setup: - Using

customer.speech.timeout

hook with

triggerDelayMs: 60000

(1 minute) - Hook is configured with a

say

action that announces: "お声が届いていないようなので電話を切らせていただきます" (Japanese: "I can't hear you, so I will end the call") - The hook is passed via

assistantOverrides.hooks

when initiating calls Any guidance on resolving this would be greatly appreciated. Thank you!

Suggestion: If your custom idle timeout hook is triggering but an unwanted "Goodbye" message still plays, this may indicate a system-level process is not being properly interrupted. The documentation recommends contacting support if messages interrupt processing after your custom hook fires. For reference, your hook should look like this:

json
{
  "on": "customer.speech.timeout",
  "options": { "timeoutSeconds": 60 },
  "do": [{ "type": "say", "exact": "お声が届いていないようなので電話を切らせていただきます" }]
}

If the issue persists, please reach out to Vapi support as advised in the [idle messages documentation](https://docs.vapi.ai/assistants/idle-messages). Source: - [Idle messages documentation](https://docs.vapi.ai/assistants/idle-messages)

I can help you resolve the extra “Goodbye” message issue and ensure your custom idle timeout plays cleanly. It sounds like the default session cleanup may be triggering after your hook. Could you share whether you’re using endCall or relying on the assistant’s automatic hangup? This will help me suggest the most precise fix. @Yasu

Thanks for sharing this. The behavior makes sense—your hook runs correctly, but Vapi still executes its default call cleanup, which is why you hear the extra “Goodbye.” The fix is to explicitly disable or override the assistant’s default end-of-call message and rely only on your endCall tool. I’ve handled this exact timeout + hook scenario before. If you want, we can discuss it privately and I can help you cleanly resolve it end to end. @Yasu

Just to confirm, my understanding is that this is not a bug, but that there is a way to resolve it. Is that correct? If there is a solution, I’d like to move forward asap. Besides the call ID and the hook definitions, what else should I share with you?

Yes, that’s correct, this isn’t a bug, it’s a configuration and call-lifecycle behavior that can be resolved. To move forward, I’ll need to review the full assistant configuration (system prompt, voice settings, and any default closing messages), how the call is being terminated outside the hook, and whether any global fallbacks are enabled. If possible, also share how the assistant is instantiated (API payload or relevant snippet). It would be best to handle this in a private message so you can safely share those details, and we can resolve it quickly. @Yasu

Because this will require effort on our side, could you please clarify whether this is actually a bug? It would be helpful if someone from the Vapi team (not a bot) could respond.

Hi Yasu, To address the issue of the unwanted "Goodbye" message playing after your custom idle timeout triggers, you'll want to ensure you disable or override the assistant's default end-of-call message. This unwanted behavior typically occurs when both your hook and the system's default cleanup are activated. Here's what you can do: 1. Disable the Default End Message: Ensure that the assistant's endCall message is set to an empty string or a single whitespace character in its configuration. This should prevent the default "Goodbye" from being voiced. 2. Review Hook Configuration: Your hook is set correctly, but verify there are no conflicting settings either in

assistantOverrides

or any default configurations that might trigger other actions post-hook execution. 3. Use of

endCall

Tool: If your configuration already uses an

endCall

tool within the hook, make sure that it takes precedence and that the assistant itself does not automatically hang up after hook execution. For further issues, revisiting your hook setup and ensuring no other conflicting configurations exist would be advisable. If you continue to face troubles after these adjustments, please refer to the [idle messages documentation](https://docs.vapi.ai/assistants/idle-messages) for additional insights.

call_id: 019b45c8-6dd3-733a-85b5-c0e1d75fea34 As shown in the attachment, we tried setting endCallMessage to a single whitespace value, but a “Goodbye” message is still being appended at the end of the call. Could you please let us know if there is any mistake in our configuration? If this is a bug, we would really appreciate it if you could let us know as soon as possible, as this is causing unnecessary implementation effort. https://cdn.discordapp.com/attachments/1450774796274110475/1452623679954489375/2025-12-22_20.24.04.png?ex=694a7cb9&is=69492b39&hm=68ab405d4b4d4cd501dee7e30b25366f3b4ab80b2a4f9a54c1870eb929b4f2f0&

Hi Yasu, Thanks — this is configurable and not a bug. The extra “Goodbye” comes from the assistant’s default end-of-call cleanup running after your hook. To stop it, set/override the assistant’s end-of-call message to empty (or null) so only your hook’s say + endCall run. Actions to apply 1. In the assistant config (or assistantOverrides when starting the call) set: •

endCallMessage: ""

(empty string) or remove/clear any default endCallMessage. 2. Ensure you call the

endCall

tool explicitly in your hook (you already do). 3. Verify there are no other hooks or overrides (global assistantDefaults, assistantOverrides, or server-side fallbacks) that set an endCallMessage or trigger a cleanup after hooks run. If you want me to check the exact assistant payload: share the assistant creation / start payload (system prompt, voice, assistantOverrides including endCallMessage and hooks). You can DM that config or paste it here and I’ll review for the specific field to change.