Simple Caldav Client Laravel Package

Product Decisions This Supports

• Calendar interoperability as a feature bet. Any roadmap item that reads "sync with the customer's calendar" — meeting scheduling, RSVP tracking, deadline/milestone mirroring in a PM tool, CRM activity sync, resource and room booking, on-call rotation export, course timetabling — needs a CalDAV client or a per-vendor API integration. This package is the cheapest way to answer "does CalDAV get us there?" before committing.
• Build vs. buy at the integration layer. CalDAV looks simple ("it's just iCalendar over WebDAV") and is not: service discovery via PROPFIND, principal/home-set resolution, REPORT queries, XML namespace quirks, ETag/If-Match concurrency, and server-specific deviations (Nextcloud, iCloud, Fastmail, Zimbra, SOGo, Radicale all behave differently). A 21-star package that already absorbs some of that is worth a spike versus 3–6 engineer-weeks of from-scratch protocol work.
• Vendor-neutral positioning. Supporting CalDAV instead of only Google Calendar API or Microsoft Graph lets marketing claim "works with your calendar, including self-hosted." This is a genuine differentiator for EU/public-sector/on-prem buyers who run Nextcloud or Groupware and will never grant OAuth access to a third party.
• A cheap de-risking artifact for a roadmap gate. Time-boxed evaluation produces a real integration prototype and a written protocol-risk assessment, which is far better input to a go/no-go than a spec review.
• Internal tooling and one-off automation. Admin dashboards, migration scripts, "push release dates to the team calendar," and backfill utilities. Here the cost of ownership is near zero and the license question is usually moot.
• Not a decision it should drive: it is a client library only. If the roadmap needs a calendar server, scheduling engine, free/busy computation, or recurrence expansion, this is the wrong tool — that is sabre/dav + sabre/vobject territory.

When to Consider This Package

Consider it when all of the following hold:

• The stack is PHP and you want a dependency-light client, not a framework.
• The integration is internal, self-hosted, or otherwise not distributed to customers as a binary/package, or the product itself is GPL-compatible.
• Scope is modest and human-scale: a few hundred to a few thousand events per account, sync on demand or on a schedule, tolerant of eventual consistency.
• You can live with a small, single-maintainer dependency and are prepared to vendor/fork it — pin the version, keep it behind your own adapter interface, and write contract tests against real servers (a Nextcloud container plus an iCloud/Fastmail sandbox account).
• You accept that you will own the hard parts yourself: retry/backoff, ETag conflict handling, timezone and recurrence handling for display, and credential storage.

Look elsewhere when:

• License is a blocker. GPL-2.0 is copyleft. If you ship on-prem software, an appliance, or an SDK to customers, this contaminates your distribution. Even for SaaS-only delivery — where the GPL generally does not trigger because you are not distributing the software — expect legal review and a maintenance burden. sabre/dav/sabre/vobject (BSD-3) is the pragmatic escape hatch and is the de facto PHP standard with vastly more adoption.
• You need Google or Microsoft consumer/enterprise mailboxes. This is the biggest product trap. Google requires app passwords (2FA-gated) and steers everyone to OAuth; Microsoft does not offer CalDAV for Exchange Online/Outlook.com. If your addressable market is "Gmail and Outlook users," CalDAV is the wrong architecture — plan on OAuth-based Google Calendar API and Microsoft Graph, and treat CalDAV as the self-hosted/EU long tail.
• You need real scale or bidirectional sync semantics — sync tokens, change journals, incremental delta, high event volume, or multi-tenant fan-out. You want a maintained library with an active security and compatibility story, not 21 stars and zero dependents.
• You need rich recurrence rules, attendee scheduling, or free/busy out of the box. Expect to pair any client with a proper iCalendar parser.
• You cannot staff a fork. With 0 dependents and a low opportunity signal, assume no upstream rescue if a target server changes behavior.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can validate a calendar-sync capability in about one engineering week using an existing open-source PHP client instead of building protocol handling from scratch. That buys us a real prototype and a defensible build-vs-buy recommendation before we commit a quarter of engineering. Two caveats drive the recommendation to pilot, don't standardize: the library is GPL-2.0 licensed, which needs legal sign-off before it touches anything we distribute, and it is a small single-maintainer project, so we must treat it as code we may end up owning. It does not change our Google/Microsoft integration path — those require OAuth APIs, not CalDAV. Decision requested: approve a time-boxed spike behind an internal interface, with legal review in parallel.

For engineering (the ask): Wrap it in a CalendarClient interface with our own DTOs so the vendor is swappable to sabre/dav without touching feature code. Pin the exact version, vendor it into the repo, and cover it with contract tests against a Nextcloud container and one hosted provider. Handle If-Match/ETag conflicts, exponential backoff on 5xx and 429, and never store raw credentials in application tables. Log raw XML on failure — you will need it. Budget for us to patch or fork; upstream support is not a dependency we can plan around.

For product: Start with self-hosted and EU calendar providers (Nextcloud, ownCloud, SOGo, Zimbra, Fastmail), where CalDAV is the native, correct protocol and buyers actively prefer it. Treat Google and Microsoft as separate, OAuth-based integrations on their own roadmap line. Set the expectation that "calendar sync" is at minimum two integration tracks, not one — and price the roadmap accordingly.