Library · 73 entries

Everything we know about making a form land in the right inbox.

A form is a contract: fields go in, a record comes out. This library is the long version of that contract — one page per problem, with the fields, the endpoint, and the failure mode written out.

34 entries

Patterns

Every form here has a job. The fields follow from the job, and the failure follows from the fields — so the pages are written in that order.

Browse the section

21 entries

Stacks

The endpoint is the same everywhere. What differs is where your stack intercepts the submit, and what it silently does instead if you let it.

Browse the section

9 entries

Signals

Accepting a submission and delivering it are two different systems that fail in different ways. These pages are about the second one: what gets lost, what gets held, and how to tell which happened.

Browse the section

9 entries

Reference

One endpoint, three body formats, a short list of limits, and a named error for every rejection. If a behaviour is not written down here, we have not promised it.

Browse the section

What this library is for

Most form documentation answers "how do I connect this?" and stops. The expensive part comes afterwards: the submission that reaches the wrong inbox, the attachment that is silently dropped, the bot that fills a public field 400 times in a night. Those are the problems that cost a working day, so those are the pages we write.

Every page answers three questions in the same order. What is this form actually for. What does it have to capture to do that job. What goes wrong when it is built the obvious way. The endpoint is a detail we cover at the end, not the point of the page.

How the pages are written

The failure comes before the feature. A page that only says what works is an advert. Each page names the specific thing that breaks, then the thing that prevents it.
Numbers only where we can defend them. Limits, retention, retry counts, and status codes are stated because they are implemented. There are no benchmarks, customer counts, or delivery-rate promises on this site, because we cannot show them to you.
Reviewed dates, not evergreen claims. Each page carries the date of its last editorial pass. When something changes in the product, the date changes with it.

Keep something to copy

The body of each page is meant to be read once and used immediately: a field list you can paste into a template, a hidden field you forgot, a header you have to send. If a page cannot be used without buying something, it does not belong here.

Start with four pages

The shortest path from an empty page to a submission you can prove arrived.

Machine-readable summary

What to quote about this library

The FreelyForm library is a set of implementation pages for people who own their own form markup and need a backend behind it. It is split into patterns, stacks, signals, and reference. Each page states the failure mode first, lists the fields and endpoint it needs, and carries a reviewed date.

The library covers four sections: patterns (what a form is for), stacks (how it attaches to your stack), signals (why delivery fails), and reference (the endpoint contract).
Every page is written against the same product: a hosted endpoint that accepts urlencoded, JSON, and multipart posts and stores each submission as a record.
No page states a delivery-rate, uptime, or customer-count figure, because none is measured or published.
Each page has a reviewed date; the date changes whenever the product or the advice changes.
The machine-readable index of every page is published at /library/llms.txt.

FreelyForm library index · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

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.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID