Jul 1, 2026·7 min read

Serverless Form Handling: One POST Endpoint, No Backend

Serverless form handling means your form POSTs to a hosted endpoint instead of a backend you build and run. If you ship a landing page, a waitlist, a React or Vue app, or any static site with a contact form, this article is for you. You'll learn what a serverless form handler is, how one POST endpoint replaces a database and a mailer, and the exact moment you should keep building your own. The short version: for most projects, the fastest form backend is the one you don't write.

TL;DR — the 30-second summary

A serverless form handler is a hosted POST endpoint for your HTML form. You keep your markup, change the form's action URL, and the service stores the submission, emails you, and can forward a webhook. Setup takes about 30 seconds, there is no SDK and no field builder, and you can swap providers later without touching a single <input>. It is the wrong tool only when you need to query the data or build a product around it.

What is serverless form handling?

Serverless form handling is a service that receives your form's HTTP POST request, stores the payload, and notifies you by email or webhook — with no server, database, or mail setup on your side.

The term comes from the same wave as "serverless functions": you outsource the infrastructure so the code you run stays minimal. In this case you run zero code. The service owns a form submission API — the endpoint, the storage, and the notification plumbing — exposing one URL per form. Your only job is pointing the form at that URL — the same way an HTML form's action attribute has always worked, just with a remote target instead of a page on your own server.

Why forms shouldn't require infrastructure

A contact form is a pipe, not an application. Someone sends a few kilobytes of data, you want to read it later, and you want to know the moment it arrives. Everything beyond that — schema design, migrations, a hosted Postgres instance, a mail server, rate limiting, a dashboard — is friction standing between you and the signal.

The conventional approach front-loads all of that friction before you have a single user:

A database with a table for submissions
An API route that inserts the row
An email service and the credentials to use it
Somewhere to deploy and keep it running
A way to view and export the rows

For a feature that ships on every project you'll ever build, that is a lot of machinery. The serverless form handler collapses all five items into one URL.

How it works: one POST endpoint

A form backend as a service gives you one endpoint per form. You create a form, you get a slug, and you send data to it. The same endpoint accepts JSON via fetch or a plain HTML form POST:

const response = await fetch("https://formy.io/api/submit/waitlist", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: "ada@example.com", source: "twitter" }),
});
// 201 -> { success: true, emailSent: true }

A native HTML form needs no JavaScript at all:

<form action="https://formy.io/api/submit/waitlist" method="POST">
  <input type="hidden" name="slug" value="waitlist" />
  <input type="email" name="email" required />
  <button type="submit">Join the waitlist</button>
</form>

That's the whole integration. The service stores the submission, emails you, and fires your webhook if you configured one. A JSON request gets a 201 response; an HTML form POST gets a 303 redirect to a success page. Missing a slug returns 400, and an unknown slug returns 404 — the same small contract on every form.

What you get: email and webhooks

Every form service can email you; that is table stakes. Webhooks are what turn a submission into an event in your own pipeline. Instead of the response disappearing into a dashboard you have to remember to check, it lands in a queue, a CRM, a Slack channel, or any system you already run:

{
  "event": "submission.created",
  "formId": "ckx0p9q4r2",
  "formTitle": "Contact form",
  "submissionId": "sub_01h2x8",
  "data": { "email": "kim@example.com", "message": "..." },
  "submittedAt": "2026-07-01T14:30:00.000Z"
}

So you get two notification channels in one: email for quiet periods, and a webhook when you want the data in your own systems in real time. Both fire from the same endpoint, and neither requires you to run a server to receive them.

When a form endpoint is the wrong call

Be honest about the boundaries before you choose a form handler:

You need search, analytics, or complex queries over the submissions → a real database is the right tool.
You're building a product around the data itself → you should own the storage layer.
You need a visual field builder → that's a different product; most form backends deliberately don't ship one.

If you just need to collect responses and read them later, a form endpoint service is the smallest solution that works. If you need to ask questions of the data, build your own storage.

A checklist for choosing a form backend

When you compare options, run this checklist rather than reading marketing pages:

Plain POST endpoint, no SDK required for the basic flow
Accepts JSON and standard HTML form encoding
Email notification on every submission
Webhook support with a structured payload
A dashboard you can search and export to CSV or JSON
No field builder (you already have form markup)
Easy to migrate away from later

Frequently asked questions

Can I use serverless form handling with a React or Vue app?

Yes. The endpoint is just a URL, so it works from any framework that can issue an HTTP request. Use fetch from your component, or point a plain HTML form's action at the endpoint — both work with the same form backend.

Does a form handler work without JavaScript?

Yes. A native HTML form with the action attribute set to your endpoint and method="POST" submits without a single line of JavaScript. The browser handles the encoding and the redirect.

What happens to the data I collect?

The service stores each submission in your account and you can export it as CSV or JSON at any time. You should pick a provider that keeps the data accessible and exportable, since that is what makes migration possible later.

Is a serverless form backend secure?

The endpoint should be HTTPS-only and the service should never log request payloads. In practice the biggest risk is bots: prefer a provider that ships spam protection, because a public endpoint will get crawled.

The takeaway

Serverless form handling removes the most expensive part of shipping a form: standing up and maintaining a backend before you have users. One POST endpoint replaces the database, the mailer, and the dashboard, and webhooks keep the data flowing into systems you already run. For landing pages, waitlists, beta invites, and static sites, it's the smallest solution that works.

If you want to try it without wiring up a database today, create a form on Formy and you'll have a live endpoint in about thirty seconds. For the decision framework behind choosing a provider, read what to look for in a form backend as a service.

On this page