How Calendar Sync Actually Works: Webhooks, Polling & Dedup Explained

Calendar sync works by detecting changes on one calendar and replicating them to another. The three core mechanisms are: (1) change detection — how the sync tool learns something changed, using either webhooks or polling; (2) incremental sync — how it fetches only what changed, using sync tokens; and (3) deduplication — how it prevents infinite loops when syncing bidirectionally, using metadata-based event IDs. These three layers form the foundation of every calendar sync tool, from simple polling scripts to production-grade services like SYNCDATE. Here is how each layer works.

The Three Layers of Calendar Sync

Every calendar sync system — whether it is SYNCDATE, CalendarBridge, OneCal, or a DIY solution — needs to solve three problems:

1. Detect that something changed on a calendar
2. Fetch only the changes (not the entire calendar every time)
3. Prevent loops and duplicates when syncing in both directions

The differences between sync tools come down to how they solve each problem. The approach to layer one (change detection) has the biggest impact on user experience, because it determines how fast events propagate between calendars.

Layer 1: Change Detection — Webhooks vs Polling

The first problem any sync tool must solve is knowing when something changes. There are two fundamental approaches: polling and webhooks.

Polling (How Most Sync Tools Work)

Polling means the sync tool asks the calendar "has anything changed?" on a fixed schedule — every 5 minutes, 15 minutes, or 60 minutes.

How it works:

1. Sync tool sets a timer (e.g., every 15 minutes)
2. Timer fires — tool calls Google Calendar API: "give me changes since my last check"
3. If changes exist — process them
4. If no changes — do nothing, wait for next timer

Advantages: Simple to implement. Works with any calendar API that supports listing events. No special infrastructure or publicly accessible server required.

Disadvantages: Delay between event creation and sync. If you poll every 15 minutes, an event created at 2:01pm might not sync until 2:15pm. During that gap, scheduling tools show stale availability — which can lead to double bookings. Polling also wastes API quota on empty checks, which matters because Google Calendar API has rate limits that restrict how frequently you can query.

Who uses polling: CalendarBridge (~15 min), Reclaim.ai, OGCS (user-configured, typically 15-60 min).

Webhooks (Push Notifications)

Webhooks flip the model. Instead of the sync tool asking "has anything changed?", the calendar tells the sync tool when something changes. Google Calendar's push notification system is documented in the Google Calendar API Push Notifications guide.

How it works (Google Calendar webhooks):

1. Sync tool registers a webhook channel with Google Calendar API (calls watch())
2. Google stores the webhook URL and a channel token
3. When any event changes on that calendar, Google sends an HTTP POST to the webhook URL
4. Sync tool receives the notification — fetches the actual changes — processes them
5. Channel expires after a set period (typically days) — tool renews it automatically

Advantages: Near-instant sync. Events propagate in seconds, not minutes. No wasted API calls when nothing changes. More efficient use of Google Calendar API quotas.

Disadvantages: More complex to implement. Requires a publicly accessible HTTPS endpoint to receive push notifications. Webhook channels expire and need renewal. Some calendar APIs do not support webhooks at all. Notifications can occasionally be missed due to network issues or Google infrastructure hiccups.

Who uses webhooks: SYNCDATE (~4 second total round-trip).

Hybrid: Webhooks + Polling Fallback

The most reliable approach combines both. Webhooks handle the fast path (instant notification), while a background polling job catches anything webhooks might have missed. Google's own documentation notes that push notifications are not guaranteed for every change, making a fallback mechanism essential for production systems.

SYNCDATE uses this hybrid model: webhooks for near-instant sync (~4 seconds), with a 15-minute polling fallback that picks up any missed changes. This ensures zero events are lost even during temporary webhook delivery failures.

To understand why some sync tools feel "delayed" while others feel instant, see Why Is My Calendar Sync Delayed?.

Layer 2: Incremental Sync — Sync Tokens

Once the sync tool knows something changed, it needs to fetch what changed without re-downloading the entire calendar. This is where sync tokens come in.

The Problem with Full Sync

A Google Calendar with 2 years of events might have 3,000+ events. Re-fetching all 3,000 events every time one event changes is wasteful — it burns API quota, takes time, and creates unnecessary server load. For busy professionals, Reclaim.ai reports that the average knowledge worker's calendar contains hundreds of events per year, making full-calendar fetches prohibitively expensive at scale.

