Four things come up often enough in integration questions to be worth stating plainly, so that you do not spend a day searching the reference for an endpoint that is not there. In each case there is something you can do instead.

For what the two APIs do cover, see Which Bookboost API should I use?

There is no endpoint for posting an arbitrary event, such as "viewed the spa page" or "abandoned a booking", and having an automation react to it. Neither API accepts events of your own design.

What to do instead. Build a campaign that uses the external trigger (API) trigger, then call the v1 trigger-campaign endpoint from your own system when the event happens. You decide when to fire it, and Bookboost decides what the message says. In practice this covers most of what people want events for, as long as you are happy owning the timing logic in your own code.

The v1 email and SMS message endpoints send exactly the subject and body you supply. There are no merge fields, no branding, no fallback to another channel if the first one fails, and no WhatsApp.

They are useful for plain, one-off messages where your own system already holds all the text.

What to do instead. For anything designed, personalised, or sent across more than one channel, build it as a campaign and fire it with trigger-campaign. The message then lives in Bookboost, where it can be edited without a code change.

Segments are rule-based groups that Bookboost re-evaluates continuously as guest data changes. They are built in Bookboost and are not exposed on either API, so you cannot create one, read one, or check membership of one programmatically.

Lists, which have explicit membership, are available on both APIs. They are called lists in v1 and profile lists in v3, over the same underlying data.

The rule of thumb. If your system decides who is in the group, use a list through the API. If the data decides, build a segment in Bookboost.

v3 has no consent endpoints. It can create a guest profile and put that profile on a profile list, but it cannot record why you are allowed to contact the person. The same applies to double opt-in and confirmation flows, which are driven entirely by consent state.

This is the gap that catches people mid-build, usually because v3 looked like the newer option and the signup flow was started there.

What to do instead. Record consent through v1. For a signup form on your own website, follow Add subscribers to a list via the API. For how consent is structured more generally, see Collecting marketing consent.

Because a guest has the same ID in both APIs, writing consent through v1 does not stop you reading that guest through v3 afterwards. You do not have to move the whole integration.

If what you need is not covered here and not in the reference, tell us the use case rather than the endpoint you were looking for. Describing what you are building and what triggers it is usually enough for us to point you at a route that already exists, and it tells us something useful when there is not one.

Open Help at the bottom of the left menu and choose Talk to Us, or email support@bookboost.io.