What is a form backend?
Short answer: A form backend is the server-side half of a form: it accepts the POST request, validates and stores the data, filters abuse, and delivers submissions somewhere you can read them. It replaces the custom endpoint you would otherwise write, deploy and maintain.
Every HTML form has two halves. The markup in the browser collects values; something on the server has to accept them. On a static site, a marketing page, or a prototype, that second half is usually the reason a form never ships.
What a form backend actually does
- Accepts the HTTP request the browser sends — form-encoded, multipart or JSON.
- Validates structure and size before anything is stored.
- Applies abuse controls: rate limits, spam filtering, origin checks.
- Stores the submission durably, scoped to the right owner.
- Delivers it: dashboard, email notification, webhook or export.
That list is short, but each line is a production concern. Validation that is too loose lets malformed data into your database; rate limiting is the difference between a contact form and a free spam relay; storage needs ownership rules so one client never sees another's leads.
What it is not
A form backend is not a form builder. It does not style your inputs, manage your layout, or replace your design system. You keep the form you already have and change one attribute, the action URL.
<form action="https://formivo.faizyab.me/api/f/YOUR_FORM_ID" method="POST">
<label for="email">Email</label>
<input id="email" type="email" name="email" required />
<button type="submit">Send</button>
</form>Why teams use one instead of writing an endpoint
- 1The endpoint has to exist everywhere: preview deployments, staging, production.
- 2Email delivery needs a domain, a provider and bounce handling.
- 3Spam arrives within days of going live, and filtering is an arms race.
- 4Someone has to own the data: retention, exports, deletion requests.
- 5Client-facing access is a separate feature most teams never get to.
A small Express handler is easy to write and hard to keep. The handler is ten lines; the operational surface around it is the project.
How Formivo implements it
Each form gets one public endpoint, identified by its form id. There is no API key to embed in HTML, because a key in client-side markup is not a secret anyway. Protection comes from the parts that can actually be enforced on the server: a 256 KB body cap, field and nesting limits, per-form and per-IP rate limits stored in the database, an optional browser-origin allow-list, honeypot fields, idempotency keys, and monthly quota checks that run in the same transaction as the insert.
Submissions are write-only from the public side. Reading them requires a signed-in workspace member, and the database enforces the same boundary with row-level security rather than trusting the application layer.
When you should build your own
- The submission must join data you already own inside your database.
- You need file processing, payments or multi-step state machines.
- Compliance requires the data to stay in your own infrastructure.
Otherwise a hosted backend removes a service from your on-call rotation. The rest of this blog covers the concrete integrations: HTML, React, Next.js, PHP and the security decisions around each.