Contact form API: status codes, errors and rate limits of 10 services

How we tested

We posted the same JSON (a name, an email and a message) to each service with a key we made up, so nothing was stored or delivered. Then we sent 30 of those posts back to back to see where a rate limit starts. The rules for reading each answer were written down before the first request. Requests went out with curl from a connection in Turkey on 29 October 2026, 14:12 to 14:26 UTC. A browser check from a page on example.com confirmed the error bodies. FormSubmit answered everything with Cloudflare error 521, an outage on its side that was still there 30 minutes later, so its row is empty. Body formats, CORS and server posts are on the form endpoint page.

What a wrong key returns

Three things in this table break naive client code:

• The status and the body disagree. Forminit sent HTTP 200 with "code":404 in the body. Formcarry sent HTTP 500 with "code":401, although its docs say the two match. Code that checks only res.ok treats Forminit's error as a sent message. Code that retries on 5xx keeps retrying Formcarry's wrong key.
• Not every error is JSON. Formspark answered a JSON request with a plain-text line, so await res.json() throws.
• There is no shared field. Five of the nine have a success boolean. Formspree, Basin, Formcarry and Formspark do not. Only four give a stable code you can branch on.

What a successful post returns, according to the docs

Formspree, Basin and FormSubmit do not show their success body in the pages we read, and Static Forms' docs would not load for us. For those four, test with a real form before you rely on any field. Web3Forms' docs put data and message under body, but the error we received had them at the top level, so read both places.

Rate limits: what 30 quick posts got

Formspree cut us off at request 21, exactly its documented 20 a minute. Splitforms stopped us at request 7, its documented 6 a minute. Static Forms was stopped by its hosting provider's firewall at request 10, not by the app. None of the three 429 answers carried a Retry-After header, so your code has to pick its own wait. Formgong sends Retry-After: 10 on its burst limit; our 30 posts stayed under it.

Forminit and Formcarry document one post per 5 and 15 seconds, yet 30 posts with a wrong key never triggered either limit. Our guess is that they count only posts to a real form; we could not check that without one.

Formgong was the second slowest of the nine to answer a wrong key, at 0.72 seconds. That is our own number to improve.

A fetch client that copes with all of them

This is the check we would put in front of any of these APIs. It reads the body as text first, so a plain-text error cannot throw. It treats a 2xx as success only when the body does not say otherwise, and it waits on 429. Swap the URL for your service's endpoint, and put its key where its docs say: in the URL or as a form field.

async function send(form) {
  let res;
  try {
    res = await fetch("https://formgong.com/submit", {
      method: "POST",
      headers: { Accept: "application/json" },
      body: new FormData(form),
    });
  } catch {
    return { ok: false, message: "Network error. Please try again." };
  }
  const text = await res.text();           // some services answer errors in plain text
  let data = null;
  try { data = JSON.parse(text); } catch {}

  if (res.status === 429) {
    const wait = Number(res.headers.get("Retry-After")) || 30;
    return { ok: false, message: `Too many messages. Try again in ${wait} s.` };
  }
  // A 2xx alone is not enough: one service answered a broken form with 200.
  const ok = res.ok && data !== null && data.success !== false && data.status !== "error";
  return { ok, message: data?.message ?? text };
}

Before you ship, send the form once with a wrong key. If your page says "thank you", the check is not doing its job. Our free form checker runs the same test on a live page.

What this test does not show

We saw each answer once, from one place, with made-up keys. Answer times from your visitors' countries will differ, and a limit that counts only real submissions will not show up here. The success column is what the docs say, not what we measured. When we run a round with real forms, it goes on this page.

Tell us what to test next

Is a service missing, or did one of them answer you differently? Write to support@formgong.com and tell us what you saw. We read every message, and the next round of this test starts from what readers ask for.