One URL accepts every submission, and answers in four different ways.

Why there is only one URL

Most form services give each form its own hostname or a long path with a token in it. That is convenient for the vendor and awkward for you: a form id ends up hard-coded in a theme file, in a build config, and in an environment variable, and moving a form means touching all three.

Here the form id is a single path segment. Swapping forms is a string change in one file. Pointing a staging page at a staging form is the same edit. Nothing else about the endpoint is form-specific.

The four things that can come back

Which answer you get depends on two things: whether the client asked for JSON, and whether the form has a redirect URL configured.

• 200 with JSON. The client sent Accept: application/json. The body contains ok, the submission id, the success message, and the redirect target if one is configured. This is what you want for a fetch call.
• 200 with an HTML page. A plain form post with no redirect set. Somebody submitting without JavaScript should land somewhere that says the submission arrived, not on a blank screen.
• 303 with a Location header. A redirect URL is configured, so the browser is sent to your thank-you page. The status is 303 rather than 302 so that a refresh does not re-post.
• A refusal. Anything from 400 to 429, with an error string. See the status code page for the full list.

const response = await fetch("https://freelyform.com/f/FORM_ID", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Accept: "application/json"
  },
  body: JSON.stringify({ email: "[email protected]", message: "Hello" })
});

const result = await response.json();
if (!result.ok) {
  // result.error is a stable string, e.g. "rule_rejected"
  console.warn(result.error, result.message);
}

What the endpoint will not do

It will not render a form for you, inject a widget, or generate a stylesheet. That is the trade: you keep the markup you already have, and in exchange you are responsible for the markup. If you want help with the boring parts, the optional script at /embed.js adds inline success and error text to an existing form and changes nothing else.

It also will not validate in the browser. Your required, type="email", and pattern attributes are the only client-side checks. Server-side, a require rule can reject a submission that is missing fields, and that rejection comes back as a 422 rather than as browser UI.

What happens after the 200

Three things start in parallel and independently. The submission is stored as a record. A notification is queued for every verified recipient, retried up to five times if the mail provider refuses. Any active webhook endpoint receives a signed event. If the first two fail, the record still exists — which is why the dashboard, not the inbox, is the source of truth for whether a submission happened.