Set-up guide
Connect a CalDAV calendar or CardDAV contacts, with one address.
Fastmail, iCloud, Nextcloud, StackMail, Zoho, or a server of your own. If it publishes a CalDAV or CardDAV address, a mailbox that signs in with a password can have its diary and its address book connected to Claude, ChatGPT or any MCP client. Here are the addresses, the one password trap that costs people an afternoon, and what is never stored.
- Time About 2 minutes each
- You will need Address and password
- Contacts stored here None, ever
The short version
Connect the mailbox first. Then open its Connection tab in the control panel, and paste the CalDAV address into the calendar card and the CardDAV address into the address book card, with an app password where the provider wants one.
Each server is opened before anything is saved. A refusal stores nothing, and says which of the address and the password was the problem.
The tools then appear on the connector already in your AI client.
Before you start
What you need: a password mailbox, an address and an app password
A calendar and an address book are separate services from the mail, with credentials of their own, so connecting the mailbox connects neither. This is the second step, and the shorter one.
- A mailbox that signs in with a password Gmail by app password, or any IMAP host
- The address of the calendar or contacts server from your provider, or below
- An app password for that server on the hosted providers that want one
- A second account with us nothing
- A second connector in your AI client nothing
- Anything installed nothing
-
Gmail or any IMAP host: this page.
The route here is for a mailbox that signs in with a password: Gmail by app password, or any IMAP host.
A diary or an address book anywhere but Google and Microsoft, which is most of the market, connects here.
-
Microsoft 365: nothing to give here.
A Microsoft 365 mailbox gets its calendar on the same sign-in as its mail, and its Outlook contacts with it, so it has no address to give here.
-
A Google diary or Google contacts: a sign-in.
A Google diary takes a Google sign-in of its own, on any mailbox, from the Gmail page. So do Google contacts, on a mailbox that uses a password.
Where to look
Find your CalDAV and CardDAV address: Fastmail, iCloud, Nextcloud, StackMail, Zoho
These are the addresses for the 5 hosts most people will need. It's the server on its own, filed under calendar sharing, CalDAV or CardDAV in your provider's settings, and not the webmail address.
Most searches for how to connect CalDAV calendar or CardDAV contacts servers to an AI end on a page of addresses. The addresses are here, and so is the reason they get refused.
| Provider | Calendar (CalDAV) | Address book (CardDAV) | Password it wants |
|---|---|---|---|
| Fastmail | https://caldav. |
https://carddav. |
App password |
| iCloud | https://caldav. |
https://contacts. |
App-specific password |
| Nextcloud | https://your-server/ |
https://your-server/ |
Account or app password |
| StackMail | https://calendar. |
https://calendar. |
Mailbox password, on premium |
| Zoho | https://calendar. |
https://contacts. |
Account or app password |
Some hosts publish the address as a path rather than a bare host, with your own mailbox address in it in place of the example one. The table shows which.
Each address is read off the provider's own page where one exists, and each hosted bare host was opened from this product without a credential, to confirm it answers as a working server does. The sources say which is which.
Which password each one wants
- Fastmail. An app password, made under Settings, Privacy & Security, with the Calendars and Contacts scopes ticked. The account password is refused.
- iCloud. An app-specific password, made at account.apple.com under Sign-In and Security, which Apple issues only on an account with two-factor authentication on (the default on most Apple Accounts). The username is the full Apple Account email address.
- Nextcloud. Your Nextcloud password, or an app password made under Settings, Security, which a server with two-factor authentication on requires.
- StackMail. The mailbox password, once the mailbox is upgraded to premium in the hosting control panel; a standard mailbox refuses the correct address with a 401.
- Zoho. Your Zoho password, or an application-specific password where two-factor authentication is on. The host differs by data centre: .eu, .in, .com.au and others.
A self-hosted server: Nextcloud, Baikal, Radicale
A Nextcloud server publishes both under
https://your-server/; the
form its manual gives a phone is that path with
principals/users/<username>/ on the end.
Baikal and Radicale publish one address for both protocols too. And any
server that follows RFC 6764 can be given its bare host: we ask for
/.well-known/caldav or /.well-known/carddav and
follow the redirect.
If your host is not on the list
Search the provider's help for its name and "CalDAV" or "CardDAV", or copy the address out of an app that already syncs with it. With a web host or a domain registrar it's very often the mail hostname with the word calendar in front of it, and a guess costs you seconds.
Walkthrough
Connect the calendar and the address book, step by step
2 cards on one tab, and the same 3 things for each: an address, a password, and a button.
-
Find the CalDAV or CardDAV address your provider publishes
Take it from the table above, from the provider's help pages under CalDAV or CardDAV, or from a calendar or contacts app that already syncs with the account. It starts with
https://. -
Make an app password with the calendar and contacts scopes
In the provider's security settings, make an app password and tick the calendar and contacts scopes where it offers them (an app-specific password, on iCloud).
A host whose row in the table says the mailbox password takes that instead.
-
Paste the calendar address into the calendar card
In the control panel open the mailbox, then its Connection tab, and paste the CalDAV address into the calendar card.
If the calendar signs in with different details from the mailbox, open My calendar signs in with different details from the mailbox and enter them there. Choose Connect the calendar, and the card lists the tools that server supports.
-
Paste the address book address into the address book card
Same tab, the card beside it. Paste the CardDAV address, open the sign-in details only if the book uses its own, and choose Connect the address book.
The card then says how many address books it found, and whether they can be written to.
-
Check both from your AI client
Ask your assistant what's in the diary on Thursday, then for the phone number of somebody who's in your address book and not in your mail. The second answer comes off a card, and says which book.
The trap
The app password trap: a 401 is the account password working as designed
Nothing is broken. Fastmail and iCloud refuse the account password on purpose and want an app password instead, and Zoho does the same once two-factor authentication is on.
Most people's first go: copy the CalDAV address off the provider's help page, paste it in with the password you sign in to webmail with, and get a 401. Check the address, try the password again, and 20 minutes later conclude the thing is broken.
It isn't. A 401 from one of these providers is the rule working as the provider designed it.
We measured it rather than read about it. On 2
September 2026 a probe of
https://caldav. with the
account password answered 401. About a minute later, Fastmail emailed
the account to say a third-party calendar app had just tried to sign
in and failed, because the regular password does not work with
third-party apps.
Fastmail's own server-names page says the same: you cannot use your regular password. iCloud's app-specific password is the same rule, and Apple issues one only on an account with two-factor authentication on, the default on most Apple Accounts in Apple's words. The address was never the problem.
What a CalDAV app password is, and where it comes from
An app password is a second password the provider issues for one app. You make it in the account's security settings, and you can revoke it there without touching the password you sign in with.
Where each host keeps the setting is in the list under the address table. On Fastmail, tick the Calendars and Contacts scopes.
It's the kind of password you'll already have made to connect a Gmail mailbox, without Google's habit of hiding the setting: the hosted providers here that want one all offer it.
401 and 403 are 2 different answers
The connect form tells you which of the address and the password was refused, and the 2 codes behind that sentence want 2 different fixes.
-
401 means the credential was refused.
Make an app password, or check that you used it rather than the account one.
A few hosts only switch CalDAV and CardDAV on for a paid mailbox tier, and answer 401 on the correct address until then. That looks exactly like a wrong password.
-
403 means the credential worked and was not allowed in.
The app password was made without the calendar or contacts scope. Make another with the scope ticked.
The same sentence reaches you later, too. A credential the server stops accepting after it was stored marks the card, emails you once, and opens the sign-in details for the new one.
Why Gmail is not on this page
Google's calendar and contacts endpoints take OAuth 2.0 and nothing else. Google's own CardDAV documentation says so in one sentence: it does not support any other authentication method.
So a Gmail app password, which opens the mail over IMAP, is refused on Google Calendar and Google Contacts. That's why a Google diary has a route of its own, and so do Google contacts: a Google sign-in, not an address.
A Gmail mailbox can take a CardDAV address book at another host instead, one book at a time.
The diary
The CalDAV calendar: one address, and the tools your server answers for
No second account, no second connector, nothing extra to pay. Giving us the calendar server's address is the whole job.
IMAP is a mail protocol with no diary inside it. What most hosts run beside the mail server is a calendar server speaking CalDAV, defined by RFC 4791 in 2007 as a store of iCalendar entries, with an address of its own.
What you get is decided by asking your server
CalDAV is 2 specifications 5 years apart: the store, and the scheduling RFC 6638 added in 2012. A server with only the first will accept a meeting with people invited, answer that it worked, and tell nobody.
So at the moment the calendar connects, we ask what it implements, and hand your assistant only the tools it answered for. A store-only calendar gets reading, searching and your own time. One that implements scheduling gets the meeting tools as well.
The calendar card shows the list your server gave, and Check it now asks again.
How it compares with Google and Microsoft
CalDAV is the route for a diary on any host but Google and Microsoft. Against Google's route, it needs an address and an app password rather than a sign-in.
Against Microsoft 365, its tool list is measured rather than complete: the structured counter-proposal, the ranked meeting suggestions and the out-of-office are Microsoft's alone.
Which of the 3 calendar routes is yours and what an assistant can be trusted with once a diary is connected are each a guide of their own.
The contacts
The CardDAV address book: looked up where it lives, never copied
Nothing about a contact is written down here. A card is fetched from your own server when your assistant asks, and forgotten.
The same servers usually hold an address book too, speaking CardDAV, the sister protocol RFC 6352 defined in 2011 for contacts in vCard form. The address book card sits beside the calendar card and takes the same one field.
On Fastmail and iCloud one app password covers mail, calendar and contacts, so the sign-in details can usually be left alone. On iCloud the username is the full Apple Account address, so open them where that isn't the mailbox address.
What the book adds
Until a book is connected, your assistant resolves a person's address from the mailbox's own history, ranking somebody you've written to above somebody who merely wrote to you. That stays.
What the address book adds is the people you put there yourself, with every address, the phone numbers, the postal addresses with their postcodes, the employer and the job title on the card, ranked above anything the mail turned up.
Ask what Bob's number is, or where to send the parcel, and the answer comes off his card.
Your webmail's own contacts list may not be the book
The address book this connects to is the CardDAV one, the list a phone or a desktop client syncs to. Some webmail programs keep their own contacts list inside webmail, separate from it, and that list is not read.
If yours does, export it as a vCard file and get it into the book.
Either use a CardDAV client, or email the file to yourself (or drop it
on an upload link your assistant makes) and ask your assistant to
import it. import_contacts does that
from the attachment, each card once.
The assistant still finds people from your mail history either way.
Looked up, never copied
A card is fetched from your own server to answer the question asked, held in memory for about 10 minutes so the next question about the same person is quick, and forgotten.
Thunderbird keeps a copy of a CardDAV book on the device, the right design for an offline client. At least one mainstream AI mail client states in its privacy policy that it syncs a copy of your Google Contacts to its servers.
This is neither. It's the relationship a mail client's address lookup has with a company directory, and nobody thinks the directory has been copied.
Afterwards
What your assistant can then do with the calendar and the address book
-
With the calendar.
Read the week and search it by subject, location or organiser. Open one event with everybody invited and how each answered. Ask when a group of people are free, and get back busy blocks rather than their diaries.
Book your own time, move it, repeat it weekly. Where the server implements scheduling, invite people to a meeting, reschedule or cancel it and tell everybody, and answer an invitation. A recurring meeting appears on every date it falls on, the way it does in Outlook.
-
With the address book.
Find a person by name, nickname, part of an email address or employer. You get back the address to write to, the phone numbers, the postal addresses, the employer and the job title, ranked above whatever the mail turned up.
Then write to that address, or put that person in a meeting, in the same conversation.
-
Open one card in full.
read_contactopens a card: every name, every email address with its type, every phone number with its type, the postal addresses with their type (home, work or other), each with street, town, county or region, postcode and country, the employer, the job title and the note, and which book it is in.A postal address is a field you read and write, never a search term: a search still matches names, nicknames, email addresses and employers, so "who do we know in Glasgow" is not a question it answers.
-
Keep the book right, where it can be written to.
On a book that lets the sign-in you gave write to it, which is checked when the book connects,
create_contactadds a card andupdate_contactcorrects one, at Draft and file.delete_contactremoves one, at Send and delete, and a compliant client asks first, naming the person.import_contactsbrings a vCard export into the book from a message in the mailbox, each card once. -
Every write lands on your own server, and none is forced.
Every one is written to your own contacts server, so the change shows in your phone and your mail client exactly as if you had typed it there. A book that can only be read offers none of them.
Every one carries a precondition, so a card your phone changed in the meantime is refused rather than written over. A correction leaves the photo, the birthday and every field it does not name as they were.
Adding a card is the one to ask for once: a second call files a second card. So after a timeout, the assistant checks with
find_contactrather than trying again.
The book doesn't replace the mailbox's own evidence; it sits above it. Both sources are read on every lookup, and the answer says which is which.
| Where the person is found | Rank | What comes back |
|---|---|---|
| In your CardDAV address book | First, where a book is connected | Every address, the phone numbers, the postal addresses, the employer, the job title, and a reference that opens the card |
| An address you have sent to | Next | The address, how often you have written to it, and when it was last seen |
| An address that only ever wrote to you | Last | The address and when it was last seen, marked as not yet confirmed |
What each tool does is on the tool reference, and how a calendar connects is on the how-it-works page.
The free tier is 5 calls a day on any mailbox, enough to connect both and ask what is on Thursday and what Bob's number is.
Limits
What is never stored, and where this connection stops
The address of each server and a credential for it are the whole of what is stored. Everything else here is never written down, written only where you asked, or not built yet.
-
Contacts are looked up, never copied
Your address book stays where it is.
Where the mailbox has one (its Outlook contacts on a Microsoft 365 sign-in; on a mailbox that uses a password, your Google contacts by a Google sign-in of their own, or a CardDAV book you connect by its address), a person is looked up in it when you ask, held in memory for about 10 minutes, and forgotten: nothing about a contact is written to a database, a file or a log of ours.
On a mailbox with no book, addresses are resolved from the mailbox's own history. There is no file store either: an attachment is read and sent on the message it belongs to rather than kept anywhere as a document of its own.
-
The address and a credential, and nothing else
A calendar's or an address book's address and, where you gave one, a username and password for it, encrypted as every credential is. Disconnecting either deletes its credential that minute, and revoking the app password at your provider ends access the same way. The privacy policy and the security page list it beside everything else held.
-
Photos are never read into an answer
A card comes back as names, email addresses, phone numbers, postal addresses, employer, job title and note. On a look-up the photograph is not requested, one a server sends anyway is discarded, and the answer says so.
On a card you ask the assistant to correct, the whole card, photograph included, passes through in memory for that one request and is written back exactly as it was, never shown to the assistant and never held.
-
Writes only where the book allows them
Adding, correcting, deleting and importing a card register only on a book that lets the sign-in you gave write to it, checked when it connects; a read-only book keeps the one tool that opens a card.
A correction or a delete lands on the card as it was just read, and is refused, never forced, if another device changed it since. Deleting needs Send and delete. Every write goes to your own contacts server, and nothing of the card stays here.
-
Password mailboxes only
This route is for a mailbox that signs in with a password. A Microsoft 365 mailbox brings its Outlook contacts with the mail, on the same sign-in, so there is no address to give and nothing to connect. That route is on the Microsoft 365 page. Google contacts connect with a Google sign-in rather than an address, on the Gmail page, and a mailbox has one address book at a time: a CardDAV book or its Google contacts.
-
One server address each
A mailbox holds one calendar address and one address book address, and every calendar or book that server exposes under it is read. A second server needs a second mailbox.
FAQ
Questions people ask about CalDAV and CardDAV
Does connecting a CardDAV address book copy my contacts to your servers?
No. The address book stays on your own contacts server; what we store is its address and a credential for it. When your assistant looks somebody up, our server asks your contacts server that one question, keeps the answer in memory for about 10 minutes, and then forgets it. Nothing about a contact is written to a database, a file or a log of ours, and disconnecting the book deletes the credential and leaves the book untouched.
Why does my CalDAV or CardDAV server answer 401 when the password is right?
Because the account password is the wrong kind of password, and the 401 is the server working as designed. Fastmail and iCloud refuse your webmail password outright, and Zoho does once two-factor authentication is on; each wants an app password, with the calendar and contacts scopes, pasted into the sign-in details. A few hosts also answer 401 until CalDAV and CardDAV are switched on for a paid mailbox tier. A 403 means the app password worked but lacks the scope.
Is the contacts list in my webmail the address book?
Not necessarily. This connects to the CardDAV book, the list a phone or a desktop client syncs to. Some webmail programs keep a separate contacts list inside webmail, and that list is not read. Export it as a vCard file and email it to yourself, then ask your assistant to import it: import_contacts does that from the attachment, each card once, on a book the sign-in may write to.
Does iCloud need an app-specific password for CalDAV and CardDAV?
Yes. Apple's own instructions say that a third-party app that wants your iCloud calendar or contacts signs in with an app-specific password, made at account.apple.com under Sign-In and Security, never with your Apple Account password, and Apple issues one only on an account with two-factor authentication on, its default for most accounts. The username is your full Apple Account email address, and one app-specific password covers the calendar at https://caldav.icloud.com/ and the address book at https://contacts.icloud.com/.
Can I connect my Gmail calendar or Google contacts this way?
Not over CalDAV or CardDAV: Google's own documentation says it supports no authentication method other than OAuth 2.0 on those endpoints, so a Gmail app password is refused there. A Google Calendar connects with a Google sign-in from the Gmail connect page, on any mailbox, and Google contacts have a Google sign-in of their own on the same page. A Gmail mailbox can connect a CardDAV address book at another host instead; it has one address book at a time.
What tools appear once a calendar or an address book is connected?
For the calendar, whatever that server turned out to support: the list is measured when it connects and shown on the calendar card. For the address book, read_contact on every book, and create_contact, update_contact, delete_contact and import_contacts as well where the sign-in you gave may write to it. find_contact also reads the book on every call and ranks a person from it first. All of them appear on the connector already in your AI client.
Can the assistant add, correct or delete a contact?
Yes, on a book the sign-in you gave can write to. A connection at Draft and file can add a card, correct one and import a contacts file; deleting a card needs Send and delete, and a compliant AI client stops and asks first, naming the person. Each change is written to your own contacts server, and a correction or a delete is refused rather than written over if the card changed on another device since it was read.
Are contact photos read?
Never into an answer. On a look-up the photograph is not requested, one a server sends anyway is discarded, and the answer says photos are not read. On a card you ask the assistant to correct, the whole card, photograph included, passes through our server's memory for that one request and is written back exactly as it was; it is never shown to the assistant and never held. The data processing agreement states the same.
Attribution
Sources
- RFC 4791: Calendaring Extensions to WebDAV (CalDAV) The calendar store, March 2007; scheduling is RFC 6638, 2012, and a server may implement the first without the second.
- RFC 6352: CardDAV, vCard Extensions to WebDAV The address book protocol, August 2011, over vCard.
- RFC 6764: Locating Services for CalDAV and CardDAV The .well-known/caldav and .well-known/carddav paths a bare host is asked for.
- Fastmail: server names and ports Both addresses, and the sentence that the regular password cannot be used. Read 16 September 2026.
- Apple Support: sign in to apps with your Apple Account using app-specific passwords The app-specific password a third-party app signs in with, where it is made, and the two-factor requirement. Apple names no hosts; both above answer their .well-known path from this product. Read 16 September 2026.
- Nextcloud user manual: synchronising with iOS The remote.php/dav/principals/users/<username>/ address the manual gives a phone for both protocols; the bare remote.php/dav/ above is the endpoint it sits under. Read 16 September 2026.
- Zoho Calendar: setting up CalDAV sync The CalDAV address, the host varying by data centre, and the application-specific password once two-factor is on. Read 16 September 2026.
- Zoho Contacts: CardDAV The CardDAV address for each data centre, and the same password rule. Read 16 September 2026.
- Google: manage contacts with the CardDAV protocol The sentence that keeps Gmail off this page: Google does not support any authentication method other than OAuth 2.0.
- Shortwave: privacy policy The AI mail client behind "at least one": its policy states that it syncs your Google Contacts, with access to your contacts' names, profile pictures and email addresses. Read 16 September 2026.
StackMail publishes no page about its CalDAV and CardDAV addresses. Both were opened from this product with a real credential, the calendar on 2 September 2026 and the address book on 16 September 2026. The premium tier and the path are the owner's own mailbox, settled the day after the first opening, rather than a document.
So is the webmail contacts list the book does not hold: on 16 September 2026 that mailbox's webmail contacts page was read beside its CardDAV book, 1 entry against 0 cards, before and after the entries were edited in webmail.
Connect the calendar and the address book.
The free tier is 5 calls a day on any mailbox, and disconnecting a calendar or an address book deletes its credential and leaves your diary and your contacts exactly as they were.