Forms

What are forms?

Forms are embeddable HTML signup widgets you create inside SendBeam and place on your website. When a visitor fills out the form, SendBeam automatically creates a contact and adds them to the list you specify — no server-side code required on your end.

Forms are the primary way most teams grow their email audience organically. You can create as many as you need: one in a blog sidebar for newsletter signups, another on a landing page for a lead magnet, and a third in the site footer as a general subscribe prompt. Each form is independent, with its own fields, protection settings and target list. A form can also be a contact form that emails you the visitor's message instead.

How forms work

The process from visitor to subscriber is fully automatic:

1. A visitor lands on your page and fills in the form fields.
2. SendBeam receives the submission over a secure HTTPS connection.
3. A contact record is created (or updated if the email already exists — new names and custom fields are merged in), and the contact is added to the form's target list.
4. If the list uses double opt-in (or your account is on the Free plan), the membership is held as unconfirmed and a confirmation email is sent automatically.
5. Any active automation with the Form Submitted trigger (or Contact Created, for a new contact) starts for the contact straight away. List Joined automations for the form's list start too — immediately, or once the contact confirms if the list uses double opt-in.
6. The visitor sees your thank-you message or is redirected to the URL you set.

The embed snippet is plain HTML and JavaScript that posts to the form's endpoint. The thank-you message and redirect are returned by SendBeam on each submission, so you can change them without touching your site; if you change the form's fields or enable Turnstile, copy the snippet again.

Views and conversion rate

Every form counts how many times it has been shown to a person, and shows its submissions as a share of that: the Views, Submissions and Conversion columns on the Forms page, the Performance panel on each form's own page, and views, submissions and conversion_rate on each form in the API. Two forms with the same number of signups can be doing very different jobs — one seen by a hundred visitors, the other by ten thousand — and this is what tells them apart.

• What counts as a view. The form rendered for a visitor on its hosted page, in a pop-up, through the WordPress plugin, or where the inline code has been pasted. Search-engine crawlers, link previews and prefetches are left out, and repeated loads from one visitor stop counting after a while, so a page reloaded in a loop does not become a thousand views.
• What counts as a submission. Every submission the form accepts — everyone who filled it in and was shown your thank-you message, whether or not a new contact came of it. Attempts the automated-submission checks drop are not counted, so they cannot bury your rate.
• The rate. Submissions divided by views, shown once the form has been seen at least once. A form you submit through the API rather than by showing it to people has submissions with no views, so its rate can read over 100%.
• Since when. Both counts started the day this was introduced; earlier submissions are not counted, so the two numbers always cover the same period.

Testing a second version

Once a form has views, you can try a second version against it. On the form's page, under Second version, write what B should say instead — a different headline, line of copy, button label, thank-you message or button colour, any or all of them — and start the test. From then on, half of the people who see the form on its hosted page, in the pop-up or through the WordPress plugin see version B, picked at random on each view, and each version's views and submissions are counted on their own.

• The fields never change. A version can change the words and the look, not what is collected, so every submission lands on the contact the same way.
• No cookie. The choice is made fresh on every view, so someone who reloads may see the other version. Nothing is set on the visitor's browser.
• Inline embeds show A. The pasted snippet is plain HTML on your site and cannot switch; its views and submissions count towards version A.
• You decide. The page shows which version is converting better and tells you when each has been seen enough times for that to mean something. Use B makes B's words the form's own; Keep A ends the test with everything as it was. Nothing is switched automatically.
• From the API. ab_test on the form: send { "status": "testing", "b": { … } } to start, { "status": "decided", "winner": "b" } to decide, null to clear. versions carries each version's views, submissions and rate.

Spam protection

Every SendBeam form includes built-in protections so you do not need to configure anything extra to keep bots out:

• Automated-submission checks — a post that carries the signs of a script rather than a person is silently discarded. They are always on and need nothing from you.
• Rate limiting — submissions are limited per visitor and capped per form per day. The caps are shown, and adjustable, on the form's settings page.
• Email format validation — malformed addresses are rejected at submission time with a clear error.

Forms vs other signup methods

Forms are not the only way to add contacts to SendBeam. Here is when to use each approach:

• Embedded forms — best for organic, self-service signups directly from your website.
• CSV import — best for bulk-loading an existing list you have collected elsewhere.
• Manual add — best for adding individual contacts one at a time.
• API — best for programmatic signups from a custom form, checkout flow, or application.

Contact forms

Not every form is a signup. Set a form's type to Contact and SendBeam does the opposite job: the visitor's message is emailed to you, sent from your verified sending address with the visitor as Reply-To, so you answer by hitting reply.

• No contact is created. Someone reporting a bug has not asked for your newsletter. Contact forms never touch your contacts, lists or automations.
• Same spam protection as signup forms, applied automatically.
• Honest failures. If the notification cannot be sent, the visitor gets an error instead of a false "sent", so your site can fall back to a plain mailto: link.
• Fields: email and message are required; name and subject are optional. Any extra field you declare on the form is included in the email.

Signup forms can use the same notification: set Email me about new subscribers to get a short email each time someone joins. Notifications appear in the Log tab under Reports.

Protecting public forms

The public endpoint has no API key, on purpose: anything in a web page is visible to every visitor. Instead, every form is protected against automated submissions, rate-limited per visitor and capped per form per day; the caps are shown, and adjustable, on the form's settings page. For forms on busy or public sites, the form's Protection section adds two more layers:

• Allowed sites. List the origins the form lives on (for example https://www.example.com). Browsers cannot forge their origin, so this stops the form being embedded or driven from anywhere else. A hand-written script can still fake it, which is what the next layer is for.
• Cloudflare Turnstile. Cloudflare's free, mostly invisible bot check. Create a widget in your Cloudflare dashboard, paste the site key and secret key into the form, and the embed code adds the widget automatically. Every submission must then carry a valid token; SendBeam verifies it with Cloudflare before doing anything else.