How Calendar Webhook Sync Works

"Webhook" sounds technical, but the concept is everyday: it's a doorbell for software. Instead of a calendar sync service constantly knocking on Google's or Microsoft's door asking "anything new yet?", the provider rings the service's doorbell the moment something changes. That inversion - provider notifies service, rather than service interrogates provider - is the whole foundation of fast, modern calendar sync.

This page explains what a webhook is, how Google and Microsoft implement them for calendars, and how a sync service turns a stream of "something changed" pings into a reliable two-way sync.

A webhook is a callback to a URL

A webhook is just an agreement: "When X happens, send a message to this web address." The sync service registers a URL with the calendar provider and says, in effect, call this endpoint whenever this calendar changes. From then on, the provider does the calling. The service doesn't have to poll, because it's told.

The notification itself is usually lightweight - often little more than "calendar A changed." It's a trigger, not a payload. That detail matters for both speed and privacy: the actual event data isn't shipped in the webhook; it's fetched separately over the authenticated API only when needed.

How the two providers do it

The mechanics differ slightly but the shape is the same:

Google Calendar - push notification channels. The service calls Google's watch method on a calendar to open a channel. Google then sends an HTTP notification to the registered endpoint whenever that calendar changes. Channels expire, so the service renews them on a schedule.
Microsoft Graph - change-notification subscriptions. The service creates a subscription to a user's calendar. Microsoft posts a change notification to the endpoint when events are added, updated, or removed. Subscriptions also expire and are renewed automatically.

In both cases the provider is the active party. Calendar Family registers and renews these subscriptions for you behind the scenes - there's nothing to configure.

From "something changed" to a synced event

A webhook tells the service that something changed, not what. So the flow is:

Notification arrives at the service's endpoint: calendar A changed.
The service fetches the delta from provider A using a sync token - a bookmark that lets it ask only for what's new since last time, instead of re-reading the whole calendar.
The service maps the change - event, recurrence rule, time zone - to provider B's format.
It writes the change to calendar B over B's authenticated API.
The change appears in calendar B, typically within about a minute.

Because step 2 uses a sync token, the service moves the minimum amount of data and never has to scan an entire calendar to find a single edit.

Built to tolerate missed pings

Networks drop messages; subscriptions occasionally lapse. A well-built webhook sync doesn't assume perfection. The sync token is the safety net: at any time the service can ask the provider "what's changed since this bookmark?" and reconcile. So a missed notification doesn't cause silent drift - it's caught and corrected on the next sync. That combination of push notifications for speed and sync tokens for correctness is what makes the result both fast and trustworthy.

Why this is good for privacy too

Because the webhook is just a trigger and the data is fetched over the official, authenticated API, your event contents aren't sprayed around in notification payloads. Calendar Family builds on that mechanism: official-API access you grant and can revoke, fetching only what changed. See is calendar sync safe and private? for the full treatment, and real-time versus polling for why the webhook approach wins. The overview of real-time sync ties it all together.

Calendar Family is free.

Get started free

Frequently asked questions

What is a calendar webhook?

A webhook is a message a calendar provider sends to a pre-registered web address the moment something changes. Instead of a sync service repeatedly asking 'anything new?', the provider proactively notifies it, which is what makes the sync feel near-instant.

Do Google and Microsoft both support webhooks for calendars?

Yes. Google Calendar uses push notification 'watch' channels, and Microsoft Graph uses change-notification subscriptions. Both call out to a registered endpoint when a calendar changes, and both require the subscription to be renewed periodically, which a sync service handles automatically.

Does the webhook contain my event details?

Typically no. The notification usually just says 'this calendar changed' - it's a trigger, not the data. The sync service then makes a separate authenticated request to fetch only what changed, so the event content travels over the secure API rather than in the webhook itself.

What happens if a webhook is missed?

Sync doesn't rely on never missing one. Using sync tokens, the service can ask the provider 'what changed since I last checked?' and reconcile, so a dropped notification self-heals on the next sync rather than causing permanent drift.