How Sync Tokens Work

Google Calendar API provides sync tokens — opaque strings that represent a point in time in the calendar's change history. Google's incremental sync documentation describes the mechanism in detail. The underlying data format builds on the iCalendar specification (RFC 5545), with Google adding their own extensions for change tracking.

First sync (no token):

1. Sync tool calls events.list() with no sync token
2. Google returns all events within the requested time range
3. Google includes a nextSyncToken in the final page of results
4. Sync tool stores this token

Subsequent syncs (with token):

1. Sync tool calls events.list() with the stored nextSyncToken
2. Google returns only events that changed since that token was issued
3. Google includes a new nextSyncToken
4. Sync tool processes only the changed events and stores the new token

This is called incremental sync. Instead of fetching 3,000 events, the tool fetches 1-5 changed events. Massively more efficient — often reducing API usage by 99% or more.

The sections below cover sync token edge cases and practical constraints.

Sync Token Gotchas

Sync tokens have practical constraints that sync tools must handle correctly. These are some of the known limitations of the Google Calendar API:

Pagination matters. Google only returns the nextSyncToken on the final page of results. If a calendar has more than 250 events (one page), the tool must paginate through all pages before it gets a usable sync token. Without proper pagination, the tool never gets a sync token and does a full sync every time — wasting quota and slowing down the process.

Tokens expire. Google can invalidate a sync token at any time (typically after weeks of inactivity). When this happens, the API returns a 410 Gone error. The sync tool must fall back to a full sync and obtain a new token. Well-built tools handle this transparently without user intervention.

