SYNCDATE vs Keeper: Features, Pricing & Architecture Compared

SYNCDATE and Keeper both sync calendars across accounts, but they take fundamentally different approaches. SYNCDATE connects directly to Google Calendar's and Microsoft Outlook's APIs and uses webhooks for near-instant sync (~4 seconds). Keeper aggregates calendars through iCal feeds — a simpler architecture, but one that polls for changes rather than receiving them in real time. If you want the fastest, most accurate sync between your calendars, SYNCDATE wins on speed and fidelity. If you want an open-source, self-hostable tool with built-in privacy anonymization, Keeper offers something most commercial tools don't.

The choice comes down to architecture. Direct API integration versus iCal aggregation is not a minor implementation detail -- it determines what your sync tool can and cannot do. According to Atlassian's 2024 State of Teams report, 76% of knowledge workers manage events across multiple calendar systems, making the architecture of your sync tool a critical decision. This guide breaks down every dimension that matters: sync method, speed, privacy, pricing, and the trade-offs of open-source versus managed SaaS.

The Core Difference: Direct API vs iCal Aggregation

This is the single most important distinction between SYNCDATE and Keeper, and it affects everything else in this comparison.

How SYNCDATE syncs

SYNCDATE connects directly to your calendar provider's API. For Google Calendar, this means using Google's Calendar API with push notifications (webhooks). When you create, update, or delete an event, Google notifies SYNCDATE's servers within seconds. SYNCDATE processes the change and pushes it to the target calendar via the same API. The entire round-trip takes about 4 seconds.

SYNCDATE also supports Microsoft Outlook via the Microsoft Graph Calendar API, using a similar webhook-based approach for near-instant sync.

Direct API access means SYNCDATE can read full event details, write events natively, handle recurring event RRULEs as defined by the iCalendar specification (RFC 5545), preserve timezones, and sync deletions. It's a first-class integration, not a middleman translation.

How Keeper syncs

Keeper takes a different approach entirely. It pulls events from remotely hosted iCal (ICS) links — the standardized calendar feed format — and pushes them to one or many target calendars. Think of it as an aggregator: it collects calendar feeds, strips them down to busy/free blocks, and redistributes them.

This architecture has real advantages (simplicity, provider-agnosticism, built-in privacy) and real limitations (no true two-way sync, polling-dependent speed, lossy event translation).

Why this matters in practice

Consider a scenario: you change a meeting from 2 PM to 3 PM on your work calendar.

With SYNCDATE, Google's API sends a webhook notification. SYNCDATE detects the update, reads the changed event, and pushes the new time to your personal calendar. Your personal calendar shows 3 PM within about 4 seconds. A 15-minute polling fallback catches anything the webhook misses.

With Keeper, the iCal feed for your work calendar needs to be refreshed. On the free tier, that happens approximately every 30 minutes. On the Pro tier, approximately every minute. Until the feed refreshes, your personal calendar still shows 2 PM. During that window, anyone checking your personal calendar sees stale availability.

For scheduling-sensitive workflows — where tools like Calendly or Cal.com read your calendar to offer available slots — a 30-minute (or even 1-minute) delay can mean the difference between accurate availability and a double-booking.

Sync Speed: Webhooks vs Polling

The speed difference between these tools is not incremental — it's architectural.

SYNCDATE uses webhooks as the primary sync mechanism and polling as a safety net. Keeper uses polling as its only mechanism, with the frequency determined by your plan tier.

As Google's own documentation notes: "Notifications are not 100% reliable. Expect a small percentage of messages to get dropped under normal working conditions." — Google Calendar API, Push Notifications Guide. This is why SYNCDATE uses a 15-minute polling fallback alongside webhooks to ensure no changes are missed.

According to Google's push notification documentation, webhook-based notifications are delivered within seconds of a calendar change. This is the recommended approach for applications that need current calendar data. Polling-based sync, by contrast, only discovers changes on its next scheduled check — introducing a delay that compounds across every event change throughout the day.

If sync speed is not critical to your workflow — say, you only need calendars to roughly align by end of day — Keeper's polling works fine. But for anyone relying on real-time availability, the difference between 4 seconds and 30 minutes is the difference between preventing conflicts and hoping for the best.

Two-Way Sync: A Fundamental Difference

SYNCDATE supports true two-way sync. When you create an event on Calendar A, it appears on Calendar B. When you update that event on Calendar B, the change flows back to Calendar A. Both calendars stay in sync bidirectionally, with deduplication preventing infinite loops.

Keeper's architecture is one-way by design. It pulls from iCal sources and pushes aggregated events to targets. The iCal standard is a read-only feed — you can subscribe to it, but you cannot write back to it. This means Keeper can push your work calendar's busy blocks to your personal calendar, but changes made on the personal calendar do not flow back to the work calendar.

For some use cases, one-way sync is exactly what you need. If you just want your personal calendar to show when you're busy at work, Keeper handles that. But if you need changes to propagate in both directions — the core use case for keeping multiple calendars truly in sync — SYNCDATE's direct API integration is necessary.

