Zoom integration

What the build usually covers

• Meetings created from your system, with the join link on the confirmation.
• Availability and slot holding, so two people can't take the same time.
• Calendar sync both ways, including changes made outside your app.
• Webhooks for meetings started, ended, updated and recordings completed.
• Reminders that cancel themselves when the booking does.
• Recording retrieval into storage you control, with access rules.

Scheduling is a calendar problem, not a video problem

Creating a meeting is one API call. Everything that goes wrong afterwards is calendar logic.

Store UTC, and store the zone with it

The bug that ruins booking systems is storing local wall time. 2pm means nothing on its own. Store the instant in UTC and keep the zone name beside it, Australia/Brisbane or Australia/Sydney, never a fixed offset like +10:00, because the offset moves and the name doesn't.

Queensland doesn't observe daylight saving and New South Wales does. For half the year a Brisbane practitioner and a Sydney client are an hour apart from what they both assume, and a system holding an offset will confidently book the wrong one. Recurring appointments need the rule and the zone stored rather than timestamps calculated once, or every occurrence after the changeover lands an hour out. Put both zones on the confirmation.

Double booking, when availability lives in several systems

A practitioner usually has a practice management system, a personal calendar, a phone that rings, and now your booking page. Pick one source of truth for availability and treat the rest as feeds into it.

Hold the slot when someone starts booking, with a short expiry so an abandoned checkout releases it. Check availability again at confirmation, not only when the page rendered, because two people can be looking at the same time. Put an idempotency key on the write, so a double tapped confirm creates one meeting rather than two. A single licensed host generally can't run two meetings at once either, so capacity is part of the availability rule, not just the diary.

What happens when a booking moves or disappears

Update the existing meeting rather than deleting it and creating a new one. Delete and recreate hands out a new join link, and the customer will click the one already sitting in their original invite.

Cancellation has to travel everywhere: the calendar invite, the reminder queue, the CRM record, the payment if one was taken. It travels the other way too, because someone will move the meeting inside Zoom. Webhooks for updated, ended and deleted events keep you in step.

Recordings, consent and where the file actually lives

Cloud recordings sit under a retention policy, so if a recording matters, pull it down when the completed webhook fires and store it somewhere you control.

Consent is not the participant list. Everyone on the call needs to know it's being recorded, and the announcement should be on rather than assumed. Once you hold a recording of a client call the privacy obligations are yours: how long you keep it, who can open it, and what you do when someone asks for a copy or asks you to delete it. For health, legal and financial work that belongs in the scope, not in a settings page nobody has read.

How the build runs

1. We map the booking

   Who can be booked, when, and which system decides.

2. Scope and price

   Fixed scope, fixed number, dates in writing.

3. Build and test

   Time zones, holds and webhooks tested across a daylight saving changeover.

4. Launch and watch

   Failed bookings and webhook errors alert a person, not a log file.

Who this suits, and who it doesn't

It suits clinics, consultants and education providers taking bookings that turn into calls across state borders.

It doesn't suit a business with one calendar and five bookings a week. A scheduling link handles that.

Why build it with us