Embedding Guide

Pre-Selecting a Service

Use data-service-id to skip the service selection step entirely. Pair with data-promo-title and data-promo-description on promo landing pages to include promo context in webhook payloads:

data-promo-code is a separate, unrelated attribute — it carries a campaign attribution code, while data-promo-title and data-promo-description control the promo banner. Where each one ends up is described below.

data-promo-code is also written into the Zenoti appointment as a Code (from link): line on the booking note, and onto the guest's Zenoti profile — the label marks the wording as arriving with the visit rather than coming from BookerKit. data-promo-title pre-selects a promotion for the guest: if the title exactly matches one in your Widget Settings promo list it becomes the Promo: line on both notes (BookerKit sends its own copy of your title, never the attribute text), and if it matches nothing on that list it changes the banner only. See what BookerKit writes to your Zenoti appointments for the full note.

Do not put guest-identifying information — names, phone numbers, email addresses, or dates of birth — in data-promo-code. It accepts letters, numbers, and . _ - up to 100 characters. On top of that format check, BookerKit drops any value holding an @ or a run of seven or more digits — counting through spaces, dots, hyphens, parentheses and underscores, so 5558675309, 555-867-5309, (555) 867-5309 and 555_867_5309 are all rejected. Slashes are not counted, so a date written 09/21/2026 is not caught by this rule. A rejected value never reaches the guest record, your webhook payloads or Zenoti. That is a safety net for the two shapes a CRM merge tag usually renders, not a guarantee: the value is not read for a name, an address, or anything else personal. Whatever does get through reaches three places — the guest record, your webhook payloads, and the note on the Zenoti appointment and guest profile — so a value that turns out to hold personal data has to be cleaned up in all of them. Take particular care if your landing page fills the attribute from a CRM merge tag — the value also travels in the widget's iframe URL, so even a value that gets rejected before it reaches the guest record or a webhook can still appear in ordinary server access logs.

promoCode and offerCode are different fields and can both appear in the same booking_completed payload. offerCode is typed by the guest during booking when the offer-code field is enabled in widget settings; promoCode is set by you on the embed and is also saved to the guest record. Map them separately in your CRM.

<!-- Promo landing page with pre-selected service -->
<div data-bookerkit-widget="your-account"
     data-mode="button"
     data-button-text="Claim Offer"
     data-service-id="your-service-uuid"
     data-promo-title="dysport-guest"
     data-promo-description="$4/unit">
</div>

Form-Only Lead Capture

Add data-form-only="true" to reduce the widget to a lead-capture form: the guest enters their details, verifies by text or email, and lands on a short success screen. There is no service, provider, date/time, or booking step, and no appointment is created. The submission still matches or creates a guest record in your connected system, exactly as the booking flow does — no appointment is booked, but the person is recorded.

data-sheet-title and data-sheet-description still customize the header, including on the success screen. Leave them off and the header uses lead-capture wording instead of the booking wording.

A form-only embed always shows your business name in the header, whether or not data-show-location-name is set, so the guest can see who is collecting their details before they type them. If you bypass the embed script and hand-write the iframe URL with headerless=true, the header and that name go with it — in that case make sure the surrounding page identifies your business, because otherwise the name first appears on the success screen, after the details have been submitted.

data-service-id, data-service-category, and data-promo-code have no routing effect in form-only mode — there is no step for them to skip — but they keep their tracking role and still appear in the webhook payload.

The booking_started webhook fires when the guest submits their details, before verification completes. That timing is deliberate: if the guest abandons the verification code, you still receive the lead.

That payload carries "mode": "form_only", where the booking flow sends "mode": "booking". Both events always include the key, so a CRM automation can branch on it — without it, a lead and a real about-to-book guest are indistinguishable and appointment reminders fire for people with no appointment.

If your widget requires marketing consent, form-only still asks for it but does not require it to submit — there is nothing being purchased in this mode, so agreeing to marketing texts is not made the price of getting in touch. A ticked box is recorded as consent. An untouched one records nothing at all, rather than a "no" — on a gated booking a stored answer is always a deliberate act, but here it would only be silence, and a stored "no" would hide the checkbox from that guest on every future widget for your account and keep them out of your Zenoti campaigns.

A form-only submission leaves BookerKit through three independent sinks, so turning one off does not turn off the others:

• the booking_started webhook to your CRM, controlled by the booking-start webhook toggle in widget settings;
• the staff notification email, carrying the guest's name, email, phone and a link to their profile — controlled by its own separate booking-start email toggle;
• the bookerkit_booking_started event pushed to your page's dataLayer, which carries the guest's email and reaches whatever tags and pixels the host page loads. This is not governed by either widget toggle — it is controlled by what you install on the page.

With all of them off the lead is still recorded in BookerKit and visible in your dashboard.

data-cc-auth-form — and a card-capture link's token — take precedence over data-form-only. The card flows render before the form-only branch is consulted, so combining them runs the card flow.

<!-- Lead-capture form, no booking -->
<div data-bookerkit-widget="your-account"
     data-form-only="true"
     data-sheet-title="Request a Consultation"
     data-sheet-description="Tell us how to reach you">
</div>