Privacy: Two Different Philosophies

Both tools take privacy seriously, but they approach it differently.

Keeper's approach: anonymization by architecture

Keeper strips event details by default. When it aggregates your calendar feeds, it replaces event titles, descriptions, and attendee lists with anonymous "busy" blocks. Your colleagues see that you're unavailable, but not why. This is baked into the architecture — because iCal feeds are the transport layer, Keeper can filter content before it ever reaches a target calendar.

This is genuinely useful. If your primary concern is protecting meeting content while showing availability, Keeper's anonymization is thorough and automatic.

SYNCDATE's approach: privacy by default with flexibility

SYNCDATE shows synced events as "Busy" by default — event details are not exposed to target calendars. You can adjust this in settings if you prefer to share full event details. The key difference is that SYNCDATE has access to full event data (because it connects via the provider API) but chooses not to expose it by default.

SYNCDATE is hosted on Hetzner in Germany (EU), uses AES-256-GCM encryption for OAuth tokens at rest, and does not store event content — it reads event data in transit to create the synced copy, then discards the content. Only event IDs and sync mappings are persisted. Under GDPR, EU-hosted services must comply with strict data protection rules.

SYNCDATE's privacy details

• Hosting: Hetzner, Germany (EU)
• Token encryption: AES-256-GCM at rest
• Event content storage: Not stored (read in transit, discarded)
• Default behavior: "Busy" blocks (no event details exposed)
• CDN: Cloudflare
• Account deletion: Full data removal including synced events, tokens, and logs

Keeper's privacy details

• Hosting: Self-hosted (your infrastructure) or keeper.sh cloud
• Credential encryption: CalDAV credentials encrypted at rest
• Event content: Stripped at aggregation (anonymized busy/free)
• Default behavior: Anonymized busy/free blocks
• License: AGPL-3.0 (auditable source code)

If you want to verify exactly how your data is handled, Keeper's open-source codebase lets you audit the privacy implementation yourself. That's a meaningful advantage for security-conscious users and organizations.

Open Source: Keeper's Unique Advantage

Keeper is licensed under AGPL-3.0 and its full source code is available on GitHub. This offers several concrete benefits:

Auditability. You can read the code that handles your calendar data. For organizations with strict security requirements, this is not a nice-to-have — it's a compliance checkbox.

Self-hosting. Keeper provides a standalone Docker image that bundles the web app, API, cron jobs, Redis, database, and Caddy reverse proxy behind a single port. By hosting Keeper yourself, you get all features for free and maintain full data sovereignty. Your calendar data never leaves your infrastructure.

Customization. If Keeper doesn't do exactly what you need, you can fork and modify it. This is especially relevant for teams with unusual sync requirements or strict data residency policies.

SYNCDATE is not open-source. It's a managed SaaS with published infrastructure details (hosting location, encryption method, data handling approach) but no source code access. For most users, this is fine — you trust the service the same way you trust any SaaS. But for organizations that require source code audits or on-premises hosting, Keeper's open-source model is the clear winner.

As Peer Richelsen, co-founder of Cal.com, has noted about the open-source scheduling ecosystem: "Governments, healthcare, and other highly regulated industries not only prefer but are often required to self-host, which open source makes possible in the most secure and trusted manner." — Peer Richelsen, Co-founder of Cal.com (Cal.com Blog)

The trade-off: self-hosting means you're responsible for uptime, updates, security patches, and infrastructure costs. SYNCDATE handles all of that for you. For a solo developer or small team comfortable with Docker, self-hosting is straightforward. For a non-technical user who wants calendar sync to just work, managed SaaS is simpler.

Pricing Breakdown

SYNCDATE Pricing

No credit card required for the free tier. See the full calendar sync pricing guide for a broader market comparison.

Keeper Pricing

Keeper's self-hosted option is genuinely free with no feature restrictions. The cloud-hosted version at keeper.sh offers a free tier with slower polling and a Pro tier at approximately $3.50/month with faster refresh intervals.

Cost comparison by use case

Freelancer syncing 2 Google Calendars (one-way, privacy blocks only):

• SYNCDATE: Free (EUR 0/year, two-way, 4s sync)
• Keeper self-hosted: Free ($0/year, one-way, requires server)
• Keeper cloud Pro: ~$42/year (~$3.50/mo, one-way, 1-min polling)

Freelancer syncing 2 Google Calendars (two-way sync required):

• SYNCDATE: Free (EUR 0/year)
• Keeper: Cannot do two-way sync (iCal limitation)

Consultant with 5 calendars across 3 accounts (two-way):

• SYNCDATE Starter: ~EUR 24/year
• Keeper: Not applicable (no two-way sync)

The pricing comparison is nuanced. If you only need one-way busy/free aggregation and you can self-host, Keeper is free with no restrictions. If you need two-way sync or webhook-speed updates, Keeper's architecture cannot provide that regardless of pricing tier.

iCal Aggregation: Strengths and Limitations

Keeper's iCal-based approach deserves a deeper look because it determines most of the tool's characteristics.

