What a form backend is, and how to choose one

A form backend is a hosted endpoint that receives submissions from your HTML form, validates them, filters spam, and delivers them where you want. You point your form’s action at a URL, and you stop maintaining a server for it.

You need one because a static site cannot process a POST. Astro, Next.js on static export, Hugo, Jekyll and GitHub Pages all ship files. There is nothing running to read the request body. The form backend is the piece that can.

What a form backend does

Four jobs, in order, on every submission:

Job	What it means
Receive	Accept a POST from a browser on any domain, without CORS setup on your side
Validate	Enforce field rules on the server, not just in the browser
Filter	Drop bots and junk before anything is stored or forwarded
Deliver	Send the clean submission to email, Slack, a spreadsheet, a CRM, or a webhook

Anything that only does the first and the last is a relay, not a backend. The value is concentrated in the two steps in the middle, because those are the ones you would otherwise write and maintain yourself.

How an HTML form works without a backend

A plain HTML form already knows how to send data. Set action and method and the browser does the rest:

<form action="https://api.formroute.dev/f/site_xyz" method="POST">
  <input name="email" type="email" required />
  <textarea name="message"></textarea>
  <button>Send</button>
</form>

No JavaScript, no build step, no fetch call. The browser serialises the fields and posts them to the endpoint. This is the whole reason the pattern works on a static host: the form action endpoint lives somewhere else, and your site stays a folder of files.

The tradeoff is that a native form POST navigates away from the page. If you want the visitor to stay, you intercept the submit and send the request yourself: that version, in about twenty-five lines. Same endpoint, same fields. You are choosing who performs the request, not changing the backend.

Setup for your stack

The endpoint is the same everywhere. What changes is where the markup lives and what your framework does on submit:

• Astro contact form, with no client JavaScript at all
• Next.js contact form, with and without a Server Action
• React contact form, on React 18 and on React 19
• Vue contact form, using the submit modifier and reactive validation
• Svelte contact form, including the three things Svelte 5 changed
• Vanilla JavaScript contact form, with no build step
• Hugo contact form, as a partial plus a shortcode
• Jekyll contact form, as an include with Liquid parameters
• GitHub Pages contact form, on a host that runs nothing

What a form submission API adds

Once the endpoint is a real API, a few things become possible that a mailto link never allowed.

You get a response you can act on. A submission API returns a status, so your page can show a success state, a validation error on a specific field, or a retry. You can also read submissions back programmatically instead of digging through an inbox, which matters the moment a form feeds something other than a human.

You also get server-side validation, and this is the part people underestimate. Browser validation is a convenience for honest users. It is required and type="email" and it disappears the moment someone posts to your endpoint with curl. A contact form API worth using lets you declare the rules once and enforces them on every request, whatever the client did:

email    required|email
name     required|min:2

Server-side rules are also the only place to validate formats the browser has never heard of, like a Brazilian CPF or a national ID number.

Sending form data to email

Email is still where most submissions need to land, and “form to email” is the job people search for first. A hosted endpoint handles the part nobody wants to own: sending mail that arrives.

Three things to check before you trust one:

• Reply-to handling. The notification is sent by the service, from the service’s domain. If it does not set the visitor’s address as the reply-to, hitting reply mails the vendor instead of your lead.
• Autoresponder. Sending a confirmation back to whoever filled the form is a separate feature from notifying you. Not every plan includes it.
• Custom SMTP. If the mail has to come from your own domain, you need to bring your own sender. This is usually a paid tier.

Email is also the weakest single point of a form pipeline. Inboxes filter, addresses change, and a message that lands in spam is indistinguishable from a submission that never happened. Which is the argument for not making email the only destination.

Stopping spam before it reaches you

Every public endpoint gets found. The question is what runs before the submission reaches you.

There are three layers, and they catch different things:

1. A honeypot field. Hidden input that a human never fills and a naive bot always does. Free, invisible, and defeats a surprising amount of traffic.
2. Bot detection. Cloudflare Turnstile and similar run invisibly and block automated clients without making real users identify traffic lights. This is where reCAPTCHA’s friction stops being necessary.
3. A content classifier. The layer that catches what passes bot detection: real humans, or good bots, sending junk that is grammatically fine and commercially useless.

FormRoute runs Turnstile and an AI classifier on the edge, before anything is stored or forwarded, and configures Turnstile for you: your form gains two lines and you never touch a Cloudflare account. Blocked spam does not count against your monthly submission limit, which is worth checking wherever you land, because a service that bills you for the spam it filtered has an awkward incentive.

Routing one submission to several destinations

One form, one inbox is the case every service handles. The real shape of the problem is different: a quote request should reach sales, a support message should reach a different queue, and an ad campaign lead should reach your mailing list and skip storage entirely.

The usual answer is to bolt Zapier or Make onto a webhook, which means another subscription, another point of failure, and a delay between submission and delivery.

The better answer is rules that live with the form:

WHEN form is "quote"    → sales inbox, HubSpot, #sales
WHEN source is "ads"    → Mailchimp, skip storage

FormRoute evaluates these rules on every submission and fans it out to every matching destination at once. No automation tool in the middle, no glue code, no delay while a third party polls a webhook. Routing rules are on Indie and above, and Pro lifts the cap on how many you can define.

Connecting Slack, Sheets and your CRM

Destinations beyond email fall into three groups, and they are worth separating because they fail differently.

Chat, meaning Slack or similar, is for things a human should see within the minute. It suits a low-volume, high-value form, and nothing that fires fifty times a day.

Spreadsheets, meaning Google Sheets or Notion, are for things you will look at in aggregate. They are also the cheapest possible database for a form nobody has decided the shape of yet.

A CRM, meaning HubSpot, Pipedrive or Mailchimp, is for anything that has to become a contact record. This is where field mapping starts to matter, because the CRM has its own required fields and your form probably does not fill them.

On FormRoute, Sheets, Slack and Notion are on Indie at $14/mo, and HubSpot, Mailchimp and Pipedrive are on Pro at $24/mo. Full breakdown on the pricing section.

What a form backend service costs

Free tiers are where these services differ most, and where the comparison is hardest to read, because the headline number is rarely the constraint that bites.

Check four things, in this order:

1. Submissions per month, which is the number everyone advertises.
2. Number of forms, which is the one that catches freelancers and agencies. A generous submission limit with a two-form cap is useless across ten client sites.
3. Storage and history. Some services are email-only and keep nothing. If the notification is lost, the submission is gone.
4. What is gated. Webhooks, server-side validation and file uploads are on the free tier of some services and the paid tier of others.

FormRoute’s free tier is 1,000 submissions a month, unlimited forms, unlimited domains, a dashboard, one webhook, spam protection, and 7 days of storage. Retention is yours to set anywhere from 0 to 30 days, or off entirely.

For how that lines up against specific services, the comparisons are written out per competitor: Basin, Formspree and Web3Forms, with the full list on the alternatives page.

How to choose one

Work backwards from the destination, not from the pricing table. Decide where submissions actually have to arrive, then check which services reach all of those places without a paid automation tool in the middle. That single question eliminates most of the field faster than comparing submission counts.

Then check the one thing nothing above covers: how you get the data out. Export is the feature nobody evaluates until they are leaving, and it is the difference between switching services in an afternoon and losing a year of submissions.

FormRoute was built around the routing half of that list, which is the half most services leave to an automation tool. It is in private access. Request an invite.