Webflow guide

How to add a backend to a Webflow form backend

Use an embed or custom form action to send Webflow leads to Formserve.

No backend API route Honeypot spam trap Works with any host
FS Formserve Team Product guides
Webflow Stack
4 steps setup Walkthrough
Form <form action="…" method="POST"> in the browser
Formserve Validates & filters spam, then stores the submission
Deliver Notifications sent to email, Slack, Sheets, or webhooks
Why a backend at all

The browser can't handle the submission on its own.

An HTML form has to POST somewhere. Formserve is that destination — it receives the submission, screens it for spam, stores it, and sends the notifications. No server to run, no serverless function, no fragile scripts.

Use an embed or custom form action to send Webflow leads to Formserve.

§ 01 · Context Why it still needs a backend.

Webflow is often the fastest way to ship a marketing site, but the submission workflow usually needs more than a basic builder form. Formserve gives a Webflow project a portable backend with inbox storage, owner notifications, exports, and downstream integrations without forcing the workflow to live only inside the site builder.

The form POSTs to an endpoint URL, the submission is stored, and notifications are sent according to the endpoint settings. It's a safer, more maintainable replacement for fragile mailto: patterns or one-off scripts that break the first time your host changes.

§ 02 · Why More than just an email alert.

When the backend stores every submission first and notifies second, you get three things a raw SMTP relay can't give you:

Inbox plus notifications

Every submission stays searchable in the Formserve inbox — not just buried in one person's mailbox.

Spam stopped first

Allowed domains, honeypot fields, rate limits, and blocklists run before any notification is sent.

Route later if needed

Start email-only, then add Slack, webhooks, Sheets, or a CRM later without touching the form.

And because the submission is stored, delivery failures stay visible instead of disappearing into email logs. If a notification bounces, you can see it, retry it, and still have the lead.

§ 03 · Setup How to connect it.

None of these steps involve writing server code. First, make sure you have the essentials in place:

Published Webflow domain

Add the live Webflow domain to allowed domains before testing the production form.

Custom form action

Use an embed or editable form markup so the form can POST to the Formserve endpoint URL.

Named fields

Keep useful field names such as name, email, phone, service, and message.

Honeypot field

Include _honeypot to filter basic spam without showing a CAPTCHA to real visitors.

1
Create the endpoint first — Name the endpoint after the real workflow, such as Contact, Quote request, or Consultation booking.
2
Update the Webflow form markup — Set the action to the Formserve endpoint URL and keep method POST.
3
Add the hidden spam field — Put _honeypot in the embedded form and keep it visually hidden from users.
4
Publish and test from the final site — Submit from the real Webflow domain and verify the lead appears in the Formserve inbox.

§ 04 · Example Keep the form simple.

There's nothing special about the markup. The only required change is the action attribute. The hidden _honeypot input is the one spam-prevention field worth adding by hand:

webflow.html — minimal
<form action="https://formserve.io/f/YOUR_ENDPOINT_KEY" method="POST">
  <input type="text" name="_honeypot" tabindex="-1" autocomplete="off" style="position:absolute;left:-9999px" />
  <input type="text" name="name" required />
  <input type="email" name="email" required />
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>
No fetch required for the basic case.

A plain action + method="POST" works with zero JavaScript. Reach for fetch only when you want to stay on the page and show a custom success state.

Before you launch

  • Publish the Webflow site before final testing.
  • Add the production domain to allowed domains.
  • Confirm the submission appears in the inbox and notifications.
  • Add integrations only after the base form flow works.

Common mistakes

  • ! Testing only from the Webflow preview instead of the published domain.
  • ! Leaving the form on builder-default handling instead of POSTing to Formserve.
  • ! Forgetting the hidden _honeypot field.
  • ! Not keeping field names stable after Webflow edits.

Get a working endpoint in under a minute.

Paste the URL into your form's action and send a test. Free up to 100 submissions / month — no credit card.

Try without signup

§ 05 · FAQ Common questions.

Do I need to build a backend for a Webflow form backend?
No. Formserve is the backend. You point the form at a Formserve endpoint URL and it stores submissions, filters spam, and sends notifications, so you never build or host a server yourself.
Does this work with Webflow?
Yes. A Webflow form submits standard named fields, and Formserve accepts them the same way any HTML form posts data — no SDK or plugin required.
Will connecting Formserve change my form design?
No. You keep your existing markup and styling. Only the submission behaviour changes so the form posts to your endpoint instead of a server you maintain.
How do I stop spam without a CAPTCHA?
Add the hidden _honeypot field shown in the code sample and set a spam protection level on the endpoint. Formserve blocks bots invisibly instead of showing a CAPTCHA.
FS
Formserve Team
We build the form backend behind thousands of HTML forms — from one-page contact forms to high-traffic launch pages.
Webflow Guide No-code