Twilio WhatsApp Webhook Triggering Scenario Multiple Times — Duplicate Messages Being Sent to End Users

Questions
, , , , ,
1

:bullseye: What is your goal?

I am building a WhatsApp lead qualification bot for estate agents called Konzi. When a lead sends a WhatsApp reply to the Twilio sandbox number, my Make Scenario 2 (Conversation Handler) should run once, read the lead’s reply, generate a response via Claude AI, and send one message back to the lead. Instead it is running multiple times (between 2 and 10 times) and sending duplicate messages to the end user — which is completely unacceptable for a client-facing product.

What is the correct way to ensure a Make scenario triggered by a Twilio WhatsApp webhook only runs once per inbound message — ignoring status callbacks and duplicate webhook fires? Is there a native Make solution, or does this require middleware?

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

Setup

  • Twilio WhatsApp Sandbox → Webhook → Make Scenario 2
  • Scenario 2 receives the reply, queries Google Sheets for conversation stage, sends to Claude AI via HTTP module, parses the JSON response, and sends the reply via a direct Twilio API HTTP call
  • I have tried routing through a Google Apps Script middleware to deduplicate by MessageSid using PropertiesService — but the Apps Script execution log shows no entries, suggesting Twilio is not reaching it despite the correct URL being in Twilio sandbox settings
  • Scenario 2 is set to run Immediately and is toggled ON

What I Have Tried

  • Google Sheets deduplication using MessageSid (race condition — all webhooks arrive before any can save)
  • Make Data Store deduplication (same race condition)
  • Google Apps Script middleware with PropertiesService to catch duplicates before forwarding to Make (Apps Script does not appear to be receiving Twilio’s requests)
  • Setting Sort Order to Descending and Limit to 1 on the Google Sheets Search module
  • Scheduling the scenario every 1 minute instead of immediately

:clipboard: Error messages or input/output bundles

Key Observation
Duplicates only started when I introduced a Google Sheets row that gets created by Scenario 1 at the start of each conversation. Before that row existed, Module 2 (Search Conversations sheet) returned 0 bundles and the scenario ran once. Now it returns 1 bundle and runs multiple times. This suggests the issue may be Twilio sending status callback webhooks (Accepted, Delivered) in addition to the inbound message webhook — and all of them are triggering the scenario.

:link: Create public scenario page

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

Screenshot 2026-06-19 at 10.08.12.png
Screenshot 2026-06-19 at 10.08.12.png1792×223 36.2 KB

3

Hi @Mpodumo_Doubada

You have clearly identified the problem; Twilio mostly requires an immediate HTTP 200 OK response before 5 seconds, but I can see your Make scenario queries Google Sheets, sends payloads to Claude AI, and parses JSON before ending the execution, the connection kinda times out from Twilio’s perspective.

You can try to use a separate inbound vs status webhooks in Twillo. Check if Twillo still allows different URLs for inbound messages and status callbacks.

In your Twillo sandbox settings when a message comes in point only to your scenario 2 webhook url. That’s the inbound handler. Then set thr status callback url to a different url which can be a basic scenario that only logs without processing anything.
I think this can prevent the status updates from triggering your conversation handler.

Another hack that could work is to use an early filter on the payload. Like immediately after the webhook trigger a router + filter that only let’s processing continue if “body” is present. Check to verify that status callbacks from twillo lack bodies or have message status instead of inbound fields. Or you can filter it on message status.
Infact if you can identify any difference between your normal payloads and status callbacks you can use a reliable difference and set up a reliable filter that will stop most or all callbacks from processing.

Regards.

4

Hello,
Welcome to the Community!

Refer to Twilio documentation.

For messages webhooks Twilio expects response to be sent to webhook.

To validate what exactly Twilio is sending please visit your Webhooks tab (left side menu bar)
Zrzut ekranu 2026-06-20 o 06.25.58
and compare requests between calls. It will give you clear information what data was sent to your workflow.