In plain terms. You build the form in the dashboard (its fields, its consent text, the list it feeds). Then you either paste a ready-made snippet onto your site, or, if you want full control of the look, render your own form and post to one endpoint. Either way the platform handles the confirmation email, spam protection, and list membership for you.
Which method should I use?
- Just want a form on your page, copy the embed snippet from the dashboard. No code to write.
- Want it to match your design, render your own form and post to the submit endpoint.
- Already collect email somewhere else, use server-side ingest with a secret key.
- Want proof the wallet is really theirs, add the wallet verification handshake.
The fastest path: the dashboard embed
Every form gives you a ready-to-paste HTML snippet (find it on the form in your dashboard). Drop it onto your page and you’re done: it renders the fields, includes spam and bot protection, shows your consent checkbox, and posts to the right place. This is the recommended path for most sites.Submit from your own form
Prefer to build the markup yourself? Post the visitor’s details to the form’s public submit endpoint. The{token} is the form’s public token, shown on the form in your dashboard.
What this does: sends one submission to the form. If the form uses double opt-in, this starts the confirmation email, and the contact joins the list only after they click the link.
email or walletAddress is required, and a form that requires consent rejects a submission without consent: true.
To render your own inputs correctly, fetch the form’s public definition first. A
GET on /api/v1/public/forms/{token} returns the form’s fields, settings, and consent text (and nothing private), so you can build your markup from it.Verify wallet ownership (optional)
A submitted wallet address is self-reported by default. To record it as verified, have the wallet sign a short challenge before you submit. This never blocks a submission: an unsigned wallet is still captured, just marked unverified. What this does: asks the platform for a one-time message, has the wallet sign it, and submits the signature so the platform can confirm the wallet is genuinely the visitor’s.Ingest from your backend
Already have a consented email from elsewhere? Hand it to the same form from your server with a secret key, no browser involved. Use this for imports or server-side capture. What this does: submits to the form as a trusted server-to-server call. The key’s organization must own the form, or the request 404s.The first server-side ingest permanently switches the form into API mode and turns on privacy protection for its captures. See Server-Side API.
What you set on the form (in the dashboard)
You configure a form once, in the dashboard, and every submission path above respects it:After a submission
With double opt-in, a submission is pending until the visitor clicks the confirmation link (single-use, valid 14 days). Only then do tags and list membership apply, and confirmation fires thesegment_entered and form_submitted triggers, so a welcome automation can greet them. Without double opt-in, they join immediately.
The email address is never returned by any read path: you see reachability and consent, not the address itself. Custom fields are capped (up to 20 keys, and any key containing “email” is dropped), so keep them small and purposeful.
