Glossary
28 terms, defined so they can be quoted alone.
Each entry is a self-contained definition rather than a pointer to another page. Where a term has a behaviour attached — a limit, a state, a field — the value here is the one the running service uses.
Reviewed 2026-11-12. The machine-readable facts behind these definitions are at /facts.json.
Core concepts
The words that decide what a product is, before any feature comparison makes sense.
- Form backend
- The server-side half of a form: it receives the submission, validates it, stores it, notifies the people or systems that need it, and records what each delivery did. It is not the form itself and it has no editor. Detail →
- Form endpoint
- The absolute URL a form posts to, conventionally of the form /f/
- Form builder
- A product that hosts the form and owns its markup, usually with a drag-and-drop editor. It solves the half of the problem a hosted backend deliberately leaves alone: the form is yours, the post-submit path is not. Detail →
- Static site
- A site served from files, where the host answers GET and HEAD and nothing else. It can render a form and collect values, but there is no process to receive a POST, store it, or send mail. Detail →
- Intake versus operation
- Intake is data arriving that someone will read later: a message, an application, a request. An operation changes state in another system — creating an order, charging a card. Intake belongs in a form backend; operations belong in your own code.
Payload and contract
What crosses the wire, and the fields that change behaviour rather than being submitted.
- URL-encoded submission
- The browser default: application/x-www-form-urlencoded, the same encoding as a query string placed in the body. It carries text fields and cannot carry files.
- Multipart submission
- A boundary-delimited body used when a form includes files, enabled by enctype="multipart/form-data". A file form that omits that attribute is the most common cause of a submission arriving with everything except the attachment.
- Control field
- A reserved field name that changes how a submission is handled rather than being stored as data — for example _redirect for the post-submit destination, _replyto for the notification reply-to, or _partial to save a draft. Control fields are stripped from the stored payload. Detail →
- Idempotency key
- A client-supplied value that identifies one logical submission. Repeating a request with the same key returns the existing record instead of creating a second one, which is what makes a retry after a timeout safe. Detail →
- CORS and native posts
- A native form POST navigates the browser to the endpoint, so the same-origin policy does not apply to it. A fetch-based post does, so the endpoint must answer with the right Access-Control-Allow-Origin header and handle the preflight when the content type is not a simple one.
Delivery
The stage where a stored record becomes something someone receives.
- Verified recipient
- An address whose owner has confirmed control of the inbox. Notifications only go to verified recipients, because an endpoint that mails arbitrary addresses is a spam relay. Detail →
- Delivery record
- One status per destination for a submission: sent, failed, or suppressed, with the provider message id when it succeeded and the error text when it did not. A single "sent" flag cannot distinguish a delivered message from a rejected one. Detail →
- Autoresponse
- An automatic reply to the address that submitted the form, confirming receipt or promising a next step. It is a separate delivery channel from the owner notification and fails independently of it.
- Retry versus replay
- A retry is automatic and part of the same event: the system tries again after a transient failure, with backoff, up to a limit. A replay is a deliberate re-send after the cause is fixed, and the record shows that a human asked for it.
- Webhook signature
- An HMAC over the timestamp and the raw request body, sent in a header so the receiver can prove the event came from the sender and was not replayed from an old capture. Signing only the body lets an old request be reused. Detail →
- Suppression list
- Addresses that must never be mailed again for an account, because they hard-bounced or filed a complaint. Suppression is state, not a per-message decision: forgetting it damages the sending domain reputation for every customer on the account.
Spam and abuse
Signals that classify a submission without putting a puzzle in front of a real visitor.
- Honeypot field
- A hidden input that a person cannot see or tab to, checked at the endpoint. Automated submissions fill every field they find, so a filled honeypot is a confident verdict and costs a real visitor nothing.
- Time trap
- A hidden timestamp written when the page renders, compared at the endpoint. A submission that arrives faster than a person could type was not typed, and no captcha is needed to act on it.
- Spam verdict
- A classification attached to a stored submission rather than a reason to delete it. Storing the verdict with its reasons keeps a false positive inspectable and adjustable, while a silent drop hides a lost customer. Detail →
- Open relay
- An endpoint that will send mail to any address a stranger names. It turns a form service into a bulk-mail tool, degrades the sending domain reputation, and usually ends in the upstream provider suspending the account.
- Disposable mail domain
- A throwaway inbox provider whose addresses are almost never used by real customers on a business form. It is one signal among several, not proof on its own.
Storage, quota and data
What happens to the record afterwards, and what limits apply to it.
- Submission record
- The durable stored form of one post: field values with their types, a UTC timestamp, request metadata such as client address and referrer, a status of its own, and any attachments.
- Partial submission
- A saved draft that returns a resume link instead of delivering anything. On this service a draft is not counted against the monthly allowance; completing it counts once.
- Monthly allowance
- The number of submissions an account may receive in a calendar month, set by its plan unless an explicit per-account override exists. Detail →
- Over limit
- The state a submission is stored in when the account has used its monthly allowance: it is kept and visible, nothing is sent, and nothing is counted. Visitors are never rejected because of the owner’s quota. Detail →
- Reprocessing
- Deliberately releasing a held submission once there is room in the allowance. It counts the submission for that month, sends the notification, and moves the record into the normal flow.
- Attachment retention
- How long uploaded files are kept, counted from receipt and configurable per form. It is a separate clock from the submission record, so a record can outlive its files by design.
- Controller and processor
- Under data-protection law the form owner decides what a form collects and why, so the owner is the controller. The service stores and forwards on instruction, so it is the processor for submission content. Detail →
Terms we do not use
Three phrases are common in this market and absent from this site, because each one implies something that cannot be checked by a reader: a compliance certification (none is issued for the regulations usually named), an uptime percentage (this service publishes no SLA), and a delivery-rate guarantee (it depends on the sender's domain reputation, not only on the service). The full list of what this service does not provide is on the facts page.
Put your forms on a backend that keeps a record.
Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.
One action attribute · urlencoded, JSON, or multipart · no SDK, no build step