Webhook response is firing repeatedly during a single inbound call (Vapi → Make → Monday) — looking for best practice to ensure it fires only once

Questions
,
1

:bullseye: What is your goal?

I’m running an inbound Vapi assistant that calls a Make.com webhook to pull applicant data from monday.com at call start.

The data now pulls correctly, but during a single call the webhook fires multiple times instead of once. This appears tied to Vapi server messages / tool calls rather than Make retries.

Has anyone handled a similar setup (voice/AI platform → Make → CRM) and found a reliable way to:

ensure the webhook logic executes only once per call, or

gate / dedupe repeated executions cleanly on the Make side?

Looking for architectural or Make-native patterns (filters, data stores, flags, etc.), not workarounds.

:thinking: What is the problem & what have you tried?

I have an inbound voice AI (Vapi) calling a Make Custom Webhook, which then pulls data from monday.com.

The data now pulls correctly, but during a single phone call the same webhook fires multiple times, even though I expect it to run once per call.

This does not appear to be Make retries — it looks tied to repeated inbound webhook requests from Vapi during the call (likely multiple server/tool messages).

I’m trying to understand the correct Make-native pattern to ensure the logic executes only once per call (e.g. filtering, locking, data store flags, execution gating), without relying on hacks or time delays.

:clipboard: Error messages or input/output bundles

there are no errors, its just consistenly running without stopping

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

Screenshot 2026-01-23 at 11.16.59 AM.png
Screenshot 2026-01-23 at 11.16.59 AM.png1920×1080 327 KB

4

Hey

It’s not on Make’s side as you pointed out already.
You’ll have to find out what’s triggering the webhook several times on Vapi’s side.

5

Hi,

Indeed, it is much better to configure then VAPI assistant or the overall VAPI configuration that calls the webhook (which is most probably configured in VAPI as a tool/function) to call it only when needed (e.g. when the assistant receives an inbound call).

I suspect the webhook URL is also added as a server URL setting in VAPI - either on assistant-level and/or on VAPI org level hence the multiple calls to the webhook.

On Make’s side you can control the webhook’s run by applying a filter based on the webhook’s received payload. Typically a payload from VAPI sent to the webhook will look like:

{

“message”: {

        "timestamp": 1751161132530,

        "type": "type-of-event-name",

//…

}

And you can apply a filter after the webhook is called to filter by the message.type before the Phone Number module.

The latter approach, however, is just for debugging purposes — you better look and adjust the VAPI’s assistant/organization settings pertaining to the webhook as a more robust solution. First check the type of events received by the webhook in the scenario’s history in Make and they will give you insights when and why the webhook is called.

I hope this helps:)