Webflow contact forms without the submission cap (four-minute fix)

April 4, 2026 · 6 min read

Abstract network pattern — rerouting Webflow form submissions to a hosted endpoint

Webflow makes beautiful websites and extracts mild rent for the privilege. One of the places you notice it is forms. The Basic plan caps you at 500 form submissions per month per site, and the dashboard where you read those submissions has been "fine" for about seven years now.

If you're running a Webflow site that gets real traffic, you'll eventually want to reroute your forms somewhere else. The trick is that Webflow makes this easier than most people realize. You don't need to export the site, you don't need a custom code embed for every form, and you definitely don't need to upgrade your plan.

Here's how I do it.

The punchline

Webflow's form element has a "Form Settings" panel. Inside that panel is an "Action" field. Paste a URL there and submissions POST to that URL instead of Webflow's servers. That's the whole trick. The rest of this post is just the details.

Step 1 — Get an endpoint

Sign up for a hosted form backend and create a form. With FormTo you'll end up with a URL that looks like:

https://api.formto.dev/f/your-form-slug

Any hosted form tool will give you something similar. Copy it.

Step 2 — Select your form in the Webflow Designer

Click the form wrapper (not just the input fields — the whole form). In the right-hand panel, scroll to "Form Settings."

You'll see three fields that matter:

Field What to put there
Action Your endpoint URL from step 1
Method POST
Name Whatever you want to see in the dashboard

Paste. Save. Publish.

One gotcha: Webflow resets this field occasionally when you duplicate a page or clone a project. Every new environment, check the action URL. I have lost an afternoon to a staging site silently posting to the wrong endpoint.

Step 3 — Name your fields

This is the step everyone skips, and then regrets three months later when they're exporting submissions and every column is called field-2.

Click each input in the form. In the settings panel, set the name attribute to something readable: name, email, company, message. Those names become column headers in your backend dashboard, your CSV exports, and your webhook payloads. Future-you will send present-you a thank-you note.

Step 4 — Add the honeypot

In the Designer, drop one extra text input inside your form. Give it:

  • Name attribute: website
  • A class with display: none or positioned at left: -9999px
  • tabindex="-1" and autocomplete="off" (you can set these as custom attributes in Webflow's settings panel)

Real users will never see it. Bots will fill it. Your backend drops those submissions. Webflow doesn't give you this by default, which is the main reason its native forms are drowning in junk right now.

Step 5 — Decide what to do with the success state

By default, when a form submits to an external action URL, the browser navigates away. Webflow's built-in "Success message" won't show, because the page is no longer on the same domain.

You have two good options:

Option A — Redirect to a Webflow page. Add a hidden input to your form:

<input type="hidden" name="_redirect" value="https://yoursite.com/thanks" />

Make a /thanks page in Webflow. Customize it properly. Add a conversion event to Google Analytics or Plausible on that page. This is the path I prefer because the thank-you page is prime real estate for a next step — book a call, follow on LinkedIn, watch a demo.

Option B — Configure the redirect in your backend dashboard. Most hosted form tools let you set a post-submit redirect URL in the form settings. Same effect, but the config lives outside your Webflow project, which is either a feature or a bug depending on how your team works.

Either way, do not leave the default "page reload" behavior. Your visitors should know the message went through.

Why leave Webflow's native forms at all?

For some sites, you shouldn't. If you're on a plan that already includes generous form submissions, you use the built-in dashboard, and you're not integrating with anything fancy — keep it. Don't fix what's not broken.

The reasons to switch are specific:

  • Submission limits. 500 is tight for a site that runs ads.
  • Spam volume. Webflow's native filtering is weak, and adding reCAPTCHA to every form is a conversion tax.
  • Webhook needs. Retrying a failed webhook is not something Webflow does well.
  • Multiple forms, one dashboard. If you run a marketing site, a pricing page, and a gated PDF, you'll want them all in one inbox with search.
  • Client handoffs. Giving a client read-only access to their form submissions without giving them a Webflow login is surprisingly hard with the native setup.

If two or more of those apply to you, rerouting is worth the four minutes.

The thing nobody tells you about Webflow forms

Webflow's form element is really good at styling and very average at delivery. Those two things don't need to live in the same system. You can keep everything you like about designing forms in Webflow — the animations, the conditional visibility, the component library — and swap out the delivery layer without touching the visual side.

That's the mental shift. Webflow is the face. The backend is someone else's job.


Create a free form, paste the URL into your Webflow form's Action field, publish, and send a test from your phone. If it works, you just reclaimed your submission cap and your dashboard in one afternoon.

And if you're running multiple sites, the same endpoint pattern works on Framer, Astro, and Next.js — one vocabulary, one dashboard, everywhere.

← All posts