Custom SimplyBook.me integration

What a custom SimplyBook integration actually means

The usual way to use SimplyBook is the way it ships: a widget dropped onto a page, or a link out to a *.simplybook.it address. It works. It also means the most important moment in your customer journey — the point where someone decides to give you money — happens inside somebody else’s interface, followed by somebody else’s emails.

A custom integration flips that round. SimplyBook stays as the engine; everything the customer touches is yours:

• Your own booking screens, built into your site with your own fonts, colours, wording and layout — no iframe, no third-party widget, no jump to another domain.
• Your own emails — confirmation, reminders, changes, the follow-up review ask — sent from your domain, in your voice.
• Your own customer area, where people sign in to see and manage their bookings alongside whatever else you offer them.
• SimplyBook invisible behind all of it, still doing the scheduling, still the thing your staff open in the morning.

Ours is live and bookable right now at /book-service/. Nothing on that page is a SimplyBook widget. Every service, every free slot and every confirmation on it comes through our own code.

Why you would bother

Brand consistency. A widget that doesn’t quite match your site reads as “this bit was outsourced”. Customers rarely say it out loud; they just trust the page slightly less.

Control of the journey. With your own UI you decide the order of the questions, what’s optional, what gets explained, where you offer reassurance, and what happens after the booking. Widgets give you a settings screen; code gives you the journey.

Owning the emails. This is the one owners underestimate. The confirmation and reminder emails are messages your customers actually open. Owning them means you write them, you time them, you decide the quiet hours, and the review request goes to your Google profile in your words at the moment you choose.

No third-party iframe. Fewer moving parts on the page, no cross-domain quirks, and your booking flow keeps working the way you built it rather than changing shape when a vendor redesigns their widget.

What stays SimplyBook’s job — and why that’s the right call

The temptation, once you’re writing code, is to write the whole thing. Don’t. A booking engine is much harder than it looks, and the parts that are hard are exactly the parts SimplyBook already does properly:

• Availability rules — working hours, breaks, per-service durations, buffers, holidays, seasonal changes.
• Double-booking prevention — the race condition where two people click the same 10am. Getting this right under concurrency is a genuine engineering problem.
• The staff diary — a mature admin interface your team already knows, on their phones, that you did not have to build or support.
• An off-site copy of the diary. If your website has a bad day, the appointments still exist somewhere else and staff can still see them. That is worth real money.

So the honest architecture is: buy the hard scheduling logic, build the experience. Ours is a small PHP proxy on ordinary shared hosting. All credentials live server-side; the browser only ever talks to our proxy, never to SimplyBook. Public read-only calls (service list, availability) are rate-limited per IP and cached for about 90 seconds; anything that writes requires proof of identity first.

The honest limits

Some things cannot be moved behind your brand, and you should know before you start:

• SimplyBook’s own notification templates are UI-only. The API cannot edit them. If you want your own emails you don’t customise theirs — you switch the relevant ones off in the admin and send your own. That means you also inherit the boring parts: queueing, retries, deduplication and email deliverability.
• The documentation is incomplete in places. We hit a create-client call that failed forever with a generic “value is required” message because the documented field list left out required custom client fields. The live JSON-RPC error payload names the missing field exactly — most client libraries just truncate it and hide the answer.
• Platform changes are outside your control. It is someone else’s product. Settings screens get renamed, defaults shift. Build so that a failure is loud rather than silent, and re-test after any account change.
• Some defaults are quietly dangerous. The callback URL is empty by default, so bookings made inside SimplyBook reach your server not at all, with no warning anywhere. Recurring services return the whole series from one booking call, so reading only the first entry hides eleven other appointments. Both cost us time before we caught them.

What a project involves

1. Look at what you have. Your services, staff, rules, current emails, and what the customer sees today. Half the value is often in decisions, not code.
2. Prove the connection. A server-side proxy, tokens cached properly, read-only endpoints first: services and real availability rendered on your own page.
3. Booking, then identity. Creating clients and bookings reliably — including the custom-field traps — then a sign-in method that actually proves who someone is. A SimplyBook client login only proves someone controls that booking account; it is not proof of being your customer. We use our own emailed-code sign-in.
4. Take over the emails. Turn off the ones you’re replacing, build a queue with retries and quiet hours, and get authentication right so they land in inboxes rather than spam.
5. Make silence visible. Webhooks, monitoring, and an alert when nothing has arrived for a while — “configured” is not the same as “working”, especially with hosting bot-protection in front of your endpoint.
6. Hand over. Plain notes on which settings live where, so you’re not dependent on remembering.

How we work on this

Pricing is per project and quoted after we’ve had a proper look — the work varies enormously depending on how many services and rules you have and how much of the email stack you want to own. We are not affiliated with, endorsed by or a partner of SimplyBook.me; we are simply customers of theirs who built an integration and learned where the edges are.

We built this for our own booking system in 2026, because we wanted our customers to stay on our site and get our emails. It is running, it is taking real bookings, and everything on these pages is what we found doing it. If you’d like the same for yours, we’re happy to talk it through.