Calendar sync in a booking app: Google Calendar and Outlook

How should a booking app sync with Google Calendar and Outlook?

Ask each staff member to connect their calendar with the narrowest permission that works, read their busy times to block slots, and write confirmed bookings into their calendar. Keep it current with incremental sync and change notifications, renew those notifications before they expire, re-check availability at the moment of booking, and handle disconnected calendars openly.

If you are still deciding whether to build a booking system at all, start with our guide on when you need a custom booking system, which also covers time zones. This article is about doing the calendar part properly.

Do you need one-way or two-way sync?

• Busy times only: the app reads when staff are busy and hides those slots. Nothing is written back.
• Push bookings out: confirmed bookings appear in the staff member's calendar, so they see their day in one place.
• Full two-way sync: bookings go out, and changes made in the calendar, such as moving or cancelling an event, come back into the app.

Most service businesses need the first two. Full two-way sync is harder, because a booking moved in Outlook may break rules your app enforces, such as opening hours, prices or the customer's own confirmation. Many apps treat the booking app as the source of truth and only accept calendar changes as busy time.

What permissions should you ask for?

Google offers separate scopes for viewing availability, editing events, editing only events on calendars the user owns, and full calendar access, listed in its Calendar API scopes. If you only block busy times, the free/busy scope may be all you need. If you write bookings, ask for event access rather than full calendar control. Google also states that public apps using certain scopes must complete a verification process, so plan it into the launch.

Microsoft Graph has its own calendar permissions; the same rule applies. Staff are more willing to connect a calendar when the consent screen asks for little.

How do you check availability without copying every event?

Google's free/busy query returns only the busy time ranges for a set of calendars between two times, without event titles or attendees, per the freebusy reference. That is often enough to block slots and keeps private details out of your database.

If you need more, such as showing a staff member's day inside your app, store only the fields you use, and plan how you will delete them when someone disconnects.

How do you keep changes in sync without reading everything again?

• Google Calendar: after a first full read, the API returns a sync token. Later requests send that token and receive only what changed, including deleted events. If Google invalidates the token, the request fails with HTTP 410 and you must clear the stored data and run a full sync again (Google: synchronize resources).
• Outlook through Microsoft Graph: a delta query on a calendar view, which is a fixed date range, returns new, updated and deleted events, then a delta link to use next time. Deleted events arrive marked as removed (Microsoft: delta query for events).

Both approaches mean your sync code must handle a full re-sync at any time, not only on the first day.

How do change notifications work, and why do they expire?

Instead of asking every few minutes, your server can ask to be told about changes:

• Google sends a notification to your HTTPS address when a watched calendar changes. The message has no body, so your app then runs an incremental sync to see what changed. There is no automatic renewal, so you create a new channel before the old one expires (Google: push notifications).
• Microsoft Graph subscriptions for Outlook events last at most 10,080 minutes, just under seven days, and must be renewed before they expire (Microsoft: subscription lifetime).

Treat notifications as a hint, not a guarantee. A scheduled job that renews subscriptions and runs an incremental sync for every connected calendar catches anything missed. This is the kind of background process our workflow automation work sets up and monitors.

How do you avoid double bookings?

• Show slots from cached availability, but check the calendar again when the customer presses book.
• Hold the slot in your own database in the same step, so two customers cannot take it at once.
• Write the event to the staff calendar after the booking is confirmed, and store the event ID so you can update or cancel it later.
• If a calendar event later appears over an existing booking, alert the staff member rather than cancelling the customer automatically.

How should you handle recurring events?

A weekly team meeting is stored once with a recurrence rule, and changing one occurrence creates an exception. Google can expand recurring events into single instances when you list them, and each instance keeps a link to its parent series and its original start time (Google: recurring events). Microsoft's calendar view also returns individual occurrences and exceptions. Use the expanded instances for availability; never try to calculate recurrences yourself.

What happens when someone disconnects their calendar?

Tokens are revoked, passwords change and staff leave. When a sync fails because access has gone, stop the notification channels, mark that person's availability as unknown rather than free, tell an admin, and delete stored calendar data you no longer need. A quiet failure here is how double bookings happen weeks later.

We build these integrations as part of booking and scheduling systems through our custom software development service.

Frequently asked questions

Last updated November 13, 2026