No time filters with tokens. When using a sync token, you cannot pass timeMin or timeMax parameters. Google returns all changes regardless of date range. The sync tool must filter events at the application level (e.g., skipping events beyond the user's configured sync horizon).

Recurring events come as masters. Sync tokens require singleEvents=false, which means recurring events are returned as the master event with a recurrence rule (RRULE per RFC 5545), not as individual expanded instances. The sync tool must handle RRULE parsing and ensure recurring events sync correctly with timezone information intact.

Outlook's Equivalent: Delta Links

Microsoft Graph API uses a similar concept called delta queries. Instead of a sync token, Outlook returns a deltaLink URL. Calling that URL returns only events changed since the link was generated. Same principle, different API naming. SYNCDATE fully supports both Google Calendar and Microsoft Outlook/Office 365, enabling cross-provider sync using each platform's native incremental sync mechanism. For the most common setup scenario, see our guide on syncing Google Workspace and personal Gmail.

Layer 3: Deduplication — Preventing the Infinite Loop

Two-way sync creates a fundamental problem: if Calendar A syncs to Calendar B, and Calendar B syncs back to Calendar A, every event gets copied infinitely. Deduplication is what separates a working sync tool from one that floods your calendar with duplicates. For more on this topic, see How to Stop Calendar Events from Duplicating.

The loop: Event created on A → synced to B → sync detects "new event on B" → syncs back to A → sync detects "new event on A" → syncs to B → forever.

Metadata-Based Dedup

The solution is to mark synced events so the system can identify its own copies.

How SYNCDATE does it:

Every event created by SYNCDATE includes a custom metadata property:

```

calendarSyncId: <user_id>:<original_source_event_id>

```

• user_id identifies which user's sync created this event
• original_source_event_id references the original event that started the chain

When processing changes, the rule is simple: if an event has a calendarSyncId that starts with the current user's ID, skip it — it is a copy the system already created.

This prevents the A-to-B-to-A loop because:

1. User creates event "Dentist" on Calendar A
2. SYNCDATE copies it to Calendar B with metadata calendarSyncId: user123:eventA_id
3. Google sends a webhook notification about the new event on Calendar B
4. SYNCDATE checks: does this event have calendarSyncId starting with user123? Yes — skip
5. No loop. No duplicate.

This approach is far more reliable than name-based matching or time-based matching, which break down with recurring events, edited titles, or timezone differences.

Cross-Sync Dedup

A more subtle problem: what if a user has two different sync processes that overlap?

• Sync 1: Calendar A ↔ Calendar B
• Sync 2: Calendar A ↔ Calendar C
• Both syncs copy an event from A to their targets. Then Sync 1 sees the event on B and tries to copy it to A (skip — dedup catches it). But what if there is also a Sync 3: B ↔ C? Sync 3 might try to copy the event from B to C, but it is already on C from Sync 2.

SYNCDATE handles this with transitive dedup: the calendarSyncId always references the original source event, not intermediate copies. Before creating an event on a target calendar, the system checks the synced_events database table to see if that original source event already exists on the target via any sync process. This prevents duplicates even in complex multi-calendar configurations.

Multi-User Dedup

Dedup is scoped per user. If user A syncs a calendar and stamps events with user_A:eventId, user B's sync sees that metadata but does not skip it (different user prefix). This means multiple users can independently sync the same shared calendars without interfering with each other — essential for teams where several members might each sync a shared team calendar to their own personal calendars.

Conflict Resolution

When two-way sync is active, the same event can be modified on both calendars simultaneously. How does the sync tool decide which version wins?

Last-write-wins (most common): Compare the updated timestamp on both versions. The most recent modification takes precedence. This is simple, deterministic, and handles 99% of real-world cases. Both SYNCDATE and CalendarBridge use this approach. The iCalendar specification (RFC 5545) defines the LAST-MODIFIED property that underpins this strategy.

Merge (rare): Some enterprise sync tools attempt to merge non-conflicting field changes (e.g., title changed on Calendar A + time changed on Calendar B — apply both). This is complex, error-prone, and generally not worth it for calendar sync where the same person typically edits the same event.

Privacy During Sync

An important aspect of how calendar sync works is what information gets copied. SYNCDATE syncs events as "Busy" blocks by default, meaning the target calendar shows that you are busy at that time without revealing event titles, descriptions, or attendees. This is critical for privacy in calendar sync — especially when syncing personal events to a work calendar. For teams distributed across the EU, our guide on calendar sync for European teams covers GDPR-specific considerations.

All OAuth tokens are encrypted with AES-256-GCM at rest, following Google's OAuth 2.0 security best practices. SYNCDATE is hosted on EU infrastructure (Hetzner, Germany), compliant with GDPR requirements, and never stores the content of your calendar events on its servers — it reads, transforms, and writes events in real time.

Putting It All Together

Here is the complete flow for a webhook-based, incremental, deduplicated calendar sync:

1. User creates event "Team Standup" on Calendar A at 9am Monday
2. Google sends webhook to SYNCDATE's server: "Calendar A changed"
3. SYNCDATE fetches changes using stored sync token — gets the new "Team Standup" event
4. Dedup check: Does "Team Standup" have a calendarSyncId for this user? No — it is an original event, proceed
5. Privacy filter: Apply sync settings (e.g., copy as "Busy" block or with full details)
6. Create on target: SYNCDATE creates a copy on Calendar B with metadata calendarSyncId: user123:standup_event_id
7. Store mapping: SYNCDATE records the source-to-target event mapping in its database
8. Google sends webhook about the new event on Calendar B
9. SYNCDATE fetches changes — gets the event with calendarSyncId
10. Dedup check: calendarSyncId starts with current user's ID — skip (it is our own copy)
11. Done. Total time from step 1 to step 6: ~4 seconds.

If you're wondering whether Google offers this natively, the answer is no — see can you actually sync Google Calendars between accounts? for the full breakdown. This entire flow repeats for updates and deletions too. Move a meeting to a new time? The update propagates in ~4 seconds. Cancel a meeting? The deletion propagates in ~4 seconds.

SYNCDATE: Try Webhook-Driven Sync for Free

SYNCDATE's free tier includes everything described in this article:

• Webhook-driven sync with ~4 second propagation (not polling)
• Metadata-based deduplication preventing infinite loops and duplicate events
• Incremental sync tokens for efficient API usage
• 15-minute polling fallback ensuring zero missed changes
• 2 calendars, 2 accounts — forever free, no credit card required

For larger setups, the Starter plan (€1.99/month, 9 calendars, 4 accounts) and Pro plan (€8.99/month, 30 calendars, 8 accounts with priority sync) cover most professional needs. Annual billing saves 17%. See the full pricing breakdown.