Webflow Form Backend: What the Custom Action Setting Actually Changes

A Webflow Form block isn't a blank slate the way a plain HTML <form> is — it already submits somewhere by default: Webflow's own backend, which stores it and can email a notification. Pointing it elsewhere isn't a matter of adding capability that doesn't exist; it's a matter of finding the one setting that redirects capability that's already there, and knowing the two or three places that setting alone doesn't reach.

Photo by Joshua Reddekopp on Unsplash

The Custom Action setting, exactly

Select the Form block on the canvas or in the Navigator, open the Settings panel, and look under Send to. The default is Webflow's own backend; choosing Custom Action reveals an Action field (the URL — https://api.nbforms.com) and a Method dropdown (GET or POST — POST is the one to pick). No embed, no exported HTML, no code panel — this is a setting on the same block that was already there, available on any hosted Webflow plan rather than something gated behind a higher tier.

What turning it on actually changes

Webflow is direct about the tradeoff, and it's worth taking at face value: with a custom action set, submissions stop being stored in Webflow's own Forms panel, and Webflow's own email notification for that form stops firing. The Settings panel actually requires removing the Webflow and Email notification options before Custom Action can be selected — the two send-to methods aren't meant to run side by side. That's not a loss so much as a straight swap: NBForms' own dashboard and email alert pick up exactly what Webflow's own versions were doing, for this one form.

The hidden field Webflow's own picker can't add

Here's the part that isn't obvious from the Settings panel alone: NBForms identifies which form a submission belongs to with a hidden _token field, and Webflow's native Form block field picker has no hidden-input option — only text, email, phone, and a handful of other visible types. The fix is an Embed element, dropped inside the Form block above the submit button, containing one line of raw HTML:

<input type="hidden" name="_token" value="YOUR_TOKEN" />

This works because a Webflow Form block is still a real <form> element under everything the Designer adds on top — an Embed's raw HTML becomes real DOM inside that same form, submitted exactly like any field Webflow's own picker would have added. Nothing about the custom action setting cares whether a given input came from the visual field list or a line of embedded HTML; the browser submits whatever's actually inside the <form> tag.

File uploads need the same treatment as the hidden field

Webflow's native File Upload field type is built around Webflow's own backend and storage — it isn't the reliable choice once a form is pointed at a custom action, and on some plans it isn't available at all outside Webflow's own handling. The fix follows the same pattern as the hidden token: an Embed element with a plain input,

<input type="file" name="attachment" multiple />

submits exactly like any other file input inside a real <form>, and NBForms accepts it the same way it accepts one from a hand-written HTML form — no Webflow-specific configuration on the receiving end, and no separate upload service or signed URL to wire up first. The pattern across both fixes is the same: Webflow's own visual field picker is built assuming Webflow's own backend is on the other end, and a plain Embed is how to add whatever that assumption leaves out once it isn't.

One form, reused as a Component

A Form block set up this way — custom action, hidden token, whatever fields it needs — turns into a Webflow Component the same way any other element does: right-click, save as a Component, and drop the same instance onto other pages. Every instance shares the same settings, including the custom action and the hidden field inside its Embed, so a contact form used identically on a pricing page, a footer, and a dedicated contact page stays one thing to update rather than three copies to keep in sync by hand. Overriding visible text per instance (a different heading above the form, say) still works through Webflow's normal Component override system without touching the settings that make the submission actually work.

Redirect only works one way, not the other

Webflow's own Redirect URL field looks like it should apply here too, and it doesn't — it only takes effect when Action is left on Webflow's default. Switch to a custom action and a real POST fires to that URL, with the browser doing a genuine navigation to wherever the request actually resolves — Webflow's Redirect field has nothing left to do at that point. The setting that matters now is the destination's own: NBForms' redirect URL, configured in the form's own settings, sends the visitor to a real thank-you page after a successful submission the same way it would for a plain HTML form anywhere else.

Staying on the page instead

A full navigation away from the Webflow page is a fine default, and also avoidable for anyone who wants the visitor to stay put and see Webflow's own Success/Fail state blocks (the ones built into every Form block, styled in the Designer, shown and hidden automatically on a native submission). A small script in an Embed element gets that back:

<script>
document.querySelector('form').addEventListener('submit', async function (e) {
  e.preventDefault()
  const form = e.target
  const res = await fetch('https://api.nbforms.com', { method: 'POST', body: new FormData(form) })
  const wrapper = form.closest('.w-form')
  form.style.display = 'none'
  wrapper.querySelector(res.ok ? '.w-form-done' : '.w-form-fail').style.display = 'block'
})
</script>

.w-form, .w-form-done, and .w-form-fail are the same classes Webflow's own Form block already generates — this script doesn't build a new success state, it just triggers the one that's already sitting on the page, styled however it was designed in the Designer, instead of letting the browser navigate away to trigger it.

What it doesn't do

Same scope as any lightweight form backend, worth stating without embellishment: this receives a submission, filters it for spam automatically, stores it, and emails an alert. No payment processing, no multi-step logic branching on an earlier answer, no CRM sync, and no automatic reply sent back to whoever filled it in beyond the alert and whatever success state the page shows. A Webflow site selling something through a separate checkout still needs that checkout; a Webflow site collecting inquiries or leads is exactly what this setting is for.

For a no-code contact form on a page that has no site around it at all, see hosted form pages with no website — the same subdomain approach works whether or not Webflow is part of the picture. And for spam filtering specifically: it runs automatically on every submission regardless of which path above sent it, native Custom Action or the AJAX version — nothing about either changes what happens once a submission reaches NBForms, only how it gets there and what the visitor sees while it does.