OverviewGetting StartedWidget SettingsEmbedding GuideAnalytics & TrackingTroubleshootingBest PracticesGlossaryZenoti API

Search Documentation

Find sections across all documentation pages

Glossary

A plain-English definition of every term BookerKit uses — in the dashboard, in the widget, and in your webhook payloads. Where two similar-sounding terms mean different things, each one says so explicitly.

Accounts & Structure

How BookerKit is organized: the organization that groups locations, the account that is a location, the one widget it owns, and the Zenoti center behind it.

Account

One physical location, and the core unit everything else hangs off: its own guests, its own widget, its own billing, and its own Zenoti connection. Every record in BookerKit is scoped to an account, so one location cannot see another location's guest list. People get dashboard access to an account through a role.

Where you'll see it: The account switcher in the sidebar; Settings → Account

Not to be confused with

  • Organization — An organization groups several accounts; the account is the single location that takes the bookings.
  • Location — Location is simply the guest-facing word for the same record.
  • Zenoti Center — The Zenoti center is Zenoti's record of the location; the account is BookerKit's, and they are always one-to-one.
  • Display Name — The account name is the internal name; the display name is the cleaned-up version guests see.

Display Name

An optional guest-facing override for an account name. Internal names often carry a franchise prefix such as "FFA - Avon" while guests should only see "Avon". Leave it blank and the real account name is used. Analytics, webhooks, and internal admin views always use the real name, never the display name.

Where you'll see it: Settings → Account → Display Name; the widget header and confirmation screens

Not to be confused with

  • Account — The account name is what staff and reporting see; the display name only changes what guests see.

Location

The guest-facing word for an account — the same record, a different vocabulary. Settings, billing, and team management talk about the account; anything a guest chooses between talks about locations.

Where you'll see it: The location picker; the widget header; organization-level screens

Not to be confused with

  • Account — Same thing. Account is the internal word, location is the guest-facing one.
  • Location picker — The location is the place; the location picker is the screen where a guest chooses one.

Organization

An optional grouping of several accounts under one brand, so that a single embed can offer guests a choice of location. An organization has no Zenoti connection and no billing of its own — those live on each account underneath it. A single-location business never needs one.

Where you'll see it: The location picker on a multi-location embed; organization settings

Not to be confused with

  • Account — The account is the location that actually takes bookings; the organization only groups accounts together.
  • Widget — Each account has its own widget; the organization only owns the styling of the location-picker screen in front of them.

Role (Owner / Admin / Member)

Also called:OwnerAdminMember

The three levels of dashboard access, set per account. Only an Owner can remove users, change roles, or transfer ownership, and each account has exactly one Owner who cannot be removed; an Admin can invite and manage Admins and Members but cannot promote or demote the Owner; a Member gets standard dashboard access with no team management. Roles are per account, so the same person can be an Owner at one location and a Member at another.

Where you'll see it: Settings → Team

Not to be confused with

  • Super Admin — A role is granted by you, inside one account; super admin is a BookerKit-staff flag that spans the whole platform.

Super Admin

A BookerKit staff flag that applies platform-wide — it is not a role you can assign inside your account. It grants owner-level access to every account plus the internal admin panel. When BookerKit staff open an account they are not a member of, that visit is written to a HIPAA audit log.

Where you'll see it: Not visible in your settings — this is BookerKit staff only

Not to be confused with

Widget

The booking experience belonging to one account — its styling, policies, feature toggles, and notification settings. An account has exactly one widget, and a second one cannot be created for the same location. Individual pages of your site can still behave differently by overriding settings on the embed itself.

Where you'll see it: Dashboard → Widget (Settings, Code, Demo)

Not to be confused with

  • Organization — A widget belongs to one account and one location; an organization spans several of them.
  • Embed code — The widget is the configuration in your dashboard; the embed code is the snippet that puts it on your site.

Zenoti API Key

The per-account secret that lets BookerKit talk to Zenoti on your behalf, used together with the center ID on every call. It is stored server-side only and is never exposed to the browser or to your embed code. Each account stores its own key value, though multi-location organizations often reuse a single Zenoti org key across their accounts. An automated daily check watches key health and alerts BookerKit if a key expires or goes missing.

Where you'll see it: Settings → Account → Zenoti API Key

Not to be confused with

  • Zenoti Center — The center ID names the location; the key is the credential that proves BookerKit may act on it.

