How Form to CMS works

Form to CMS lets visitors submit entries to your Framer site's CMS — with you in charge of what goes live. A visitor fills in a form; the submission is screened for spam and quality; it waits in a moderation queue; when you approve it, it appears on your site as a real CMS item. No Zapier, no spreadsheet, no re-keying.

It's built for sites that run on other people's content: directories, job boards, community showcases, resource lists. The pieces a thin form-to-webhook connector doesn't have — moderation, screening, paid listings, expiry, an audit trail — are the product.

Two halves: a Framer plugin (creates forms from your CMS collections, syncs approvals back) and a dashboard (the moderation queue your team works in).

1. Install the plugin. Find "Form to CMS" in the Framer marketplace and open it on your project's canvas.
2. Sign in from the plugin. The plugin opens the dashboard to approve the connection — one click, no password. (We use email magic links.)
3. Pick a CMS collection. Choose the collection submissions should feed — an existing one or a new one. The plugin reads its fields and proposes a form: tick the fields visitors should fill in, mark which are required, pick the title field.
4. Insert the form. The plugin drops a preconfigured code component onto your canvas. Style the surrounding layout however you like — the form renders your collection's fields on your own page, on your own domain.
5. Publish your site and moderate. Submissions appear in the dashboard queue, already screened. Approve, edit-then-approve, or reject with a reason. Approved entries sync back into the connected CMS collection — press Sync in the plugin (or just wait for your next visit to the canvas).

Prefer not to touch the canvas at all? Every collection also gets a hosted form at formtocms.com/f/<site-key>/<collection> you can link to.

All three land in the same queue and the same pipeline.

1. The code component (recommended)

Inserted by the plugin, or added manually from the marketplace listing. It fetches your collection's form schema and renders exactly the mapped fields — adding a field in the dashboard updates the live form with no code edit. Configure the site key, collection, button label, success text and accent color in Framer's properties panel.

2. The hosted form

A ready-made page on our domain for every collection: /f/<site-key>/<collection-slug>. Useful for linking from emails or socials, and as the zero-setup fallback.

3. Native Framer forms (and anything else that can POST)

Point any form at your ingest endpoint — POST /api/ingest/<site-key> — and it joins the same queue. See the API reference for the payload.

A collection's mapping is the contract between the form and the CMS: each entry maps a form field to a CMS field, with a human label, an optional required flag, a length cap, and a rendering kind (text, longText → textarea, url). The plugin derives all of this from your Framer collection's field types; the dashboard's site creator lets you define it by hand.

Ingest validates against the mapping: unknown fields are dropped, missing required fields fail the submission with a clear message, over-length values are rejected. The designated title field becomes each submission's headline in the queue.

The queue gives every submission four verdicts:

• Approve — publishes it: the entry becomes a CMS item, goes live, and starts its expiry clock if the listing type has one.
• Edit & approve — fix a typo or tighten copy first, then publish. The edit is recorded in the audit trail.
• Reject — with a reason (templates provided). If the submission was paid, the payment is automatically refunded in full.
• Restore — pull a false positive out of spam back into the queue. Spam is kept 30 days, then dropped.

Every action lands in the listing's audit trail: what arrived, how it screened, who approved or rejected it, what changed, when it went live. When a submitter asks "what happened to my listing?", the answer is one click away.

Before a submission reaches your queue it passes through:

• a honeypot field (bots fill it, humans never see it),
• blocklist checks,
• duplicate detection against the submitter's prior entries,
• link-flood and shouting checks,
• a transparent quality score (0–100) from content signals — no black box; the signals appear on the submission.

Each site sets a strictness: off (score is informational), flag (low scores are marked "needs review" but still queue — the default), or reject (below the threshold goes straight to spam). Screened-out submissions never notify you; they sit in the Spam tab for 30 days in case you want them back.

A site can define listing types — say, Standard (free), Paid ($29), Featured ($79, pinned styling on your site). Visitors pick one at submission; payment is captured through your own Stripe account at the moment they submit, before you moderate.

• We take 0% of listing revenue. The subscription is our income.
• Rejecting a paid submission auto-refunds it in full.
• Payments and refunds appear in the listing's audit trail and your revenue stat.

Paid listing types are available on every paid plan (Starter and up).

A listing type can carry a duration — 30 days is the job-board classic. When a published listing lapses, the sweep unpublishes it (the CMS item comes off the site); listings in their final week are flagged "expiring soon" so renewal nudges can go out. Run the sweep from the dashboard header, or on a schedule in production.

Plans are per workspace — invite your whole team on any tier. The meter is submissions per calendar month (spam never counts) plus a site cap:

Going over never loses data. At 80% of your allowance the dashboard nudges you; at 100% it warns; only at 150% do your forms pause — visitors see a polite "submissions are paused" notice instead of an error, and everything reopens when the month resets or the plan grows.

The trial: every new workspace gets 14 days of Pro, no card, starting when you connect your first site (not when you sign up). After it, you land on Free — published items stay live, nothing is deleted.

Ingest a submission

POST /api/ingest/<site-key> — public, CORS-open (it's called from your visitors' browsers). Content type application/json:

curl -X POST https://app.formtocms.com/api/ingest/YOUR_SITE_KEY \
  -H 'content-type: application/json' \
  -d '{
    "collection": "makers",
    "listingType": "Standard",
    "name": "Ada",
    "email": "ada@example.com",
    "fields": {
      "title": "My tool",
      "tagline": "Does one thing well",
      "website": "https://example.com"
    }
  }'

collection is the collection slug; email is required; listingType is a listing type name or id (defaults to the cheapest); honeypot, if you render one, should be an empty string from humans.

Responses:

• 201 — accepted: { id, status, statusUrl } where status is pending (or spam, silently).
• 400 — validation problem; error says what.
• 402 with code: "quota" — the site's monthly allowance is exhausted; show a "paused" state.
• 404 — unknown site key.

Read a form schema

GET /api/form/<site-key>/<collection-slug> — the public field list a front door should render (labels, required flags, input kinds), plus paused and credit flags. This is how the code component self-configures.

The Framer feed

GET /api/framer/<site-key> — published listings as a stable feed; the plugin's sync uses it to write approved entries back into your CMS collection.

Stuck, or building something the docs don't cover? Email henry@kirkness.com — replies come from the person who wrote the code. Paid plans get priority; Agency gets a setup call if you want one.

Ready to try it? Start free — 14-day Pro trial, no card.