action URL, and a hidden field instead of the endpoint
ID being baked into the URL. This guide covers the swap itself and the handful of
behavioral differences worth knowing before you flip the switch, so nothing breaks
silently.
The core swap
A typical Formspree form posts straight to an endpoint with your form ID embedded in the URL:/submit - and instead
identifies your form through a hidden access_key field in the body, not through the
URL:
action URL, and one new hidden access_key input.
Every other field - your email, message, or whatever custom fields your form
already has - keeps its name and works unchanged, since neither service reserves those
names.
Get your access_key (fp_…) by creating a form in the
dashboard (or asking an agent to do it via the MCP
create_form tool) - see Your first form if
you’re starting from scratch.
If you’re using Formspree’s AJAX/fetch integration
The pattern is the same shape, just pointed at a different URL and withaccess_key in
the body instead of the endpoint path:
200 with
{"success": true, "message": "Submission received.", "id": "sub_..."} - check
res.ok or success the same way you’d have checked Formspree’s response.
Mapping the rest of your setup
Differences worth knowing before you switch
No spam puzzles. If your Formspree form had reCAPTCHA or hCaptcha wired in, just remove it - don’t look for an equivalent to configure. Formpaste relies entirely on server-side heuristics (honeypot, timing, link density, rate, disposable-email) that never show your visitor a puzzle. If you had a honeypot field for Formspree, rename it tobotcheck - that’s the specific name Formpaste checks - and hide it with CSS
(display:none), not type="hidden", so unsophisticated bots that skip hidden inputs
still fall for it. See Preventing spam.
Suspicious submissions are quarantined, not silently dropped or blocked. A
submission that scores as spam still lands somewhere you can see it - the dashboard’s
Spam tab - rather than vanishing. On Free that view is read-only; re-delivering a
false positive (“rescue”) is a Pro action. If your
Formspree spam filter silently discarded submissions, budget time to check the
quarantine tab occasionally after migrating, in case anything legitimate needs a nudge.
No REST API for forms or submissions. Formpaste doesn’t have a general
create-form/list-submissions REST API. Forms are created in the dashboard or via the
MCP create_form tool; submissions are read via the dashboard, CSV export, or the MCP
list_submissions tool - see Retrieving submissions if
you were scripting anything against Formspree’s API surface.
An MCP server, if you’re wiring this up with an agent. If you’re migrating a form
with the help of Claude Code, Cursor, or another MCP-speaking agent, it can create the
form and hand you back a wired snippet directly - see MCP server
and the cookbook prompts. This isn’t a Formspree
equivalent; it’s new surface Formpaste has that Formspree doesn’t.
Plans are simpler. Formpaste has exactly two plans - Free and Pro (four
submission-quota tiers within Pro) - rather than Formspree’s multi-tier structure. See
Pro plan if you’re evaluating whether your current usage fits
Free’s 250 submissions/month.
After you switch
- Update the
actionURL and addaccess_keyon every form you’re migrating. - Verify each form’s destination email (one-time OTP per address) - see Your first form.
- Rename any honeypot field to
botcheckand confirm it’s hidden with CSS. - Remove any CAPTCHA widget/script - it isn’t needed and Formpaste won’t read it.
- Set the domain allowlist once you’ve confirmed submissions are arriving, so the form isn’t left open to any origin indefinitely.
- Submit a real test and confirm it lands in the dashboard inbox and your email.
Your first form
Full walkthrough for creating a form and verifying its destination.
Framework snippets
Wired examples for HTML, React, Next.js, Astro, Vue, and Svelte.
Preventing spam
How filtering works.
Retrieving submissions
Dashboard, CSV export, and the MCP tool - no REST API.