caldav.icloud.com: iCloud CalDAV Settings

Command references used in this guide: nylas auth login, nylas calendar list, and nylas calendar events list.

What are the iCloud CalDAV server settings?

The iCloud CalDAV service runs at caldav.icloud.com over HTTPS on port 443, speaks the CalDAV protocol defined in RFC 4791, and accepts only app-specific passwords for third-party clients. Apple maintains a settings page for iCloud Mail but publishes no CalDAV equivalent, which is why every value below matters enough to bookmark.

One behavior trips up first-time testers: a plain browser-style request to the server returns an empty HTTP 400, not a login page. That's expected — the server answers WebDAV verbs like PROPFIND and REPORT, not GET /. A 400 from caldav.icloud.com means the host is reachable and you're speaking the wrong verb, not that the service is down.

Why does iCloud CalDAV reject my Apple Account password?

Third-party CalDAV clients can't sign in with your regular Apple Account password — they need an app-specific password generated at account.apple.com. Apple's documentation describes them as passwords that "allow you to sign in to your Apple Account in apps made by developers other than Apple," generating one requires two-factor authentication, and an account can hold up to 25 active app-specific passwords.

Practical consequences for calendar tooling: a 401 from caldav.icloud.com with credentials you know are right almost always means a regular password was used where an app-specific one belongs. Give each integration its own generated password so one client can be revoked without breaking the rest. And per the same Apple page, "any time you change or reset your primary Apple Account password, all of your app-specific passwords are revoked automatically" — the silent breakage behind most sudden CalDAV sync failures.

How do you discover your calendar URL with PROPFIND?

CalDAV clients don't guess calendar URLs — they discover them. The flow defined by RFC 4791 and the well-known URI convention takes 2 requests: ask the server who you are (current-user-principal), then ask that principal where its calendars live (calendar-home-set). On iCloud the home set lands on a numbered partition host like p67-caldav.icloud.com; that partition number is per-account, which is why hardcoding another user's URL fails.

# Step 1: who am I? (current-user-principal)
curl -s -X PROPFIND "https://caldav.icloud.com/" \
  -u "you@icloud.com:app-specific-password" \
  -H "Depth: 0" -H "Content-Type: text/xml" \
  --data '<propfind xmlns="DAV:">
    <prop><current-user-principal/></prop>
  </propfind>'

# Step 2: where are my calendars? (calendar-home-set, against the
# principal path returned by step 1)
curl -s -X PROPFIND "https://caldav.icloud.com/PRINCIPAL_PATH/" \
  -u "you@icloud.com:app-specific-password" \
  -H "Depth: 0" -H "Content-Type: text/xml" \
  --data '<propfind xmlns="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav">
    <prop><c:calendar-home-set/></prop>
  </propfind>'

From the calendar home you can list individual calendars (another PROPFIND at Depth: 1) and fetch events as raw iCalendar objects. At that point you're writing an XML-parsing CalDAV client — roughly the moment most projects decide the protocol isn't the product and look for a higher-level interface.

How do calendar subscriptions differ from CalDAV sync?

A subscription is a read-only one-way feed (webcal/ICS), while CalDAV is full two-way sync — and iCloud supports both. Apple's calendar subscription documentation covers adding feeds to iCloud so they appear across your devices. Subscriptions are the right tool for consuming an external schedule (a team roster, a sports feed); CalDAV is the right tool when a client needs to create and edit events.

The distinction matters for automation: an ICS subscription updates on the provider's refresh schedule, often hours apart, while a CalDAV client (or an API-backed CLI) reads current state on demand. If a script needs to know what changed in the last 5 minutes, a subscription feed is the wrong transport.

How do you read iCloud calendars without a CalDAV client?

The CLI route replaces the whole PROPFIND-and-XML stack with one OAuth-style connection and JSON output. nylas auth login walks through connecting the iCloud account (using the same app-specific password mechanism under the hood, once), and after that every calendar read is a single command — no partition hosts, no principal paths, no iCalendar parsing.

# Connect iCloud (one time)
nylas auth login

# List calendars — the CalDAV calendar-home-set equivalent, as JSON
nylas calendar list --json

# Events for the next 14 days
nylas calendar events list --days 14 --json | jq '.[] | {
  title: .title,
  start: .when.start_time,
  organizer: .organizer.email
}'

The same 3 commands work unchanged against Google and Microsoft accounts, which is the practical difference between configuring a protocol and using an abstraction. For the full iCloud calendar workflow (shared calendars, read-only feeds, availability), see the iCloud Calendar CLI guide.

Next steps

• iCloud Calendar CLI: Manage Events — create, update, and check availability on iCloud calendars
• Calendar API Compared: Google, Microsoft, CalDAV — where CalDAV fits against the REST APIs
• Sync calendars across providers — keep iCloud, Google, and Outlook calendars aligned
• iCloud Mail API alternative — the equivalent story for iCloud email access
• Full command reference — every calendar subcommand documented