Why your website form shouldn't send enquiries straight to n8n

If your website form is how new customers reach you, every enquiry matters. And if you use n8n, a tool that connects your apps and does routine tasks automatically, the form is a natural thing to connect to it. Someone fills it in, and n8n adds them to your CRM (the system that holds your customer list and sales pipeline) and sends the follow-up emails. The shortcut is to send the form straight to n8n, and it can be working within an afternoon. We understand why people do it. We also see what usually follows: spam in your CRM, an automation nobody dares to touch, and the odd enquiry that simply disappears.

This article explains what goes wrong, and the safer setup we recommend instead. The short version: let your own website receive the form first and check it. Only then should it pass the enquiry on to n8n.

What goes wrong when the form goes straight to n8n

• Anyone can find where your form sends its messages. That address is written into your web page, so anyone can send anything to it, as often as they like.
• Nothing is checked on the way in. Broken email addresses, huge messages and information you never asked for all go straight into your automation, and often into your CRM.
• Nothing stops a flood. A single program can send the form thousands of times, filling your CRM with junk and sending thousands of emails in your company's name.
• Lost enquiries go unnoticed. If n8n is restarting for an update when someone sends the form, they see an error and give up, and nobody knows a potential customer was lost.
• Your automation system is exposed. To receive the form directly, n8n has to accept messages from anyone on the internet.

The safer setup: your website first, then n8n

The form sends the enquiry to your own website, which is already there to show your pages. Only once your website has checked and accepted the enquiry does it pass it on to n8n, behind the scenes. Visitors never find out where n8n is. And the form can keep working even when someone's browser blocks scripts.

Before anything is passed on, your website should run a series of checks. The quick, simple ones come first, so obvious junk is turned away early:

1. Basic checks. Only a normal form submission is accepted: no file uploads, nothing in an unexpected format, and nothing over a set size, which is checked before the message is even read.
2. Where it came from. The message must come from a page on your own website. A program can fake this, so it is a first filter, not a lock.
3. How often. Each visitor gets a limited number of attempts, and only a smaller number of those can become enquiries, so a single program cannot flood you. To keep count, your website stores each visitor's internet address only in scrambled form, never as plain text.
4. A one-time code. When your website shows the form, it adds a hidden code that only your website could have issued. Each code works once, so a double click or a repeated submission reaches n8n only once, and a submission without a valid code goes nowhere.
5. Quiet checks for bots, the programs that fill in forms automatically. Simple signs that real people never trigger catch most of them, without making your visitors solve a puzzle.
6. Only the fields you asked for. The submission must match the fields your form actually has. Anything unexpected, even one extra field, means it is rejected, so nobody can slip extra information into your automation.
7. Checked, tidy answers. Every answer is checked for length and format, so an email address has to look like an email address. Invisible characters and untidy spacing are removed.

How n8n knows an enquiry is genuine

Once your website accepts an enquiry, it sends n8n a clean copy with only the expected information. Three labels travel with it: the time it was sent, a reference number and a digital signature. The signature is worked out from that time and the exact content of the message, using a secret that only your website and n8n know.

The first thing n8n does is check that signature, and it turns away anything older than a few minutes. A message that was changed, re-dated or sent by anyone without the secret goes no further. In plain terms, even someone who finds n8n cannot slip fake enquiries into your systems. For your developer: switch on the Webhook node's raw body option, so the check runs on the exact message that was signed. The check in n8n looks like this:

const crypto = require("crypto");

function isValidDelivery(rawBody, timestamp, signature, secret) {
  const age = Math.abs(Date.now() / 1000 - Number(timestamp));
  if (!Number.isFinite(age) || age > 300) return false; // 5-minute window

  const expected =
    "sha256=" +
    crypto.createHmac("sha256", secret).update(`${timestamp}.${rawBody}`).digest("hex");

  const a = Buffer.from(expected);
  const b = Buffer.from(signature ?? "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

The reference number matters too. If your website has to send an enquiry again, it uses the same number, so n8n can see it has already added that contact and does not create a duplicate.

What happens if n8n is offline

Automation systems restart for updates, and internet connections have bad moments. If your website cannot reach n8n, it should not show your visitor an error. Instead, it can keep the enquiry in a small, encrypted holding area on the server and tell the visitor their message was received, which is true. Your website then tries again on a schedule, with the same reference number. Enquiries that still cannot be delivered after a set time should be deleted and a person alerted, so personal details are not left waiting indefinitely.

Only if n8n and the holding area both fail should the visitor see an error, with an email address to write to instead. The one thing that must never happen is telling someone their message was sent when it wasn't.

What visitors see, and what is recorded

Keep what visitors see short and plain: whether it worked and, if something needs correcting, a note next to that field. Never show error details or anything about how your systems are set up. Behind the scenes, keep a record of what happened to each enquiry, with its reference number and as little personal information as possible: no names, no messages, no full email addresses.

Is this overkill for a contact form?

The extra part is small: a few hundred lines of well-tested code on your website, and it rarely changes. In return, your CRM only contains real enquiries, your automation system is not open to the whole internet, and no enquiries are lost during maintenance. If your form is how your business wins work, that is a good trade.

If your form already sends straight to n8n, switching over is usually straightforward. The checks are added to your website, n8n's address and secret move into your website's private settings, n8n is set to check the signature, and the form is pointed at your website. If you'd like a second opinion, we're happy to look at yours and tell you what the switch would involve.