Zenoti Center

Zenoti's own identifier for one business location. A BookerKit account holds exactly one Zenoti center ID — no account spans two centers. If you run several locations, each one is its own account with its own center ID.

Where you'll see it: Settings → Account → Zenoti Center ID

Not to be confused with

  • Account — The account is BookerKit's side of the pairing; the center is Zenoti's.
  • Zenoti API Key — The center ID says which location; the API key is the secret that authorizes calls about it.

Guests & Identity

Who a guest is, how BookerKit and Zenoti each identify them, and what the badges on the guests table are actually telling you.

Guest

A person who booked, or started booking, through one med spa's widget. Guest records are scoped to a single account, so the same person visiting two BookerKit med spas becomes two separate guest records that are never linked. One clinic's client list is invisible to another.

Where you'll see it: Dashboard → Guests table and guest profile pages

Not to be confused with

  • Zenoti Guest — The Zenoti guest is the record in your EMR; one Zenoti guest can map to several BookerKit guests, one per account.
  • Booking session — A guest is a person; a booking session is one visit to the widget, and one guest can have many.

Guest identity restore

The name, email, and phone BookerKit already holds for a returning guest. When their browser still remembers a recent verification, the widget fills those details back in instead of asking for a new code. If there is no usable name on file, the Personal Information step appears once more — but they are still not asked to verify again.

Where you'll see it: Step 1 of the booking flow, for returning guests

Not to be confused with

  • Verification session — The verification session is the browser-side proof that permits the restore; the identity is the name, email, and phone it brings back.

Has Booked

An all-time yes or no: has this guest ever completed a booking through the widget, across every session they have had. It never resets. A guest with an old completed booking and a newer abandoned visit shows Has Booked = Yes while their most recent session still reads Incomplete.

Where you'll see it: Dashboard → Guests table column and filter

Not to be confused with

  • Recent Session status — Has Booked looks at their entire history; the session status looks only at their latest visit.

New guest vs. Existing guest

Also called:is_new_guestNewExisting

A badge showing whether Zenoti already had a record for this person the first time BookerKit synced them. "New" means Zenoti had no match at that moment; "Existing" means Zenoti already knew them, which reflects recognition across your whole Zenoti organization, not just the location they booked. It is set once, permanently, at that first sync — it never changes on later visits.

Where you'll see it: Dashboard → Guests table, beside the guest name

Not to be confused with

  • Verification (email vs. SMS) — Existing means Zenoti already knew them; verification is proof they control that email or phone right now.
  • Recent Session status — This badge is fixed for life at first sync; the session status changes with every visit.

Zenoti Guest

Also called:zenoti_guest_id

Zenoti's own identifier for a person, shared across all of your centers. Because BookerKit keeps guests per account, one Zenoti guest maps to many BookerKit guest records — one for each account they have booked at. A BookerKit guest ID never identifies someone across accounts, so do not use it to match people between locations.

Where you'll see it: Guest profile pages; webhook payloads

Not to be confused with

  • Guest — The BookerKit guest is per location; the Zenoti guest is the single person behind all of them.

Consent & Verification

The two kinds of consent a guest gives, the terms checkbox that is neither, and the machinery that proves a guest is who they say they are.

Booking token

A signed, server-issued proof that this browser has just proved it belongs to this guest at this med spa. Nearly every action taken on a guest's behalf — recording consent, saving their details, linking their session — requires it, so a guest ID on its own can never be used to impersonate someone. It expires 15 minutes after it is issued.

Where you'll see it: Invisible to guests — issued the moment they finish verifying

Not to be confused with

  • Verification session — The booking token is the cryptographic proof and lasts 15 minutes; the verification session is the browser wrapper around it and lasts about 30.

Also called:marketing_consentRequire Marketing Consentmarketing opt-in

Permission to send promotional messages, kept entirely separate from appointment messages. It is a per-widget toggle: switch it off and the checkbox never appears and nothing is recorded. Switch it on and any guest without an answer already on file must tick it to continue — so BookerKit only ever stores a yes, never an explicit "no", and a guest who previously declined is never re-asked. It normally appears on the code-entry screen; a returning guest who skips verification is asked on the personal-info step instead.

Where you'll see it: Widget Settings → Features & Requirements (Require Marketing Consent) and Widget Settings → Consent Text (Marketing Consent Text); the verification screen in the booking flow

