I’m using n8n to handle a webhook that receives messages from the WhatsApp API. However, I’m facing an issue where the webhook is triggered not only for the initial message but also for 3 additional requests related to the message status updates. These status updates are unnecessary for my workflow, and their processing results in additional execution costs.
I’ve already implemented a function node to filter out status updates and only process the initial message, but this doesn’t prevent the webhook from triggering and starting the workflow. Is there any way to configure the webhook node or n8n in general so that these status updates don’t trigger the workflow at all? Or is there another strategy I could use to avoid these extra executions and minimize costs?
Any advice or suggestions would be greatly appreciated!
As far as I remember when you set up an app in the meta developer portal, you can select webhook scopes (or an app scopes, don’t remember exactly).
Even if you select just messages scope you will still get a ton of events on webhook, like message delivered, message read etc. I think the only way to work with it is by using switch/IF/filter node and process what you need.
If you want to reduce the number of execution history events, i can suggest making a subworkflow for message processing. This way you can get a history of only those events that you need.
I was thinking about this setup: the main workflow with the WA trigger is activated as usual with all unnecessary messages. then you have a Switch node (or IF node, Filter, etc) that identifies the events that you need. In the specific output you can attach an Execute workflow node.
Oh, just realized: if you are on n8n cloud and that’s why you want to reduce workflow activations, then my solution actually increases them (real messages will activate 2 workflows: the main one AND the sub-workflow).
The benefit of having a sub-workflow is that messages are clumped together, and the execution history is less spammy.
But if you want to optimize the number of executions, then I’m afraid this approach won’t help, because it doesn’t change the amount of events that WA sends on your trigger node.
@Jaylton_Alencar Have you managed to resolve this issue? I am following another post related to this issue and am waiting for some feedback as I have the same problem.
@Jaylton_Alencar I believe it might work if I were to use an external API, such as the Evolution API. But I haven’t tested it. I’m still waiting for the answer in another topic here in the community.
