I just finished making a site, it has multiple ways emails are stored, I made a n8n workflow that gets the stored emails, checks if it has not been added onto a spreadsheet before, deduplicates it, then adds it to a spreadsheet. This workflow runs anytime a new email is submitted. This is my first time using n8n, is this dangerous? in the sense that having a n8n workflow that can be triggered directly by users, can it cause massive usage spikes in memory, etc very easily when its dependent on what a user can do? even if i ratelimit it, because I dont know the overhead n8n has, it takes a minute for the workload to finish also.
Yes, user-triggered workflows need protection. Main risks: duplicate submissions (users refresh/retry), resource spikes (malicious or accidental floods), and runaway costs.For protection, add rate limiting before processing (“max X submissions per user per hour”) and execution locks for deduplication (“if already processing this email, skip”). Ainoflow Guard + Shield handle both - Guard rate-limits requests, Shield prevents duplicate executions with one HTTP check each, sub-millisecond overhead.
Hi @SpiderUnderUrBed Welcome!
Yes this is dangerous, as if i can do a lot bad with that, like extracting your webhook and then sending huge number of requests, for that kind of thing i would say you should consider the approach of SESSION and also what i have done personally is that if someone submits an email, first they will get an confirmation on their mail and then only that mail would be sent to the database for further check, and that would really help you and it is quite easier to implement.
Hi, @SpiderUnderUrBed
Yes it is:
- Optimize the Spreadsheet Lookup; Instead of pulling all the data into n8n to check for duplicates make the Spreadsheet provider do the heavy lifting.
-
Use the a relevant spreadsheet node and set the operation to Lookup or use a query parameter.
-
Search only for the specific email address that was just submitted.
-
If the node returns empty, use an If node to route to the “Append Row” action.
-
Result*:* Your execution time should drop from 60 seconds to about 2 seconds, drastically reducing memory overhead.
- Turn Off Execution Saving By default, n8n saves the data from every single successful execution into its database. for a high-volume webhook, this will rapidly bloat your database and slow down the entire system.
-
Go to your workflow settings and set Save Data on Success to “Do Not Save”
-
Only save data on errors so you can debug failed submissions.
There are other solutions,
Great points from everyone above. One thing I want to add from experience building a FB Messenger chatbot that handles user-triggered workflows:
For the deduplication concern specifically, if you’re using Google Sheets, the bottleneck is usually the lookup speed, not n8n itself. Haian’s advice on using Lookup instead of pulling all rows is spot on.
Another pattern I use for high-volume webhooks: put a Redis (or even an in-memory store via n8n’s built-in static data) between the webhook trigger and the actual processing. The webhook just logs to queue, and a separate scheduled workflow processes the queue every 30 seconds. This decouples the user-facing response time from the actual processing time, and naturally prevents spikes from overwhelming your workflow.
For a simple email dedup case like yours, the confirmation email approach Anshul mentioned is probably the most practical without added complexity. But keep the architecture in mind for when you scale.
Your workflow is lightweight so n8n can handle it fine.
One thing to watch out for: if two emails get submitted at the exact same time, both might slip past your duplicate check and both get added. Easy fix is to add a Remove Duplicates node at the end of your workflow as a second safety net.
For rate limiting, just use Cloudflare’s free plan in front of your webhook URL. Takes 10 minutes to set up and handles it automatically.