Not to be confused with

  • Transactional consent — Marketing consent is a toggle you control — off means it is never asked; transactional consent is always asked and always required.

OTP (one-time passcode)

The single-use 6-digit code sent by text or email to prove the guest controls that phone number or address. It expires after a short window and can be resent if it does not arrive.

Where you'll see it: Step 1 of the booking flow, after personal details

Not to be confused with

Terms accepted

Also called:termsAccepted

A separate checkbox on the final booking screen confirming the guest agreed to your terms of service and privacy policy. It sits right next to the transactional-consent checkbox but is a different thing, and it is not stored as a consent field on the guest record.

Where you'll see it: Step 4 of the booking flow

Not to be confused with

  • Transactional consent — Transactional consent is recorded on the guest as messaging permission; terms accepted is agreement to your policies.

Also called:transactional_consent

Permission to send appointment-related messages such as reminders and confirmations. It cannot be turned off by the clinic and cannot be skipped by the guest — a booking cannot be completed without it. It is captured on the final date-and-time screen, immediately before the appointment is confirmed. Only its wording is configurable.

Where you'll see it: Step 4 of the booking flow; wording at Widget Settings → Consent Text

Not to be confused with

  • Marketing consent — Marketing consent is a toggle you control — off means it is never asked; transactional consent is always asked and always required.
  • Terms accepted — Terms accepted covers your terms of service and privacy policy; it sits on the same screen but is not stored as consent on the guest record.

Verification (email vs. SMS)

Proving a guest actually controls the email address or phone number they entered, by having them type a 6-digit code. Every new guest must verify — it cannot be skipped. You choose the channel: SMS is the stronger defence against made-up contact details, email is the fallback for landlines and VoIP numbers. A returning guest whose browser still holds a valid verification session skips the screen entirely.

Where you'll see it: Step 1 of the booking flow; Widget Settings → Features & Requirements → Verification Method

Not to be confused with

  • OTP (one-time passcode) — Verification is the step; the OTP is the code used to get through it.
  • Verification session — Verification is the act of entering a code; the verification session is the browser record that lets them skip it next time.
  • New guest vs. Existing guest — Verification proves control of a contact detail today; new versus existing only says whether Zenoti had already heard of them.

Verification session

Also called:bookerkit_vsession

A short-lived "remember me" record kept in the guest's own browser saying that this browser already verified this exact email or phone. It lasts about 30 minutes, and it is what lets a returning guest reopen the widget already signed in. Clearing the browser, switching device, or changing the email or phone sends them back through verification.

Where you'll see it: Invisible to guests — it is the reason a returning guest skips the code screen

Not to be confused with

  • Booking token — The verification session is the browser-side wrapper; the booking token is the signed proof inside it that the server actually checks.
  • Booking session — A verification session proves identity across visits; a booking session is the record of one single visit.
  • Verification (email vs. SMS) — Verification is entering the code; the session is what remembers that they already did.
  • Guest identity restore — The session is the permission; the identity restore is the name, email, and phone it brings back.

Booking Flow

The screens a guest moves through, the Zenoti catalog behind them, and the records created along the way.

Add-on

An optional extra attached to a main service, with its own name, price, and duration. Add-ons appear only when Show Add-Ons is on and the chosen service actually has add-ons defined in Zenoti.

Where you'll see it: Step 2 of the booking flow, after a service is chosen

Not to be confused with

  • Service — An add-on cannot be booked on its own; it always attaches to a service.

Availability

Day-level information about which days have any opening, used to grey out full days on the calendar. Zenoti's day-availability answer only covers the current calendar week, so later weeks are checked as the guest navigates into them. A day is greyed out only on a positive confirmation that it is full — when there is no answer, the day stays clickable.

Where you'll see it: The calendar in Step 4 of the booking flow

Not to be confused with

  • Slot — Availability tells you whether a day is worth opening; slots are the actual times inside it.

Booking / Appointment

The appointment itself, held in Zenoti. Creating one is a two-step process: BookerKit first creates a draft booking, then confirms it. Until it is confirmed it remains a draft and does not appear on the centre schedule.

Where you'll see it: Zenoti's calendar; the guest's confirmation screen

Not to be confused with

  • Booking session — A session can exist with no appointment at all; the appointment only exists once a booking is confirmed.
  • booking_completed — The appointment is the record in Zenoti; booking_completed is the event BookerKit fires once it is confirmed.

