# Connect iCloud Mail, Calendar, and Contacts

Canonical: https://figment.so/icloud-connect

iCloud Mail, Calendar, and Contacts are services Apple documents an account authorization path for in support of third-party app access. Each speaks an open standard — IMAP/SMTP for mail, CalDAV for calendar, CardDAV for contacts — and Apple documents two distinct authorization paths for connecting them. The choice affects what credential the app holds, what the user experience looks like at setup, and how access gets revoked later.

## Two authorization methods Apple documents

**Account authorization.** The user enters their Apple Account email address and an Apple prompt asks them to click Allow. The app receives an authorization grant and never receives or stores the Apple password. This is the method Apple recommends for apps that support it. To revoke, the user goes to account.apple.com → Sign-In and Security → Account Data Sharing → Remove access ([Apple Support](https://support.apple.com/en-us/121539)).

**App-specific passwords.** For apps that do not support account authorization, the user generates a dedicated app-specific password at account.apple.com → Sign-In and Security → App-Specific Passwords. The app stores that password as a credential. Two-factor authentication must be active on the account before an app-specific password can be generated. Apple allows up to 25 active app-specific passwords per account; each can be revoked individually or all at once. App-specific passwords are reusable credentials that remain valid until explicitly revoked; changing the primary Apple Account password automatically revokes all active app-specific passwords ([Apple Support](https://support.apple.com/en-us/102654)).

Both are Apple-described options for accessing these services. Actual access depends on the app and the applicable approvals.

## Which to use

| Scenario | Method | Credential the app holds | Revocation path |
|---|---|---|---|
| App that prompts user to click Allow | Account authorization | Authorization grant — no Apple password | Account Data Sharing → Remove access |
| Legacy client without authorization support | App-specific password | App-specific password stored by app | App-Specific Passwords → Revoke |
| Automated server-side integration | Depends on the app's supported auth method | Varies by method | Varies by method |
| New integration | Depends on supported method and enrollment status | Varies by method | Varies by method |

When an app migrates from app-specific passwords to account authorization, Apple recommends revoking any previously active app-specific passwords for that app once the new authorization is in place.

## Apple developer enrollment

Account authorization for third-party apps is a capability Apple enables through a separate enrollment process. To request access for your app, submit a request at [developer.apple.com/contact/request/icloud-oauth2/](https://developer.apple.com/contact/request/icloud-oauth2/). That page requires an Apple developer sign-in; eligibility and approval terms must be confirmed with Apple directly.

This enrollment is separate from Sign in with Apple, which authenticates a user's identity rather than granting data access.

## Protocol settings

**Mail — IMAP and SMTP**

Apple's setup guide for third-party client configuration specifies an app-specific password for IMAP and SMTP authentication ([Apple Support](https://support.apple.com/en-us/102525)):

| Direction | Server | Port | Encryption |
|---|---|---|---|
| Incoming (IMAP) | imap.mail.me.com | 993 | SSL required |
| Outgoing (SMTP) | smtp.mail.me.com | 587 | SSL / STARTTLS |

The IMAP username is typically the short name of the iCloud address — for example, `johnappleseed`. If the short name does not connect, the full address (`johnappleseed@icloud.com`) may work as a fallback. The SMTP username is always the full iCloud email address. POP access is not supported.

**Calendar — CalDAV and Contacts — CardDAV**

iCloud Calendar uses CalDAV and iCloud Contacts uses CardDAV, both open protocols. Compatible clients that support the authentication method Apple requires for these services can connect through those protocols.

## Figment Apple Connect

Figment Apple Connect is a separate product layer. When a user opens an app's OAuth consent prompt, they sign into Figment, select an existing Apple connection, and approve the app's requested scope. Apple account sign-in and trusted-device approval occur earlier, during the separate Mac connection-setup process — not on the Figment consent screen. Your app receives a scoped Figment grant through a standard OAuth 2.0 + PKCE flow; it never receives or stores the Apple password.

Connection state is tracked per service and reflects current evidence from the connector. A service must report `ready` before operations on it are attempted; non-ready services reject operations, and state can change between a status check and the next request. Revoking one app's grant stops that app's access only. Disconnecting the Apple connection stops every grant and queued operation tied to that connection.

Figment's iMessage API is a distinct product that operates on messages available on a connected Mac; it is separate from the IMAP/SMTP, CalDAV, and CardDAV protocol paths described on this page. For Calendar, Contacts, and Reminders, Figment currently provides a synthetic sandbox environment; live native access for those services is not available to customers in this release.

Register your app at [figment.so/apple-connect/developers](https://figment.so/apple-connect/developers). Users can review and remove app grants at [figment.so/apple-connect/account](https://figment.so/apple-connect/account).

## Pricing

Figment Apple Connect is **$29 per month per active live connection**. Sandbox access is free; sandbox returns synthetic data and does not interact with live Apple services. The first hosted checkout covers one connection. Access starts after setup. Mac rentals are a separate product.

---

[**Connect Apple Account →**](https://figment.so/apple-connect/developers)