A sign-up form on your own website can write straight into a Bookboost list, so a newsletter subscriber is on your list and consented the moment they submit the form, with nobody copying addresses across by hand. This is done through the Bookboost API, which means your web developer does the work on the website side. What you do in Bookboost is create the consent and the list, build the campaigns that greet the subscriber, then hand over three values.
Set up the consent and the list first
Both have to exist in Bookboost before the form can write to them. Create a consent for the newsletter, and create the list the subscribers will land in.
Two settings on the consent change behaviour rather than wording, and they decide what the subscriber receives:
Require Confirmation is double opt-in. With it on, a new sign-up arrives at pending and stays there until the subscriber clicks a confirmation link. With it off, it goes straight to granted.
Auto-grant decides whether the consent is given automatically rather than asked for. Leave it off for a website form, where the subscriber is actively agreeing.
A consent has no channel. There is no built-in split between email permission and SMS permission, so if you treat those separately, create two consents and your developer sends one request per consent. The same applies to different purposes: one consent per purpose, not one per campaign. See Set up and apply consent options.
You also need an API client integration set up on your account. Without one, the UUIDs are not shown anywhere in the platform.
The three values your developer needs
Consent UUID. Go to Settings and then Consent Form, select the consent, and take the UUID at the bottom.
List UUID. Go to Profiles and then Lists. The UUID is in the last column.
Access token. Go to Settings and then Access Tokens. If you cannot see that page, it has not been enabled on your account. Email support@bookboost.io and we will enable it.
Ask for the key early. Keys are generated by Bookboost support rather than by you, so this is the step most likely to hold up a go-live date. See API keys.
The access token is a credential. Send it to your developer the way you would send a password, and do not put it anywhere public. It must never appear in your website's front-end code, where anyone viewing the page could read it and write into your guest database.
Set up the campaigns that greet the subscriber
Nothing is sent by your website. The consent's configuration decides what happens, and campaigns on the Journey board do the sending. Go to Campaigns and then Journey, add a campaign, and set its trigger in the first step of the editor. These triggers exist only on Journey campaigns, not on Broadcasts.
Campaign | Trigger to select | Must contain |
Confirm your subscription, only with Require Confirmation on | After double opt-in was requested | The Confirmation URL token |
Welcome, double opt-in | After double opt-in was confirmed | - |
Welcome, single opt-in | After consent was granted | - |
The Confirmation URL token is the click-to-confirm link. Selecting it inserts {{user_consent.double_optin_url}}, which Bookboost replaces with that subscriber's own link when the message sends. If the token is missing, the subscriber receives an email with nothing to click and stays at pending indefinitely, so send yourself a real test and click the link before going live.
At the Review & Publish step, set which consent each campaign requires, then publish it. An unpublished campaign is skipped without an error. On the Journey board, DRAFT means it was never published and UNPUBLISHED CHANGES means it was edited afterwards, so those edits are not live.
The request your developer makes
The endpoint is documented in the Bookboost API reference. The request carries the access token for authentication, the list UUID, the consent UUID, and the guest's details from the form.
For the request itself, the fields it accepts, and what each response code means, send your developer to Connecting your website signup form to Bookboost.
Decide with your developer which fields the form captures. Name and email address are the usual minimum. Whatever you collect has to be covered by the consent wording the subscriber agrees to. Ask them to send the subscriber's language, because it decides which language version of your campaigns they receive and it is hard to correct afterwards.
What this does not do
It does not build the form for you. The form itself lives on your website and is built by whoever maintains it. Bookboost receives what it sends.
It does not create the consent or the list. Both have to exist in Bookboost first, and the request fails if the UUIDs do not match a real consent and a real list.
It does not show you the UUIDs without an API client integration. If the UUID column or field is not there, that integration is missing rather than the data.
It does not send anything on its own. A sign-up that records consent but has no published campaign on the matching trigger produces no email at all, and nothing reports the failure.
It does not make your form compliant. The consent wording your subscriber agrees to on the website is yours to write, and it has to match what you actually do with the data.
What to do next
Once the form is live, submit it yourself with a real address and check that the profile appears in Profiles, on the right list, with the consent recorded. A form that posts successfully but writes to the wrong list looks identical from the website side.
Connecting your website signup form to Bookboost, the request your developer makes and what each response means.
Adding existing guests to a list and sending campaigns from your own site, for migrating an existing subscriber list or sending a campaign from your own code.
Why a website signup or confirmation email is not working, when something does not arrive.
Getting help
Open Help at the bottom of the left menu and choose Talk to Us, or email support@bookboost.io.