What iCal does well

iCal (ICS) is a universal calendar format. Nearly every calendar provider — Google, Outlook, Apple, Fastmail, Zoho, and dozens more — can generate an iCal feed URL. This means Keeper can theoretically aggregate calendars from any provider that publishes iCal feeds, without needing a dedicated API integration for each one.

This is genuinely provider-agnostic. While SYNCDATE needs specific API integrations for each provider (currently Google Calendar and Microsoft Outlook), Keeper works with any calendar that has an iCal export URL.

What iCal cannot do

iCal feeds are read-only snapshots. They are not real-time notification channels. The calendar provider generates the feed, and the consumer (Keeper) checks it periodically. This creates several inherent limitations:

No write-back. You cannot push changes back through an iCal feed. Two-way sync is architecturally impossible with iCal alone.

Polling-dependent freshness. The iCal feed only updates when the consumer requests it. Google Calendar's iCal feeds, in particular, can be slow to update — sometimes lagging hours behind actual changes, independent of how frequently Keeper polls.

Lossy translation. iCal feeds do not always include the same level of detail as the native API. Recurring event exceptions, attendee lists, conference links, and custom properties may be absent or simplified in the feed. This is a limitation of the format, not of Keeper specifically.

No deletion detection. When an event is deleted from the source calendar, the iCal feed simply stops including it. The consumer has to infer the deletion by comparing the current feed against previously seen events. This is less reliable than API-based deletion notifications.

For a deeper dive into these architectural differences, see our guide on how calendar sync works and the comparison of webhooks vs polling.

Event Handling Comparison

Recurring events

SYNCDATE syncs recurring events as master events with their full RRULE recurrence pattern, preserving the original timezone in start and end times. Individual instances (exceptions, cancellations) are tracked via the recurring event reference. Editing a single occurrence of a recurring series updates correctly on the synced calendar without breaking the rest of the series.

Keeper inherits whatever recurring event representation the iCal feed provides. In many cases, iCal feeds expand recurring events into individual instances rather than preserving the RRULE. This means the synced calendar may show dozens of individual events instead of a single recurring series — which is less clean and harder to manage.

Timezone handling

SYNCDATE preserves the original timezone attached to each event. If you create an event at "3 PM Eastern," the synced copy also shows "3 PM Eastern" rather than converting it to a different timezone.

Keeper's timezone handling depends on the iCal feed's representation. Most iCal feeds include timezone data, but the fidelity varies by provider.

Deduplication

SYNCDATE uses metadata-based dedup — each synced event carries a unique identifier (calendarSyncId) embedded in the event's extended properties. This prevents the A-to-B-to-A infinite loop problem and handles cross-sync deduplication when the same source event appears in multiple sync processes.

Keeper's one-way architecture largely avoids the dedup problem — since events only flow in one direction (from iCal sources to targets), there's no loop to prevent. However, if you set up overlapping aggregation rules, duplicates can still occur.

Clean exit

SYNCDATE offers a "clean exit" feature: when you delete a sync process, all events that sync created are automatically removed from your target calendars. This makes testing and migration painless.

Keeper's behavior on sync removal is not documented. Events pushed to target calendars likely remain, requiring manual cleanup.

Self-Hosting: What It Actually Involves

If you're considering Keeper's self-hosted option, here's what to expect:

Keeper provides a Docker image (keeper-standalone:latest) that bundles the web interface, API, cron scheduler, Redis, database, and Caddy reverse proxy. On first run, it generates a .env file with session keys and encryption keys for CalDAV credentials.

What you need:

• A server or VPS with Docker installed
• A domain name (for HTTPS via Caddy)
• Basic familiarity with Docker and environment variables

What you're responsible for:

• Server uptime and monitoring
• Security updates and patches
• Backups
• SSL certificate management (Caddy handles this automatically in most cases)
• Scaling if needed

For a developer or small team comfortable with Docker, this is straightforward. For a non-technical user, managed SaaS (whether SYNCDATE or Keeper's cloud offering) removes this operational overhead entirely.

Who Should Choose SYNCDATE

• You need two-way sync (changes flow both directions)
• You want real-time sync (~4 seconds, not minutes)
• You use Google Calendar or Outlook and want native API integration
• You want a managed service with no infrastructure to maintain
• You want EU-hosted data with documented AES-256-GCM encryption
• You need recurring event fidelity (full RRULE sync)
• You want clean event removal when you delete a sync
• You have 2 calendars and want a free tier with no credit card

Who Should Choose Keeper

• You want open-source software you can audit and modify
• You want to self-host for full data sovereignty
• You only need one-way busy/free aggregation (not two-way sync)
• You need to aggregate calendars from providers beyond Google (anything with iCal)
• Privacy anonymization (stripping event details) is your primary requirement
• You're comfortable with Docker and self-hosting infrastructure
• 1-minute (Pro) or 30-minute (Free) polling delays are acceptable for your workflow
• You want to avoid any recurring SaaS cost (self-hosted is free forever)