Booking session

Also called:session_id

The record of one visit to the widget. It is created the moment the widget renders — before the guest has typed anything — and is linked to a guest once they verify in Step 1. It is the anchor for analytics events, webhooks, and recovery, and nearly every dashboard number is counted per session rather than per person. A session ID is globally unique, never reused between accounts.

Where you'll see it: Dashboard → Analytics; the activity timeline on a guest profile

Not to be confused with

  • Verification session — A booking session is one visit through the funnel; a verification session is the identity proof that carries across visits.
  • Guest — The guest is the person; the session is one of possibly many visits by that person.
  • Booking Starts — Every visit creates a session; Booking Starts only counts the sessions that showed real engagement.
  • The four booking steps — The steps are the screens inside a visit; the session is the record of that visit.
  • Booking / Appointment — The session is the visit; the appointment is the confirmed result of it in Zenoti.

Category

The top-level Zenoti grouping a service belongs to, such as "Injectables" or "Hair Services". It is the first screen of service selection, and its contents come straight from your Zenoti catalog.

Where you'll see it: Step 2 of the booking flow

Not to be confused with

  • Subcategory — The category is the top level; a subcategory is an optional second level beneath it.
  • Service — The category is the grouping; the service is the individual thing that gets booked.
  • Data attributes — The data-service-category attribute is a different thing entirely — free text used only for tracking labels, not the Zenoti taxonomy the guest picks from.

Invoice

Zenoti's record of what the guest owes for the appointment. It is generated once the time slot is reserved, and it is the figure the deposit is measured against.

Where you'll see it: Zenoti; behind the scenes whenever a deposit is charged

Not to be confused with

  • Deposit — The invoice is the full amount owed; the deposit is the portion charged up front at booking time.

Provider

The staff member who performs the service — injector, aesthetician, stylist, whatever your team calls them. The "Any Available Provider" option books the soonest opening regardless of who performs it. The provider step is shown only when Show Providers is on.

Where you'll see it: Step 3 of the booking flow

Not to be confused with

  • Therapist — Therapist is simply Zenoti's word for the same person and the same record.

Service

A bookable offering pulled live from your Zenoti catalog, carrying its price, duration, category and subcategory, and any add-ons or prerequisites. Only services Zenoti has flagged as online-bookable appear in the widget. Nothing about a service is edited in BookerKit — the catalog belongs to Zenoti.

Where you'll see it: Step 2 of the booking flow

Not to be confused with

  • Category — A service is one bookable offering; a category is the Zenoti grouping it sits inside.
  • Add-on — The service is the main appointment; an add-on is an optional extra attached to it.

Slot

A single bookable start time returned live from Zenoti for the chosen service and provider. Slots are fetched at the moment the guest opens a day, so what they see is current availability rather than a cached schedule.

Where you'll see it: Step 4 of the booking flow, beneath the calendar

Not to be confused with

  • Availability — Availability is day-level — which days have any opening at all; a slot is one specific time inside a day.

Subcategory

An optional second level of grouping underneath a category. The subcategory screen appears only when the category has more than one subcategory and Show Subcategory Navigation is on; a lone subcategory is skipped automatically so guests never see a one-option screen.

Where you'll see it: Step 2 of the booking flow; Widget Settings → Features & Requirements → Show Subcategory Navigation

Not to be confused with

  • Category — A subcategory always lives inside a category; the category screen comes first.

The four booking steps

The widget flow: Step 1 Personal Information (name, email, phone, and verification), Step 2 Service Selection (category, then subcategory, service, and add-ons), Step 3 Provider Selection, and Step 4 Date & Time (calendar, time slot, deposit or card, confirm). Step 3 only appears when Show Providers is switched on, so for most accounts it is effectively a three-step flow.

Where you'll see it: The progress indicator at the top of the widget

Not to be confused with

  • Booking session — Steps are the screens a guest moves through; the booking session is the single record of that whole visit.

Therapist

Zenoti's word for a provider. It is the same person and the same record — BookerKit's screens say provider, Zenoti's screens and API say therapist. Nothing about the booking changes between the two vocabularies.

Where you'll see it: Zenoti's own screens and API responses

Not to be confused with

  • Provider — Same thing, two vocabularies: provider is the BookerKit word, therapist is the Zenoti word.

Embedding

