The oldest feature of the web — a form with an action attribute — can store data on FormLM. Point the action at your endpoint and submit natively.
The <form action="..." method="POST"> pattern is one of the oldest contracts on the web: the browser gathers the named inputs, urlencodes them, and POSTs them to whatever URL the action names. For decades that URL had to be your own server-side script — which is why "add a form" used to mean "add a backend."
A form endpoint breaks that coupling. The action points at FormLM; the browser does exactly what it has always done; the submission is stored as a structured record with one column per input name. Your page remains a static file — no build step, no runtime, and it keeps working with JavaScript turned off entirely.
<!-- The whole integration --> <form action="https://formlm.me/api/v3/share/YOUR_TOKEN/form" method="POST"> <input name="topic" placeholder="What's on your mind?" required> <input name="email" type="email"> <fieldset> <label><input type="checkbox" name="interests" value="design"> Design</label> <label><input type="checkbox" name="interests" value="engineering"> Engineering</label> </fieldset> <button type="submit">Send</button> </form> <!-- Multiple values with the same name arrive as an array. --> <!-- Input names become stored columns, automatically. -->
Hostile environments. Privacy extensions, corporate proxies, and text-only browsers block scripts — a native form still submits. Printed and archived pages. A form that works when the page is saved as HTML and opened months later works the same way it did on day one. Email-adjacent and embedded contexts where script injection is restricted. And simplicity itself: there is nothing to minify, bundle, or debug — the page is honest, readable HTML.
The trade-off: after submitting, the browser lands on the endpoint's JSON response instead of staying on your page. Two fixes exist — accept it (the response confirms storage and includes the record id), or upgrade selectively to a fetch handler that keeps users in place. The static site forms guide shows the fetch variant; both store identical records through the same endpoint.
Submissions are visible in FormLM immediately and exportable as CSV. Enable the query API and the same endpoint family serves reads: GET /{token}/query pages through records, and GET /{token}/summary returns aggregate statistics. Every read endpoint also answers ?help with a Markdown doc — which means scripts, automations, and AI agents can discover the read path as easily as the write path. If your data deserves more than storage — scoring, bands, personalized PDF reports — that's the same records flowing into FormLM's assessment engine.
Yes — the form's action attribute can point at any URL, including a hosted endpoint on another domain. The browser POSTs the field values to that URL; the endpoint stores them. Your page needs no server-side code at all.
Yes. Native form submission is a browser feature that predates JavaScript. FormLM's endpoint accepts the standard application/x-www-form-urlencoded POST that browsers send, so the form works with JS off, in text-only browsers, and in strict privacy setups.
Two: application/x-www-form-urlencoded for native HTML forms (the /form path) and application/json for fetch or curl clients (the main endpoint). Both store the same structured records.
When a field submits multiple values (like a group of checkboxes sharing a name), the endpoint stores them as an array. Single values are stored as plain strings or numbers.
With a native POST the browser shows the endpoint's JSON response. To control the experience, add a small fetch handler that submits via JavaScript and shows your own message — or keep it JS-free and accept the plain response page.
Free endpoint, native HTML POST, records you can query back.
Create your free endpoint →