Digitalwert Contact Form (2025)

What the pipeline does

The workflow receives contact enquiries from digitalwert.de and filters out spam in several deterministic stages before a genuine enquiry is delivered to the mailbox and the Slack channel. It replaces a classic form microservice without putting a language model in front of it.

Why this solution

The contact form was under constant spam pressure. A single honeypot field is no longer enough, and LLM-based classification would create running costs, additional latency and unnecessary energy consumption. Instead, the pipeline combines several hard rules that are fast, traceable and GDPR-compliant.

Trigger

The form is embedded in Framer. On the form=submit event, Framer calls a webhook on the N8N instance and passes the structured form data.

Processing steps

1. Webhook receives the request.
2. Honeypot: a hidden field that only bots fill in. On a hit, the run ends with HTTP 400.
3. Origin check: does the request really come from digitalwert.de? If the origin is missing or does not match, it is rejected.
4. Rate limit: if a request was already submitted within the same minute, that counts as flooding.
5. XSS/SQL scan: the message is checked against a curated catalogue of dangerous patterns, among them control characters, injection snippets and script fragments. A hit aborts the run immediately.
6. Spam patterns: a dedicated code node detects typical bot signatures: frequently alternating upper and lower case within single words in the name field, and e-mail addresses whose local part contains more than three dots.
7. Timestamp is generated and passed on to the following steps.
8. Confirmation e-mail to the sender via Brevo (formerly SendinBlue).
9. Internal e-mail to Digitalwert with the full content of the enquiry.
10. Slack message to the internal channel in charge, including the message, metadata and timestamp.
11. HTTP 200 as the webhook response to Framer.

Responses to the frontend

The webhook responds with 200 for successfully processed enquiries and with 400 as soon as one of the security stages triggers. Framer uses the status to decide which feedback the user sees in the form.

What carries the solution

The filtering is entirely deterministic. No language model, no external classification API, no personal data ending up somewhere for training purposes. That keeps the solution cheap, energy-efficient and GDPR-compliant, and makes every decision traceable in the N8N log.

Edge cases

Brevo, Slack or the N8N instance itself can fail. Every delivery step stays individually observable and traceable. If bots get smarter and slip past the heuristic checks, the rule sets can be tightened in one place without touching the frontend.