How the widget gets onto your website: the snippet, the script, the three ways it can open, and the per-page overrides.

Allowed origins

The list of domains your widget is permitted to run on. It is required — an empty list hard-disables serving, so the widget will not load anywhere at all. Each entry can be a bare domain (which covers that domain and all its subdomains), a *.wildcard entry (subdomains only), or a full origin URL. The same list also governs which parent page the widget will accept close and resize messages from.

Where you'll see it: Widget Settings → Allowed Embed Origins

Button trigger

Also called:data-mode="button"

An embed mode that renders a styled button in place of the widget. The widget only loads when someone clicks it, then slides open in a side panel — useful on pages where booking is secondary to the content.

Where you'll see it: data-mode="button" on your embed container

Not to be confused with

  • iframe embed — A button trigger defers all loading until the click; an iframe embed loads with the page.
  • Custom trigger element — A button trigger uses BookerKit's own button; a custom trigger element uses your own HTML instead.
  • CTA text — The CTA text setting supplies the default label printed on that button.

Custom trigger element

Also called:Expert Mode

Put your own clickable element inside the widget container and the script detects it and uses it as the trigger instead of drawing its own button. You keep complete control of the styling while the opening behaviour stays the same.

Where you'll see it: Your embed container, in place of the default button

Not to be confused with

  • Button trigger — A button trigger draws the button for you; a custom trigger element is markup you supply.
  • iframe embed — A custom trigger element still opens on click; an iframe embed is already open.

Data attributes

Also called:data-*

Per-embed settings added to the container div that override your widget defaults on that one page — colours, button text, iframe height, header text, and which service is preselected. They let one widget behave differently on different pages without touching your dashboard settings.

Where you'll see it: Your embed container div; the reference table in Docs → Embedding

Not to be confused with

  • Category — data-service-category is free text used only for tracking labels — it is not the Zenoti category a guest picks from.
  • data-service-id — data-service-id is one specific data attribute, the one that preselects a service.
  • data-promo-code — data-promo-code is the one data attribute that gets stored on the guest record rather than only changing the display.

data-promo-code

An attribution code saved onto the guest's record and passed along in webhooks, so you can tell which offer produced a booking. It is not the same as data-promo-title and data-promo-description, which only change the banner text shown inside the widget. Never put guest-identifying information into a promo code — it is stored and forwarded.

Where you'll see it: Your embed container div; webhook payloads

Not to be confused with

  • Data attributes — The other data attributes only affect display; this one is recorded as attribution data.

data-service-id

The attribute that preselects one Zenoti service for that embed and skips the service-selection step entirely. Use it on a service-specific landing page so the guest goes straight from their details to picking a time.

Where you'll see it: Your embed container div

Not to be confused with

  • Data attributes — This is one member of the wider set of per-embed data attributes.

Embed code

The copy-and-paste snippet that puts the widget on your website: a container div marked with data-bookerkit-widget, plus a script tag pointing at embed.js. You generate it in the dashboard and paste it wherever the widget should appear.

Where you'll see it: Dashboard → Widget → Code

Not to be confused with

  • embed.js — The embed code is what you paste; embed.js is the script that code loads.
  • Widget — The widget is the configuration in your dashboard; the embed code is how it reaches your site.

embed.js

Also called:embed.js

The single hosted script file that reads your container's data attributes and builds the widget, either inline or behind a button. One script tag serves any number of widget containers on the same page, so you never need to include it twice.

Where you'll see it: The script tag inside your embed code

Not to be confused with

  • Embed code — embed.js is hosted by BookerKit and always the same; the embed code is the snippet unique to your account.

iframe embed

Also called:data-mode="iframe"

The default embed mode: the full widget loads inline on the page straight away. It is the right choice for a dedicated booking page and for CMS platforms that dislike overlays.

Where you'll see it: data-mode="iframe" on your embed container

Not to be confused with

  • Button trigger — An iframe embed loads immediately; a button trigger loads nothing until someone clicks.
  • Custom trigger element — An iframe embed shows the widget on page load; a custom trigger element still waits for a click.

Location picker

The screen a guest sees when one embed serves several locations in an organization: they pick, or search for, a location before the widget loads. The choice is remembered in their browser for next time. It is styled from the organization's own settings, so per-widget appearance settings, including fonts, cannot reach this screen.

Where you'll see it: The first screen of a multi-location embed

