Web3Forms Alternative · SubmitHarbor

What either service does for you

Both products occupy the same niche: a static or client-rendered page posts to a hosted URL, a public key routes the submission, server-side spam checks run, and a human finds out. The setup syntax differs, though, and Web3Forms changes independently. Its current feature set belongs in its own documentation; judge it there rather than from a copied feature table here.

A public routing key: Web3Forms documents an access key in a hidden field or in the action URL; SubmitHarbor puts its project key in the action URL. Both are intended to sit openly in your markup rather than act as account passwords.
JSON or a plain form body: Both services document a native <form> post and a browser fetch flow. Their field names and success responses differ, but neither requires a client library for a basic message.
Server-side spam checks: Both services check submissions on the server. SubmitHarbor supports the website and _gotcha honeypots; Web3Forms documents botcheck, while warning that honeypots are deprecated there in favour of stronger CAPTCHA options.

Where SubmitHarbor takes a different position

The dividing question is what happens after the POST succeeds. Some form services exist chiefly to relay each entry into your mailbox and forget it. This product treats the stored record as the primary artifact and the notification as a courtesy on top.

A durable inbox, not just a forwarded email: Every accepted submission is written to a private inbox scoped to your project, so a mislabeled message, a full mailbox, or a crashed laptop does not erase a lead. Email delivery can fail silently; the inbox is the record.
Read state, search, and export: Entries carry unread markers until opened, filter across every field, and leave as CSV when you want them elsewhere. The exported rows are exactly the ones on screen.
Replies come from you: Opening an entry offers a pre-addressed reply drafted in your own mail client, keeping the thread and the sender's trust attached to your address rather than a third party's relay.
Limits printed, not discovered: 20 submissions a minute per address, 64 KB bodies, 20 fields, 5,000 characters per value — every ceiling on this page is enforced by the running route and listed on the endpoint reference.

Our numbers, so you can compare directly

These are the ceilings this endpoint enforces today. Whatever provider you currently use publishes its own equivalents; put the two lists side by side and pick.

Limit	Value	What happens at the edge
Request body	64 KB	Larger declared payloads are rejected with 413.
Fields per submission	20	Counted after control fields are removed; 422 beyond it.
Characters per field	5,000	Values are trimmed first, then checked; 422 beyond it.
Field name	1–50 characters	Letters, numbers, underscores, and hyphens only.
Submissions per minute	20 per address, per endpoint	A fixed 60-second window, then 429.

A comparison is only useful while it is current, so treat both sides as moving targets: re-read the other provider's documentation before committing, and hold this page to the same standard.

The full SubmitHarbor contract, status codes included

Moving an existing form across

The page structure and ordinary fields can stay in place. The provider-specific action, routing key, honeypot name, and response handling are the pieces to review.

Point the action at your new endpoint: Create a project, copy its sh_… URL, and replace the old action value. Keys are not portable between providers — each service mints its own — but everything else travels.
Keep `email` and `message`: SubmitHarbor requires those two names, so an existing form that already uses them keeps them untouched. Any additional inputs arrive under the names you already gave them.
Rename the hidden trap input: Whatever your current honeypot is called, this endpoint listens for website or _gotcha. One attribute change keeps the protection working.

Kick the tires first

Run this now — the shared demo key is open and answers immediately

curl -i -X POST https://www.submitharbor.com/api/submit/demo_contact_7x2p \
  -H "Content-Type: application/json" \
  -d '{"email":"you@example.com","message":"Testing the demo endpoint."}'

The shared demo key validates a submission and echoes it back, then discards it. It never writes to the database, because a stored demo submission would leave a stranger's details in an inbox nobody owns. Create your own endpoint to keep what arrives.

What SubmitHarbor does not do

Worth reading before you build on it. These limits apply today.

The shared signed-out demo validates and echoes a preview; durable endpoints, storage, and notifications require a configured signed-in project.
SubmitHarbor does not promise an uptime SLA, attachments, CAPTCHA providers, webhooks, CRM integrations, or unlimited submissions.
Origin checks and honeypots reduce common abuse but do not replace a complete security and privacy review for sensitive forms.

Questions about web3forms alternative

What does SubmitHarbor cost?

Nothing today. There is no billing system yet: create projects, collect submissions, and export CSV without paying. Paid tiers exist only as a plan for when real usage justifies them.

Do submissions get stored, or only emailed?

Stored first, emailed second. The inbox holds every accepted submission; the optional notification reports whether it was sent, and a failed email never costs you the record.

Can I run both services during a transition?

Yes. Use separate test forms or deliberately split a small amount of traffic between two visible, independently submitted versions. Do not make one visitor submission fire at both providers: that duplicates personal data and muddies consent.

Is the project key safe to publish?

It is meant for public markup. It can invite submissions to that one project and do nothing else — the inbox opens only for your signed-in account.

An inbox-first Web3Forms alternative, compared honestly