Practice
CardDAV
CardDAV is the open protocol for syncing address books between devices and a server. Defined in RFC 6352, it layers vCard data over WebDAV and HTTP.
CardDAV answers the question vCard leaves open: a .vcf file moves contacts once, but how do two phones and a laptop stay continuously in agreement? The protocol, standardized as RFC 6352 in August 2011, models an address book as a WebDAV collection on a server in which every resource is exactly one vCard with a UID unique within that collection. Clients create, update, and delete contacts with ordinary HTTP verbs, and the server is the source of truth all devices converge on.
It is the address-book sibling of CalDAV (calendars), and the pairing explains its reach: any platform that wanted open calendar sync usually implemented both. iOS and macOS speak CardDAV natively, Android needs a sync adapter such as DAVx⁵, and on the server side it's the contacts protocol of Nextcloud, Radicale, Baïkal, Fastmail, and most groupware.
For anyone leaving big-platform ecosystems, CardDAV is the practical backbone of contact self-hosting: one server, every device subscribed, no vendor able to revoke access to your own address book.
Anatomy of a CardDAV sync round-trip
A client first discovers the user's address books via well-known URLs and PROPFIND requests, then keeps them current with REPORT queries. Change detection rides on standard HTTP machinery: every contact resource carries an ETag that changes when the vCard changes, and the collection exposes a CTag (or a sync-token, per the RFC 6578 extension) that changes when anything inside changed. A periodic sync therefore costs one cheap comparison; only on mismatch does the client fetch the delta. Writes use PUT with If-Match preconditions, so two devices editing the same contact produce a 412 conflict the client must resolve rather than a silent overwrite — primitive compared to CRDT-style merging, but predictable and debuggable with nothing more than an HTTP log.
Clients and servers that speak it (and the Google asterisk)
Client support is asymmetric across platforms. Apple implemented CardDAV deeply: an account added in iOS or macOS settings syncs system-wide. Android ships no native client, so DAVx⁵ (open source) fills the gap by bridging CardDAV into the system contacts provider. On the server side, self-hosters typically choose between full suites (Nextcloud), minimal Python servers (Radicale, Xandikos), or PHP options (Baïkal); hosted providers like Fastmail and mailbox.org include it. Google Contacts technically exposes a CardDAV endpoint, but with quirks and historically incomplete field mapping — most people sync Google contacts through Google's own APIs instead. Interop bugs cluster in vCard dialects, not the protocol: servers store what clients PUT, and two clients disagreeing about photo encoding blame each other via the server in the middle.
Where Endearist is meant to sit relative to CardDAV
CardDAV syncs the fields of a contact; a personal CRM cares about the relationship around those fields — interaction notes, reminders, how you met — which the vCard data model was never built to carry. Endearist, our own app in development, is therefore not meant to replace your CardDAV setup: it is planned to import the vCards any CardDAV server or client can export and to keep its relationship layer local-first on your device, with optional end-to-end encrypted sync over a folder or WebDAV server you run; a managed EU-hosted option is planned only for after the first release. Plaintext-readable server storage is exactly what classic CardDAV gives its operator; for notes about your closest people, the planned E2E design means the sync storage would only ever hold data it cannot read. The two can coexist cleanly: CardDAV for the phone-dialing layer, a personal CRM for the remembering layer.
End-to-end encrypted sync over storage you run yourself — a local or shared folder, or a WebDAV server — is planned for v1. Google Drive as a destination is not decided yet. Managed sync on Endearist Cloud is planned for after v1, as part of the Pro Cloud subscription only.
Frequently asked questions
- What's the difference between CardDAV and CalDAV?
- Same architecture, different payload. Both extend WebDAV over HTTP and use ETags and sync tokens for change detection; CalDAV (RFC 4791) carries iCalendar data for events and tasks, while CardDAV (RFC 6352) carries vCard data for contacts. Most servers and most native clients implement the pair together, which is why one Nextcloud or Fastmail account typically syncs your calendar and address book through sibling endpoints.
- Does Android support CardDAV out of the box?
- No. Stock Android ships sync adapters for Google accounts but no generic CardDAV client. The standard solution is DAVx⁵, an open-source app that registers your CardDAV (and CalDAV) accounts with the system, after which any contacts app on the phone reads and writes them like native data. iOS, by contrast, has supported CardDAV accounts natively in its settings since iOS 4.
- Can I self-host a CardDAV server?
- Yes, and it's one of the easier self-hosting projects. Radicale runs as a small Python service ideal for a Raspberry Pi or VPS; Baïkal offers a lightweight PHP alternative; Nextcloud bundles CardDAV into a full personal cloud. Point iOS settings or DAVx⁵ at the server URL with your credentials and every device converges on your own hardware. Remember backups — being your own provider means being your own disaster recovery, too.
Last updated: 2026-09-30
Tend relationships, not records.
Join the launch list: one email when it opens. Platforms, plans and capabilities need their own approval; signup creates no app access or purchase.
Join the launch list