Zunmao Forms

A form backend for static sites. No server of your own required: point your <form> at an endpoint, read submissions from your inbox.

Service status: documentation is live. The API Worker deploys to https://zunmao-forms.minos-zou.workers.dev once its KV namespace is created (see status note). The free tier below is the live design; the inbox viewer on the Inbox page works as soon as the Worker is up.

Quick start

Create a form (one call, no account needed for the free tier):
```
curl -X POST https://zunmao-forms.minos-zou.workers.dev/create \
  -H 'content-type: application/json' \
  -d '{"name": "Contact form"}'
```
You get back a form_id and an inbox_key. Save the inbox key now — it is shown only once. It is stored only as a hash, so it cannot be recovered later.

Point your static form at the submit URL:

<form action="https://zunmao-forms.minos-zou.workers.dev/f/frm_xxxxxxxxxxxx"
      method="POST">
  <input name="name" placeholder="Your name" required>
  <input name="email" type="email" placeholder="Email" required>
  <textarea name="message" placeholder="Message"></textarea>
  <!-- Honeypot: keep it hidden with CSS. Bots fill it; humans never see it.
       Submissions with a filled honeypot are discarded. -->
  <input name="website" tabindex="-1" autocomplete="off"
         style="position:absolute;left:-9999px" aria-hidden="true">
  <button type="submit">Send</button>
</form>

Plain HTML forms work, and so do JSON posts (

content-type:
application/json

Read submissions on the Inbox page with your form id and inbox key, or via curl:

curl 'https://zunmao-forms.minos-zou.workers.dev/inbox/frm_xxxxxxxxxxxx?key=YOUR_INBOX_KEY'

Endpoints

Method & path	What it does
`POST /create`	Create a form. Body `{"name": "..."}` (optional). Returns `form_id`, `inbox_key`, `submit_url`, `inbox_url`.
`POST /f/:id`	Public submission. Accepts JSON or `application/x-www-form-urlencoded`. Returns `{"ok": true}` on receipt.
`GET /inbox/:id?key=…`	List submissions as JSON (newest first), plus monthly usage. Wrong key → `401 unauthorized`; unknown form → `404`.
`GET /`	Health check and current limits.

Limits

Rule	Value
Request body cap	64 KB — larger bodies are rejected with `413 body_too_large`.
Rate limit	20 submissions per minute per IP per form — beyond that, `429 rate_limited`.
Spam handling	Honeypot fields (`website`, `_gotcha`, `bot-field`): filled honeypot submissions are silently discarded and never stored.
Free tier	100 submissions per form per calendar month. Beyond that, `429 monthly_quota_exceeded`.
Pro tier	$29 one-time payment raises the cap to 5,000 submissions per form per calendar month. No subscription billing: this stack bills one-time PayPal unlocks only, so recurring monthly billing is a later decision, not something we built here.

Status notes — read before you rely on this

Email forwarding is not yet available. Email delivery needs a third-party mail service key (Resend/SendGrid class service), which has not been provided. No email is sent today, and nothing here pretends otherwise. Submissions are stored in your inbox and readable via the Inbox page or the /inbox/:id endpoint. Email forwarding will be switched on after a mail key is connected.
Pro upgrade checkout is being connected. The $29 one-time Pro tier (5,000 submissions/month) is the pricing, but its PayPal unlock is still being registered on the existing payment worker. Until that lands, every form runs on the free 100/month tier. The Worker already reads a pro flag on the form record, so the upgrade takes effect without any change to your form endpoint.
API deployment is pending a KV namespace. The Worker stores forms and submissions in Cloudflare KV. Namespace creation is blocked on the current API credential (KV endpoints return 401 while Pages and Workers reads succeed), so the Worker itself is not live yet. The code is complete and tested locally; the live end-to-end check runs as soon as the namespace exists.

Open the inbox viewer →