Web forms

Signups, RSVPs, pledges and surveys as living pages: draft → publish → archive, edited live beside a preview, with responses that are people.

7 min read

A form under Forms is a living page with a lifecycle: draft, published, archived. You pick a type when you create it (Signup, Pledge, RSVP, Request, Survey), edit it live beside a preview, and share one public link. Every response creates or updates a person, so submissions arrive as records, never a spreadsheet to import on Friday.

Create from a template

Open Forms and click New formPick a starting template card, then name the form. It opens as a draft in edit mode.
Turn fields on and set what’s requiredCheck a field to add it; click its Optional/Required pill to toggle. Drag a field by its handle to reorder it; the order you set is the order people see on the public form. Changes apply to the live form instantly. There is nothing to save. Every form also carries an optional “I’d like a yard sign” checkbox: turn it on and a checked box creates a sign request in Deliveries for the submitter’s address (Movement plan; turn the address fields on with it so new supporters have an address to deliver to).
Publish when it’s readyPublish activates the public link and the form starts accepting responses. Unpublish pauses it; the link keeps working again the moment you republish.

Email is the identity key

Every form always collects an email, always required. It’s how each response is matched to (or creates) a person. That’s why the email field can’t be turned off or made optional.

Every form has its own address

Selecting a form puts it in the address bar, and editing it adds /edit. So you can bookmark a form, send a colleague a link straight to the one you mean, refresh without losing your place, and use the browser’s Back button to step back through the forms you looked at.

Responses are people

The Responses tab lists each submission and links straight to the person it created or updated. Every response also applies the form’s tags, including an automatic Source: <form name> tag, and joins the lists you chose under Audience, so your segmentation stays effortless. Export the responses to CSV anytime.

What a response may change on someone you already have

A form is public, so anybody can submit one. When the email matches a person already in your workspace, the response is linked to them rather than allowed to rewrite them: it can fill a first name, last name or mobile that is currently blank, and nothing else. It never overwrites a value you already have, never changes their household or address, and never edits their notes. The full answers — address and message included — are kept on the response itself, where you can read them and apply anything worth keeping by hand. A brand-new person is created in full, address and all.

Only the fields your form defines are accepted

A submission is matched against your form’s own field list. Answers to fields the form doesn’t define are discarded and never reach the person record or the response — so a form with no address inputs cannot receive an address, whoever posts to it.

Copy the public link or open the standalone page from the link row.
Use the </> embed to drop the form into any site: an auto-updating iframe, or a raw HTML form that reflects your currently enabled fields.
Turn on a confirmation email to thank people automatically, or notify your team when a response lands (both under After submit).

Bring your own form (API)

Already have a form that matches your website’s design? Keep it. Point its submit action at your form’s public endpoint — POST /api/forms/submit/<slug>?t=<workspace> on the API domain (the same URL the raw-HTML embed uses) — with your enabled field names, and every submission still becomes a person, applies your tags and lists, and respects double opt-in. Include the hidden _hp field and leave it empty; it’s the spam trap.

Submitting from your own server or backend instead? Create a workspace API key (Workspace settings → API keys) and send it as an Authorization: Bearer header. The key identifies your workspace on its own — no ?t= needed — and lifts the anonymous per-visitor rate limit in favor of a per-workspace one built for batch traffic. The same key authenticates Zapier and the event RSVP and volunteer signup endpoints. API access is available on Grassroots and above.

What the key unlocks (endpoint reference)

POST /api/forms/submit/<slug> — submit a form response. Keyless from a browser (with ?t=<workspace>); keyed from a server.
POST /api/event-pages/rsvp/<slug> — RSVP to an event page, using the same field names as the public page.
POST /api/events/signup/<slug> — sign a volunteer up for a shift, using the same field names as the public page.
POST /api/zapier/persons/upsert — create a person, or update the person with that email. email is required; names, phones, social links and notes are optional.
POST /api/zapier/persons/tag and POST /api/zapier/persons/untag — add or remove a tag, identifying the person by email and the tag by tag_name.
GET /api/zapier/persons/search?email=<address> — find people by exact email match. Returns a list; an empty list means no match.
GET /api/zapier/persons/recent — the ten most recently added people.
GET /api/zapier/me — names the workspace behind the key; useful as a connection test.

Webhooks out: POST /api/zapier/subscribe with a JSON body of event_type and hook_url registers an HTTPS URL to be called whenever the event happens — person_created, person_updated, person_deleted, person_tag_added or person_tag_removed. It returns an id; DELETE /api/zapier/subscribe/<id> stops that webhook. Several webhooks can listen to the same event, so more than one Zap or service can subscribe at once. Any service that can send HTTP requests and receive webhooks — Zapier included — can drive all of this. Keyed requests are limited to 120 per minute per workspace.

Never put the API key in a public page

The key is a secret — anyone who has it can write into your workspace. Browser-side forms don’t need it (the public endpoint works keyless); the key belongs only in server-side code. If it ever leaks, Revoke it in Workspace settings → API keys: it stops working instantly. A workspace can hold two keys at once, which is how you rotate without downtime — add a second key, move your integrations onto it, then revoke the first. Each key shows when it was last used, so you can tell which one is still in service before you revoke anything.

Archive, don’t delete

A form with responses can be archived. Its public link shows a friendly closed notice and every record keeps pointing at it. Restore brings it back as a draft. Only an untouched draft with zero responses can be deleted outright.

Forms need a paid plan — including forms already published

Forms are available on Grassroots and above. If your workspace moves to the Free plan, published forms stop accepting submissions: anyone opening one on your website sees an error. Nothing is deleted — your forms and every response you have already collected stay exactly as they are, and everything resumes the moment you upgrade again. The Billing page warns you about this, and tells you how many published forms are affected, before the change goes through.

Double opt-in and your forms

If your workspace enables double opt-in (Workspace → Communications), new subscribers confirm by email before receiving newsletters: better list quality and compliance in one setting.

Donation forms show here too

Donation pages appear in the Forms list with a Donation chip, and selecting one previews it right beside the list like any other form. Because they collect card payments through your connected Stripe account, they aren’t edited in the live editor. Edit donation form opens the Donations fundraising builder, where the amount and payment settings live, and their responses arrive as gifts in the Donations ledger rather than a form responses tab.

Try this on sample data.

Every feature in the docs is live in the free demo workspace — no card, nothing to lose.

Start free