Not to be confused with

  • Location — The location is the place being chosen; the picker is the screen that does the choosing.

Appearance & Policies

The settings that make the widget look like your brand, and the money rules that govern deposits, cancellations, and cards on file.

Border radius

How rounded the widget corners and buttons are, anywhere from 0 (fully square) to 32 pixels. Match it to the buttons already on your site and the widget stops reading as a third-party tool.

Where you'll see it: Widget Settings → Appearance

Cancellation policy

Three settings that govern late changes: a cancellation fee, the hours of advance notice a guest must give to cancel without incurring it, and a late-arrival grace period. All three are disclosure only — BookerKit prints them in the terms the guest agrees to at booking, but it does not track cancellations or charge the fee itself; you collect that in Zenoti. The cancellation fee requires that you also require a payment method, and a $0 fee is left out of the disclosure entirely. There is no separate no-show setting — no-shows are covered by the same fee line and by having a card on file.

Where you'll see it: Widget Settings → Booking Policies

Not to be confused with

  • Deposit — A deposit is money BookerKit actually charges at booking; the cancellation fee is only disclosed to the guest — collecting it happens in Zenoti.

Also called:save-card link

A one-time expiring link — 72 hours by default — that opens the widget in card-on-file mode only, with no service browsing at all. It carries nothing but an opaque hashed token, never any guest details, and it runs on your own embedded domain rather than a BookerKit URL. Deleting the link revokes it: the stored token is destroyed, so any copy already sent stops working immediately.

Where you'll see it: A guest profile page, where you generate and send it

Not to be confused with

  • Deposit — A card capture link saves a card without charging anything; a deposit is an actual charge taken during booking.

CTA text

The label on the main call-to-action button, "Book Appointment" by default. The same text is also used as the default label for a button-trigger embed.

Where you'll see it: Widget Settings → Appearance

Not to be confused with

  • Button trigger — CTA text is the wording; the button trigger is the embed mode that displays a button at all.

Deposit

An amount charged to the guest's card at the moment of booking and applied toward the final cost of the visit. It depends on the Require Payment Method setting — turn that off and deposits stop being collected. If the Zenoti invoice comes to less than the deposit, BookerKit sells a Zenoti gift card for the shortfall and charges that, rather than overcharging the guest.

Where you'll see it: Widget Settings → Advanced Deposit, gated by Require Payment Method under Features & Requirements

Not to be confused with

  • Cancellation policy — The deposit is money BookerKit actually charges at booking; the cancellation fee is only disclosed to the guest — collecting it happens in Zenoti.
  • Gift card — A deposit shortfall is covered by an internal Zenoti gift card, which has nothing to do with the Gift Card URL link in the widget header.
  • Invoice — The invoice is the full amount owed in Zenoti; the deposit is the slice taken at booking.
  • Deposit events — The deposit is the setting and the charge; the deposit events are the records written when it succeeds, fails, or is still in flight.
  • Card capture link — A deposit charges a card during booking; a card capture link only stores one for later.

Font scale

A relative size multiplier applied on top of whichever fonts you chose — body text from 0.9 to 1.2, headings up to 1.5. It exists because some typefaces render optically small or large at the same nominal size. It never changes which font is used.

Where you'll see it: Widget Settings → Appearance

Not to be confused with

  • Heading & body font — Font scale is size only; the font pickers are what choose the typeface.

Gift card

Two different things share this name in BookerKit. The customer-facing one is the Gift Card URL setting, which adds a link in the widget header pointing at your own gift-card purchase page. The internal one is the deposit shortfall mechanism: when a deposit is larger than the invoice, BookerKit mints a Zenoti gift card for the difference and charges that instead — a mechanism the guest never sees.

Where you'll see it: Widget Settings → Links & Promotions (Gift Card URL); the link in the widget header

Not to be confused with

  • Deposit — The internal gift card only exists to cover a deposit larger than the invoice; the header link is unrelated marketing.

Heading & body font

Two independent Google Font pickers — one for headings, one for body text — chosen from a curated, searchable catalog. Only fonts on that allowlist are accepted; an arbitrary font name is rejected before it is ever saved.

Where you'll see it: Widget Settings → Appearance

Not to be confused with

  • Font scale — The font setting picks the typeface; the font scale only changes its size.

Primary color

Your brand colour, applied to buttons and interactive elements throughout the widget. It is the single setting that does most of the work of making the widget look like part of your own site.

