What happens to a form submission after you hit submit

Published 2026-07-12

Most form backends treat a submission as an email with extra steps: the POST arrives, an email goes out, and if anything in between hiccups, the submission is gone. Nobody notices until a customer follows up angry.

SubmissionBuddy is built the other way around: the submission is data first, notification second. Here is exactly what happens between your visitor clicking Submit and the email landing in your inbox — and why each step exists.

Step 0: the POST

Your form points at one endpoint:

POST https://api.submissionbuddy.io/f/your-form

It accepts three content types, so it works with whatever you already have:

• application/json — from fetch() in any framework
• application/x-www-form-urlencoded — a plain HTML <form>
• multipart/form-data — text fields from multipart forms

There is no field schema. Send name, email, message today and add budget tomorrow — nothing to reconfigure.

Step 1: validation and spam checks

Before anything is stored, the request passes a gauntlet:

1. Size limit — payloads over 1 MB are rejected outright.
2. Rate limiting — per-IP-per-form and per-IP-global limits. Bursts from one address get 429s instead of flooding your inbox.
3. Honeypot — if your form includes a hidden _honeypot field and a bot fills it, we return a normal-looking success response and silently drop the submission. The bot learns nothing.
4. CAPTCHA (paid plans) — if enabled, an invisible-CAPTCHA token is verified server-side.
5. Risk scoring — origin, rate-limit pressure, and honeypot signals are combined into a risk score stored with the submission, so you can judge borderline cases later instead of guessing.

Step 2: durable storage — before anything else

This is the step that makes the difference. The raw payload, plus metadata (IP, user agent, origin, risk score), is written to immutable object storage the moment it passes validation. Only then do we acknowledge your visitor with a 202:

{ "ok": true, "submission_id": "9be2…" }

At this point the submission cannot be lost. Not by a database outage, not by a bad deploy, not by an email provider having a bad afternoon. The stored object is the source of truth; everything downstream is derived from it and can be replayed.

Step 3: queue-backed processing

A message — containing only a reference to the stored payload, never the payload itself — is placed on a queue. A worker picks it up and writes the submission into a queryable database that powers the dashboard: search, filters, Excel export.

If the worker fails, the message goes back on the queue and is retried. The raw payload sits safely in storage the whole time.

Step 4: notification, as its own stage

Email sending is a separate queue and a separate worker. Your notification template is rendered, stored, queued, and sent — and retried independently if the mail provider blips.

This separation is deliberate: an email problem can delay a notification, but it can never touch the submission itself. Compare that with email-first form handlers, where the email is the submission.

Why bother with all this for a contact form?

Because the failure mode of a form isn't dramatic — it's silent. A dropped submission doesn't throw an error on your site; it just quietly costs you the lead. The pipeline above turns every failure into either a retry or a delay, never a loss.

If you'd rather not build and babysit this yourself (S3 buckets, queues, workers, idempotency, retries), that's the product: point your form at the endpoint and get the whole pipeline — free for 100 submissions a month, no credit card.