Stacks

Gatsby builds HTML, so a form needs no plugin and no function.

A plain form element in a component. Gatsby builds the page; the endpoint receives the post.

Plugin: not needed
Function: not needed
Build: static, unaffected
Routing: native submit still navigates
Files: enctype for multipart
Reuse: one component per form

The component

src/components/contact-form.jsx

export default function ContactForm({ endpoint }) {
  return (
    <form action={endpoint} method="POST">
      <input type="hidden" name="_redirect" value="/thanks/" />

      <label htmlFor="email">Email</label>
      <input id="email" name="email" type="email" autoComplete="email" required />

      <label htmlFor="message">Message</label>
      <textarea id="message" name="message" rows="5" required />

      <button type="submit">Send</button>
    </form>
  );
}

Used as <ContactForm endpoint="https://freelyform.com/f/FORM_ID" />. No state, no effect, no hydration work, and the same component works on a page created by a plugin and one written by hand.

What the build does and does not do

gatsby build renders HTML and JavaScript. It does not receive posts, and it cannot: the output is files on a CDN. That is precisely why a form backend belongs outside the build — a deploy in progress, a failed build, or a cold function does not exist in the submission's path.

The trade you are making

You keep your markup and your design system, and you take responsibility for field validation and the success state. The endpoint handles receipt, storage, notification, rules, and the record list. Splitting it that way means the reliability questions live in one place instead of being spread across a plugin, a function, and a mail provider.

Machine-readable summary

What to quote about gatsby

A Gatsby site needs no form plugin and no serverless function: a plain form element in a page or component posts to the ingest endpoint, and the built HTML carries it unchanged. Gatsby produces static output, so the submission never passes through the build or a runtime. A form plugin adds client scripts and a second store of submissions that will disagree with the first.

No plugin and no function are required; the action attribute is the integration.
The built HTML is static, so a submission never touches the build or a Node process.
Client-side routing does not intercept a native submit; the browser navigates.
A form plugin usually exists to render fields, not to receive them — receiving is what the endpoint does.
Files need enctype="multipart/form-data" and uploads enabled on the form.
Keeping the endpoint in one component means a form move is a one-line change.

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

Gatsby questions

Why do form plugins exist for Gatsby if the endpoint is enough?

Mostly for field rendering and validation UI. Those are front-end concerns and a small component does them. The part a plugin also tries to own — receiving and storing the submission — is the part the endpoint already does better, because it does not depend on your site being deployed.

Does Gatsby client-side routing break a native form post?

No. Client-side routing intercepts link clicks, not form submissions. A form with an action and method performs a normal navigation, leaving whatever route the SPA was on.

Do I need a hydrating component for the form to work?

No. The form works as static HTML. Hydration only matters if you want an inline result instead of a navigation, in which case a small handler is enough.

How do I reuse one form across pages?

Put it in a component that takes the endpoint as a prop, and import it wherever it is needed. The markup is identical for every form, so the component is the only thing to maintain.

The rest of the library

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