Where you'll see it: Widget Settings → Appearance

Analytics & Tracking

The numbers on your dashboard, the events sent to ad platforms and webhooks, and the attribution data that travels with them.

bookerkit_booking_started (dataLayer event)

Also called:bookerkit_booking_started

A dataLayer event fired when a visitor completes the personal-information step. It is the earliest strong intent signal worth handing to ad platforms. Its firing rule is different from — and later than — the booking_started event BookerKit stores and sends to webhooks.

Where you'll see it: Google Tag Manager, GA4, or whatever reads your dataLayer

Not to be confused with

bookerkit_widget_opened

Also called:bookerkit_widget_opened

A dataLayer event fired when the widget loads or its trigger button is clicked. It goes to your site dataLayer only — it is not stored as a booking event and it does not feed any dashboard funnel number.

Where you'll see it: Google Tag Manager, GA4, or whatever reads your dataLayer

Not to be confused with

Booking Starts

The number of distinct sessions that reached the booking funnel — meaning the session recorded a booking start, a completed booking, or a staff-marked recovery. Browsing services or times is not enough on its own. It is the denominator of your conversion rate. A session counts here even when no start was ever recorded — a returning guest restored straight into the flow enters through their completion instead — so this figure will not line up with the number of start webhooks you received, in either direction.

Where you'll see it: Dashboard → Analytics

Not to be confused with

  • bookerkit_booking_started (dataLayer event) — The metric counts sessions with any funnel engagement; the dataLayer event fires only when a visitor finishes the personal-info step.
  • booking_started (webhook and database event) — The stored booking_started event is skipped for auto-recognized returning guests, so its count is lower than Booking Starts.
  • Conversion rate — Booking Starts is the denominator; the conversion rate is what share of them ended in a booking.
  • Booking session — Every widget load creates a session; only sessions with real engagement become a Booking Start.

booking_completed

Also called:booking_completed

The event fired once an appointment is confirmed. It is the primary conversion signal to give ad platforms, and it is what marks a session as Booked in the dashboard. The dataLayer version carries hashed email and name so ad platforms can match the conversion to a click.

Where you'll see it: Your dataLayer and webhook receiver; Dashboard → Analytics

Not to be confused with

  • booking_recovered — booking_completed means the guest booked in the widget; booking_recovered means staff booked them some other way.
  • Booking / Appointment — The event is the signal BookerKit sends; the appointment is the record sitting in Zenoti.

booking_recovered

Also called:booking_recovered

The record created when staff manually mark an abandoned session as recovered, because the guest ended up booking by phone, walk-in, or follow-up instead. It is always a manual dashboard action and never happens automatically. A session cannot be both completed and recovered — marking an already-completed session as recovered is rejected.

Where you'll see it: Dashboard → the session detail, via Mark as Recovered

Not to be confused with

  • booking_completed — Recovered is staff-entered and manual; completed is what the widget records on its own.

booking_started (webhook and database event)

Also called:booking_started

The safety-net lead capture. It is written at guest-lookup time — before the guest has verified with a code and before they exist in Zenoti — deliberately early and unverified so a lead survives a later failure or outage. It does not fire when the entered phone and email belong to different people; that mismatch case is silent by design. It is also not written for returning guests who are auto-recognized, which is why it cannot serve as the conversion denominator.

Where you'll see it: Your webhook receiver; the activity timeline on a guest profile

Not to be confused with

  • bookerkit_booking_started (dataLayer event) — The dataLayer event fires later, after personal info; this one fires at lookup, before verification.
  • Booking Starts — This event misses some engaged sessions entirely, so its count sits below the Booking Starts metric.
  • Webhook — This is the event; the webhook is the delivery of it to your CRM.

Click IDs

Also called:gclidfbclidfbcfbpmsclkid

The identifiers ad platforms attach to a click: gclid for Google, fbclid plus the fbc and fbp cookies for Meta, and msclkid for Microsoft. They are stored with the session and forwarded in the webhook payload, so your CRM can report the conversion back to the platform that produced it.

Where you'll see it: Webhook payloads, under tracking.click_ids

Not to be confused with

  • UTM parameters — A click ID identifies one exact click; UTMs describe the campaign it came from.

Conversion rate

Sessions that completed a booking online, plus sessions staff marked as recovered, divided by all sessions with any booking-flow activity, shown to one decimal place. Each session is counted once and completed takes precedence over recovered, so the figure can never exceed 100%. It is a session rate rather than a per-person rate: one guest who books, cancels, and rebooks creates two sessions and affects it twice.

Where you'll see it: Dashboard → Analytics

Not to be confused with

  • Booking Starts — Booking Starts is the denominator of this rate, not a separate measure of it.

Deposit events

Also called:deposit_collecteddeposit_pendingdeposit_faileddeposit_gift_card_minted

The records BookerKit writes around a deposit charge. deposit_collected is written only after the server itself confirms a successful charge — never on the browser's word — and carries the amount; deposit_pending, deposit_failed, and deposit_gift_card_minted cover the in-flight, failed, and gift-card-funded cases. Deposits appear per session in a guest timeline, not as one guest-level total.

Where you'll see it: The activity timeline on a guest profile

Not to be confused with

  • Deposit — The deposit is the money; these events are the audit trail of what happened to it.

Recent Session status

Also called:BookedRecoveredIncompleteAbandoned

A badge reflecting only the guest's most recent session: Booked if that session completed a booking through the widget, Recovered if staff marked it recovered, and Incomplete if neither. Because it looks at the latest session alone, an older completed booking does not keep it green. A guest who is mid-booking right now still shows Incomplete — the guests table has no in-progress state, and only their activity timeline reveals what is happening. Note that the filter chips above the table call this same group Abandoned, so Incomplete and Abandoned are two names for one status.

Where you'll see it: Dashboard → Guests table

Not to be confused with

  • Has Booked — Has Booked is all-time; this badge is only ever about the most recent session.
  • New guest vs. Existing guest — The New/Existing badge is fixed at first sync; this one changes with every visit.

Referrer / Source

The page a visitor arrived from, simplified into a readable name such as Facebook, Google, or Direct. When a utm_source is present it takes precedence over the referring domain, so a visit arriving from Facebook tagged utm_source=newsletter is reported as the newsletter.

Where you'll see it: Dashboard → Analytics traffic breakdown

Not to be confused with

  • UTM parameters — The referrer is inferred from the browser; UTMs are added by you, and they override it.

UTM parameters

Also called:utm_sourceutm_mediumutm_campaignutm_termutm_content

The campaign tags read from the page URL when the widget loads and stored with that session: utm_source, utm_medium, utm_campaign, utm_term, and utm_content. They are how a booking gets attributed to a specific campaign rather than just a channel.

Where you'll see it: Dashboard → Analytics breakdowns; webhook payloads

Not to be confused with

  • Referrer / Source — UTMs are tags you deliberately add; the referrer is what the browser reports on its own — and utm_source wins when both are present.
  • Click IDs — UTMs are your own campaign labels; click IDs are the ad platforms' identifiers for one specific click.

Webhook

An automatic POST that BookerKit sends to a URL you configure, typically GoHighLevel, when a booking starts or completes. The payload carries the event type, timestamp, booking details, and tracking information including UTMs, click IDs, and referrer. The two triggers toggle separately, so you can send completions only if starts are too noisy.

Where you'll see it: Widget Settings → Webhooks

Not to be confused with

Webhook signing

Also called:X-Bookerkit-Signature

Every outgoing webhook is signed with your account webhook secret, and the signature travels in the X-Bookerkit-Signature header. Your receiver can recompute it to confirm the request genuinely came from BookerKit and was not forged or altered in transit.

Where you'll see it: The headers of every webhook request you receive

Not to be confused with

  • Webhook — Signing does not change what is sent; it only proves who sent it.

Compliance

The HIPAA vocabulary that governs what BookerKit may hold on your behalf, and the agreement that has to be in place first.

BAA (Business Associate Agreement)

The HIPAA agreement that must be in place before protected health information can flow between you and BookerKit. Your account Owner accepts the current version in Settings. Until it is accepted, BookerKit blocks creating or serving that account widget — the booking widget simply will not run.

Where you'll see it: Settings → BAA

Not to be confused with

PHI (Protected Health Information)

The guest data HIPAA protects that BookerKit handles: names, email addresses, phone numbers, and appointment details such as service type, date, time, and provider. BookerKit acts as a Business Associate processing that data on your behalf, which is exactly why a BAA is required before anything is served.

Where you'll see it: The HIPAA page; Settings → BAA

Not to be confused with