What's new in TheBooking 4.0

Version 4.0 is the current major product model and the baseline for this documentation.

New in 4.0

TheBooking 4.0 keeps the appointment model you already know, but rebuilds several of its foundations around teams, automation, and compliance. The sections below explain what changed and why it is worth adopting, not just that it exists.

From one provider to a team

The previous plugin computed availability one provider at a time and left provider selection entirely manual; running a multi-person team meant duplicating plans per provider and letting customers hunt through near-identical slots for whichever specialist had time free. TheBooking 4.0 lets one plan serve several providers at once, and a service can either keep manual selection or let the system assign the appointment automatically — to the first available provider, the least loaded one, or at random.

Customers booking an auto-routed service see one merged slot instead of a wall of near-identical options, and administrators can still step in and override the assignment from the reservation form when a specific case calls for it.

See Provider assignment and Availability plans.

Google Calendar that understands teams, not just individuals

Previously, every provider connected their own separate Google account, full stop — there was no concept of a calendar shared across a team, so an organization with several providers ended up with several disconnected calendars instead of one coherent picture. TheBooking 4.0 replaces that with an explicit model: a Google account is either personal (bound to exactly one provider) or team-managed, and every calendar inside a team account can stay open to the whole team or be scoped to a chosen sub-team.

The same model governs all three calendar roles — source availability, personal busy-time blocking, and destination events — so what a calendar affects is always a direct consequence of account and calendar configuration, not a hidden per-service switch. Rescheduling also got smarter here: moving a reservation to a different provider now updates the existing Google Calendar event in place whenever the new provider still qualifies for that calendar, instead of always deleting and recreating it.

See Provider and sub-team scoping.

Reservations you can actually move, with a full paper trail

Changing an appointment's date and reassigning its provider used to be two separate actions, saved independently and with no dedicated notification explaining the change — customers and providers found out through a generic message, if at all. Reschedule is now one action: pick a new slot, optionally reassign the provider, and TheBooking updates the reservation, sends dedicated "old vs. new" emails to customer and provider, and keeps every connected integration — Google Calendar, Zoom, webhooks — in sync.

Reservations already kept an activity log, but entries only recorded that something had changed, not what the value had been before, and a combined date-and-provider change showed up as two unrelated lines. The reservation drawer's History tab now shows a proper before-and-after for every entry, and a reschedule collapses back into the single, coherent action it actually is.

See Reschedule a reservation and Reservation history.

A Privacy & GDPR panel, without leaving the customer record

WordPress's native privacy tools already worked correctly behind the scenes — export and erasure requests were resolved by email, so guest customers with no WordPress account were covered too. But "working correctly" still meant leaving the customer screen, finding Tools > Export/Erase Personal Data, retyping the email, and waiting for the customer to confirm a link before anything happened. And once a request went through, erasure was the only outcome available — there was no way to strip a customer's identity while keeping their reservations for accounting or reporting.

The new Privacy & GDPR section on every customer record closes both gaps: download a data export immediately, file the standard confirmation-based request, anonymize the customer while preserving their reservations, or delete everything outright — all from one panel, all logged in an activity trail, and all identical whether the customer has a WordPress account or not.

See Customers and Privacy & GDPR.

Central switches for integrations and payments

Previously, whether Google Calendar, Google Maps, Zoom, or online payments were "on" was mostly implicit: if credentials were configured, the feature behaved as active. TheBooking 4.0 gives each of these its own explicit switch under Settings > Integrations and Settings > Payments, decoupled from whether a gateway or credential set happens to be configured.

That means you can keep credentials on file and turn a feature off site-wide — during a migration, a test, or a temporary pause — without losing configuration. Existing installations were migrated to keep behaving exactly as they did before the upgrade.

See Integrations overview and Enable online payments.

Freed from WPML: an internal translation catalogue

Translating service names, form fields, and emails used to mean routing everything through WPML's String Translation system — a dependency that only worked if WPML was installed and precisely configured for each string type. TheBooking now stores its own translations in an internal catalogue, with WPML and Polylang reduced to the job they are naturally good at: telling TheBooking which languages the site actually has active.

Existing WPML translations are imported automatically the first time the catalogue is enabled, so nothing needs to be retyped, and sites without WPML can now translate content too — a second WordPress language is all it takes.

See Internal translations.

Reusable email templates

Building a new service email used to mean starting from scratch or copying an entire service to carry its notifications over — there was no library of reusable templates independent of a specific service. TheBooking 4.0 adds a proper Templates workspace: save the current email as a named, reusable template, browse and preview saved templates later, and apply one to any service's notification — while copying content from another existing service is still available for when that is genuinely what you want.

See Notifications.

Scoped API tokens and outbound webhooks

API access used to be effectively binary: a token could do everything, or it was marked read-only. Tokens are now explicitly scoped to read and/or write, stored as a hash rather than in the clear, and tracked with their last use and IP address; existing tokens were migrated to the equivalent scopes automatically.

Alongside that, TheBooking can now push signed webhooks for fourteen booking, payment, customer, and service events, so external systems no longer need to poll the API to notice a change.

See API and webhooks and Webhooks.

Zoom: one host, or one per provider

The Zoom integration used to create every meeting under a single connected account, which works well for a small team but gets awkward once each provider should really be hosting their own sessions. TheBooking 4.0 keeps that single-host mode as the default, but lets you map each provider to their own Zoom user instead — and if a provider is not mapped, TheBooking will not silently create the meeting under the wrong host.

See Zoom.

Review after upgrade

• Activate the subscription license.
• Confirm all services use real appointment availability.
• Review slot duration, buffer, capacity, and plan independence.
• Review multi-provider plans and provider assignment rules.
• Enable online payments centrally and confirm gateway readiness.
• Enable integrations centrally and validate credentials.
• Review reusable email templates and reschedule notifications.
• Enable the internal translation catalogue and inspect imported translations.
• Generate scoped API tokens and rotate integrations that no longer need write access.
• Configure webhook endpoints and verify signatures.
• Review customer Privacy & GDPR actions and the privacy policy guide.

Important compatibility changes

• Customer booking is single-slot.
• The public reservation API validates slots against current availability.
• Slot duration and buffer are service-scoped.
• Provider conflicts cannot be bypassed with service overlap switches.
• The event-list and no-slot booking modes are not current widget workflows.
• TheBooking owns dynamic content translations at runtime.
• Automatic migration from releases older than 3.0 is not supported.