Taking over SimplyBook’s customer emails

What SimplyBook actually sends your customers

Out of the box SimplyBook.me sends five kinds of email to the client: a booking confirmation, a reminder before the appointment, a change notice if the booking is edited, a cancellation notice, and a feedback request some days afterwards. Provider (staff) notifications are a separate set with their own switches — turning off a client email does not turn off the matching one to your team, and vice versa. Worth knowing before you start hunting for why an email you thought you had killed is still arriving.

One more thing to check before you assume you know what is being sent: if you have the Multiple booking or Group booking features enabled, those features override the default notification templates. The email your customer receives may not be the template you have been carefully editing.

Templates are editable only in the admin UI

This is the constraint that shapes everything else. The notification templates live in SimplyBook’s admin interface and can be edited only there. There is no API surface for them — you cannot version them in git, you cannot vary them per service from your own code, you cannot A/B them, and you cannot deploy them alongside a release. If you want your booking emails to be part of your codebase rather than part of somebody’s SaaS settings screen, the only route is to stop SimplyBook sending them and send your own.

The feedback request is usually what starts this

For most firms the trigger is the automatic feedback request. It points customers at SimplyBook’s own review page. That is a perfectly reasonable thing for SimplyBook to do and a slightly odd thing for your business to do, because the review you actually want sits on your Google Business Profile, where it does some good. So the first change most people make is to disable it: Settings → Email and SMS settings → “Send feedback request X days after booking” → Disable. Then send your own follow-up pointing wherever you want.

While you are there, one legal point that is easy to get wrong in the UK. Asking a customer for an honest review is fine. Rewarding them for leaving one — a discount, a prize draw entry, a free hour — is not: incentivised reviews fall foul of the Digital Markets, Competition and Consumers Act. Rewarding a referral is a different thing entirely and remains fine. If you are writing a follow-up email template, keep those two ideas in separate sentences, because they read very similarly and only one of them is legal.

Replacing them properly starts at the webhook

Your own emails have to be triggered by something, and the only reliable trigger is SimplyBook’s callback. Set the Callback URL in the admin under Settings → API; SimplyBook then POSTs raw JSON containing booking_id, booking_hash, company and notification_type, where the type is one of create, cancel, notify or change. The POST is not signed, so protect the endpoint yourself — we pass a secret token in the query string and compare it with hash_equals(). Booking detail is then read back with getBookingDetails(id, sign), where sign = md5(bookingId . bookingHash . secretKey).

Do not send the email inside the webhook request. Write it into a queue and return. Our queue is a JSON file holding one state machine per email — queued, sending, sent, failed — with file locking so two overlapping callbacks cannot send twice, tmp-file-plus-rename writes so a crash mid-write cannot corrupt the queue, a retry cap so a permanently bad address does not loop forever, quiet hours (we send between 9am and 8pm) and a per-customer dedupe window so a customer who reschedules three times in ten minutes gets one email, not three. Every one of those pieces exists because something went wrong without it.

Two behaviours to build in from the start. Return a non-2xx status on transient failures so SimplyBook retries; if you return 200 after a failed lookup, that booking is gone for good. And make the callback announce itself somewhere visible — we post to Slack — because hosting bot-protection can quietly intercept server-to-server POSTs. “Configured” is not the same as “working”, and silence looks identical to no bookings.

One gap you must plan for: SimplyBook fires no webhook for reminders. Reminders are purely time-based inside their system. If you want your own reminder emails, you schedule them yourself from the booking start time you got at creation.

The switch-off order that avoids disasters

Run both systems in parallel for a few weeks. Yes, customers get two confirmations; that is a small, explainable annoyance and it is far better than the alternative. Watch your queue against SimplyBook’s own sent log until the two agree on every booking, including ones staff take inside the SimplyBook interface.

Then switch SimplyBook’s emails off one type at a time, leaving a week between each, starting with the least critical — feedback request, then change, then cancel, then reminder. Never turn off their confirmation email first. The confirmation is the one email a customer notices the absence of, and it is the one that proves the booking exists. Turn it off last, and only once yours has landed correctly for every booking type you handle, including recurring series and bookings created by staff rather than by your own front end.

Deliverability: the parameter that ate our sign-in codes

This cost us more time than the rest of the project. PHP’s mail() does not set an envelope sender unless you tell it to. Without the -f parameter, Return-Path defaults to the hosting account’s address, SPF is then checked against that domain rather than yours, the alignment fails, and Gmail either junks the message or rejects it outright. The From: header looks perfect the whole time.

// Without the fifth argument, Return-Path = the hosting account
mail($to, $subject, $body, $headers, '-fbookings@yourdomain.co.uk');

We now send through authenticated SMTP with an explicit envelope sender, which removes the ambiguity entirely. But the missing -f is what stopped our passwordless sign-in codes reaching Gmail, and the symptom — “some customers say they never got it” — is maddeningly vague.

A forwarded test proves nothing

When you test, send directly to an external mailbox you control — a real Gmail, Outlook and Yahoo address. If you send to your work address and forward it to Gmail to check, Gmail authenticates the forwarder, not you. The message sails through, you declare victory, and your customers carry on not receiving anything. Check the received headers on the direct test: you want SPF pass, DKIM pass and DMARC pass, all aligned to your sending domain.

We built all of this for our own booking system at 365 Techies in July 2026, and everything above is what we found while doing it rather than what the documentation says. If you are looking at the same job and would rather not spend a fortnight discovering the -f parameter, we are happy to talk it through or do it for you.