I was wondering whether it was possible to wait for let’s say 1 minute, if the same webhook is triggered more than once, and only then trigger a workflow.
I had the issue this morning that a webhook was fired four times (it should’ve only triggered once), and then based on this executed a workflow four times instead of just once. This way I could filter out and account for a malfunctioning of this webhook in the future (it is not intended to fire more than once per day.
Thanks!
Hey @somesimon, this is rather tricky in n8n. When using the webhook node each received webhook will trigger a new workflow execution that has no knowledge of other executions.
Do your webhooks have a unique value allowing for deduplication? If so, you could consider using a data store for this purpose. For each webhook check if the ID is already present in your data store, and only if it’s a new ID, store said ID and continue with your workflow.
Alternatively, you could check if your workflow is already running if your goal is to simply make sure it never runs more than once at a given time. This would require using the undocumented and unsupported REST API used by the UI to display currently running workflows though.
Ah cool, thanks a lot that sounds like it could work.
Looking for a datastore node it looks like that’s custom work, where do I find more info about it? The search node just reveals a Customer Datastore dummynode, not sure where to take it from there.
It’s enough if that store persists for a minute, but I’m guessing that your solution would mean that it adds all the ids that were already run and then only in the case it’s not been saved, it continues.
Ah, sorry for the misunderstanding, I didn’t want to mention a specific node for the job, because pretty much all nodes that can store (and read) data should do the job.
For example, every database should do the job (unless you process a very high volume of webhooks). If your volume is rather low and it doesn’t matter if your workflow takes a little bit longer you could also use Google Sheets. I think even a file written to your hard drive could do the job in that case.
You could also consider using static workflow data (described here), but this won’t work when manually executing/testing your workflow.
Let me know if you need an example and I’ll put something together when I have some time 
Oh I see, hm I think I could even do with a Google Sheets solution tbh, this webhook is expected to run 1-2/day, it’s just about making sure it doesn’t start a chain reaction with 4 of the same actions (with email going out etc.).
By now I also know what happened, Ghost couldn’t reach n8n within two seconds and resent the webhook 4 times till it reached it and got a result. By then, of course, it was all too late and the damage was done.
Would love to see how you’d solve it, I have a general idea, but would help a ton. <3
Okay, here we go. Assuming your webhook is a POST request with a JSON body like this:
{
"id": "foo"
}
And you have a spreadsheet like this:
You could use a workflow like so:
The part right of the Merge node would only run once for each id received in a webhook. This value is then stored in the sheet and subsequent webhooks will not make it beyond the Merge node running in “Remove Key Matches” mode:
With all that said, if the root problem here is the webhook not getting a response within 2 seconds, you could try setting your webhook to respond immediately:
And also switch n8n to main mode as described here. This will greatly reduce the latency.
Wonderful. I’ve learned 3 things here.
Thanks, this gave me some ideas to work on.
Yes, that’d be in the webhook node. Sorry, I should have used a larger screenshot:
ok so with a Merge node, I see. In terms of latency would it not be still an issue if all 5 webhook signals arrive at the same time?
5 webhooks shouldn’t be a problem normally unless your main thread is blocked for whatever reason. Jan explained this in a bit more detail over here yesterday.
Thank you,
Looks like I’m on a slightly older version of n8n then, need to upgrade.
I’m more concerned about 5 webhooks hitting immediately, while the first is in the flow to write to sheets, the others are already past that stage because it didn’t write to the spreadsheet fast enough. Make sense?
In any case, I have some work to do. Thanks
Is there an issue with replacing the dot-notation with a node centered path? eg. {{ $item("0").$node["Webhook"].json["body"]["post"]["current"]["id"] }} - I can’t get the dot-notation to do anything, with a direct path I get the right id.
Given that Google Sheets is one of the nodes that outputs only one result, wouldn’t I need to add a loop to where you indicated the ID?
Thanks
Edit: in all actuality I don’t even need the loop, because it’s good enough for me to check the id in the last element of the column of the sheet against the one coming from the webhook now. But even then, I’m confused, it does not seem to work as it continues even though the two elements match exactly:
FTR, updated to n8n v 0.176.0 but it keeps running despite two identical ids. Not sure where I’m messing up.
Hi @somesimon
You put in the Id field as an expression I see?
You will need to put in the name of the field.
So for this example I think It is body.post.current.id
Not sure if you can use Dot notation here.
Hope this helps, please correct me if I misunderstood the issue.
@BramKn thanks for picking it up, I was losing my mind. Rebuilt (the exact same flow) from scratch and now it works (with the dot-notation), possible that there was some bug from the old n8n version I was using, no idea.
Thank you!
So, unfortunately the problem still persists for me. Even though I have successfully set the deduplication flow, they still go through. They all hit at the same time and only when one hits a little later it successfully stops the flow. What can I do, any ideas @MutedJam ?
To illustrate. Only the 4th, slightly later arriving webhook gets stopped.
Thanks
Hey @somesimon, seeing all your webhooks arrive at the same time this might be a problem with Google Sheets not processing your data fast enough. This could in theory also happen with other databases but is less likely. So in a first step you could try using another database.
If this isn’t successful, you could split your single workflow in two separate workflows, essentially building a queue for your specific case. On first thought, it could look something like this:
