Skip to content
Skip to main content

Using the Contacts API

Last updated:

The Nylas Contacts API, part of Nylas Connect, provides a secure and reliable connection to your users’ contacts. This enables you to perform bi-directional sync with full CRUD (Create, Read, Update, Delete) capabilities for users’ accounts. The API provides a REST interface that lets you…

  • Read contact information, including names, email addresses, phone numbers, and more.
  • Create, update, and delete native iCloud and Yahoo contacts through CardDAV.
  • Organize contacts using contact groups.
  • Store private application data on Contact objects with Nylas-managed metadata.

By default, Nylas fetches address_book contacts when you make a Get all Contacts request. Use source=domain or source=inbox only when the provider supports that source.

Grant typeaddress_book behaviorOther sources
Google or MicrosoftUses the provider contacts API.inbox and domain availability depends on provider scopes.
EWSUses the provider contacts API.inbox is unsupported.
Native iCloudUses iCloud CardDAV and supports list, create, update, and delete without the inbox feature gate.inbox is separately gated and read-only. domain and compound filters fail.
Native YahooUses Yahoo CardDAV and supports list, create, update, and delete without the inbox feature gate.inbox is separately gated and read-only. domain and compound filters fail.
Generic hosted IMAPAPI-created contacts use address_book. Updating an inbox contact changes it to address_book.Contacts are gated. inbox is parsed from message metadata. Compound address_book,inbox is supported.

The Contacts feature for generic hosted IMAP is gated. When enabled, Nylas builds inbox contacts automatically from the name and email pairs in message from, to, cc, and bcc metadata. Creating a contact through the API always creates an address_book contact. Updating an inbox contact saves the updated contact with source=address_book.

Native iCloud and Yahoo behave differently. Their address_book contacts come from the provider’s CardDAV server, not from email messages, and don’t depend on the gated inbox feature. When enabled, their mailbox-derived inbox contacts are read-only. See the generic hosted IMAP provider guide, iCloud provider guide, and Yahoo authentication guide for setup details.

To get contact information from a user’s inbox, you need the following scopes:

  • Google: contacts.other.readonly
  • Microsoft: People.Read

Native iCloud and Yahoo CardDAV contacts don’t use Google or Microsoft Contacts scopes. Configure the native provider connector and authenticate the grant as described in the iCloud provider guide or Yahoo authentication guide.

To follow along with the samples on this page, you first need to sign up for a Nylas developer account, which gets you a free Nylas application and API key.

For a guided introduction, you can follow the Getting started guide to set up a Nylas account and Sandbox application. When you have those, you can connect an account from a calendar provider (such as Google, Microsoft, or iCloud) and use your API key with the sample API calls on this page to access that account’s data.

To get a list of your user’s contacts, make a Get all Contacts request. By default, Nylas returns up to 30 results. The examples below use the limit parameter to set the maximum number of objects to 5. For more information about limits and offsets, see the pagination references.

To get information about a specific contact, make a Get Contact request with the contact’s ID.

Native iCloud and Yahoo contact IDs start with carddav_v1_. The encoded value contains the contact’s canonical provider href. It doesn’t contain an ETag and doesn’t rely on a Nylas ID mapping.

Treat the ID as opaque, untrusted, and grant-bound. URL-encode it in request paths and never decode it to construct your own CardDAV request. Nylas validates the underlying href against the address books discovered for that grant.

An ordinary update keeps the same ID while the provider href stays stable:

Before update: carddav_v1_<CONTACT_HREF_A>
After update: carddav_v1_<CONTACT_HREF_A>

The Contacts API doesn’t expose an address-book move operation. If the user or provider moves the resource, its href and ID can change. You might observe a deletion for the old ID and an update for the new ID:

Before move: carddav_v1_<CONTACT_HREF_A>
After move: carddav_v1_<CONTACT_HREF_B>

Always persist the latest data.id from an API response or notification. A CardDAV ID is a current locator, not a permanent tombstone: if the provider later reuses the same href, Nylas can return the same derived ID for the new resource.

Many providers let users assign a photo to a contact’s profile. You can access contact profile images by including the ?profile_picture=true query parameter in a Get Contact request.

Nylas returns a Base64-encoded data blob that represents the profile image. To save or display the image, redirect the response to an appropriate file.

Native iCloud and Yahoo CardDAV contacts don’t support profile_picture=true.

To create a contact, make a Create Contact request that includes the contact’s profile information.

Make an Update Contact request with the contact id to change a contact’s details.

Contact metadata stores application data without writing it to the provider contact or vCard. It works for Google, Microsoft Graph, EWS, hosted IMAP, native iCloud, and native Yahoo grants. The metadata belongs to the Contact object only; Contact Group objects and endpoints don’t support it.

You can supply metadata when you create a contact, as shown in the Create a contact sample. Create, get, list, and update responses hydrate the metadata field from Nylas storage.

Send only metadata to update it without changing provider fields:

Metadata updates follow these rules:

  • Omitting metadata preserves the existing object.
  • Supplying an object replaces the whole existing object.
  • Supplying "metadata": {} clears the metadata.
  • Deleting the contact also cleans up its Nylas-managed metadata.
  • Deleting the grant removes metadata stored for its Contacts.

Use one of the indexed keys key1 through key5 with metadata_pair to filter contacts:

You can paginate a metadata query with limit and page_token. You can’t combine metadata_pair with email, phone_number, group, recurse, or a non-default source. If a filtered metadata record points to a provider contact that no longer exists, Nylas removes the stale record while resolving the query.

To delete a contact, make a Delete Contact request with the contact’s id.

Contact groups let your users organize their contacts. You can get a full list of a user’s contact groups by making a Get Contact Groups request.

For native iCloud and Yahoo grants, Nylas returns explicit provider-backed group vCard records only. Address-book collections are containers, not groups, and combined views such as iCloud All Contacts don’t appear. CardDAV group IDs start with carddav_group_v1_; treat them as opaque and grant-bound, and expect the ID to change if the provider moves the group resource.

The Contacts API manages group membership through the groups field on Contact create and update requests, and removes contact membership when you delete a contact. It doesn’t expose endpoints to create, rename, or delete Contact Group resources. Concurrent provider edits can cause a conflict or partial failure during a membership update. Fetch the latest Contact and Contact Groups before retrying. See Work with Contact Groups for provider-specific examples.

Keep the following limitations in mind as you work with the Contacts API.

Native iCloud and Yahoo list responses contain at most 200 Contacts per API page. Nylas rejects an individual provider vCard larger than 1 MB and a CardDAV inventory response larger than 8 MB instead of parsing unbounded provider data.

Native group operations are bounded to 1,000 groups, 9,000 member references per group, 100,000 member references across the result, 10,000 scanned provider resources, 1 MB per group vCard, and 8 MB of group-card data. If provider data exceeds a bound, Nylas returns a provider error.

CardDAV requests can also fail because an ID is invalid or belongs to another grant, authentication, or permissions changed, the provider has no unambiguous writable address book, an ETag conflict occurred, or the provider rate-limited or timed out. Group membership operations can partially change provider resources before an error. Fetch current Contact and Contact Group state before retrying a failed write.

Google doesn’t have a modern push notification API to handle real-time changes to contacts, so Nylas polls for changes every 5 minutes.

  • Microsoft doesn’t support the other type for phone numbers.
  • Contacts can have at most two home phone numbers, two work phone numbers, and one mobile phone number.
  • Contacts can have at most one home physical address, one work physical address, and one other physical address.
  • Contacts can have up to three email addresses.
    • Email addresses have their type set to null by default.
  • Contacts can have a maximum of three instant messenger (IM) addresses.
  • Contacts can have only one work webpage.

Because of the way the Microsoft Exchange protocol works, Nylas applies the following limitations to Exchange contacts:

  • Contacts can have at most two home phone numbers, two work phone numbers, one mobile phone number, and one other phone number.
  • Contacts can have at most one home physical address, one work physical address, and one other physical address.
  • Contacts can have a maximum of three instant messenger (IM) addresses.
    • IM addresses have their type set to null by default.
  • Microsoft Exchange doesn’t support adding contacts on Microsoft Exchange accounts to contact groups.
  • Microsoft Exchange doesn’t support the suffix property on Exchange contacts.
  • Contacts can have up to three email addresses.
    • Email addresses have their type set to null by default.
  • Contacts can have a maximum of three instant messenger (IM) addresses.
    • IM addresses have their type set to null by default.
  • Contacts can have only one work webpage.
  • source=address_book uses native CardDAV. inbox is a separately gated, read-only source; domain and compound sources are unsupported.
  • iCloud contacts support multiple email addresses, phone numbers, physical addresses, IM addresses, and web pages. manager_name, office_location, and profile pictures are unsupported.
  • The first successful CardDAV notification scan establishes a baseline and doesn’t publish historical contacts. Later polling can emit contact.updated and contact.deleted.
  • Provider-originated changes aren’t real-time. Duplicate notifications are possible, and the sync cursor can advance before publication, so the notification feed isn’t an exactly-once or lossless change log.
  • Contact IDs and Contact Group IDs are href-derived locators. A provider-side move can change an ID.
  • Native Yahoo grants use CardDAV for source=address_book. Generic hosted IMAP grants don’t gain Yahoo CardDAV support.
  • A Yahoo contact supports at most one email address and multiple phone numbers, physical addresses, IM addresses, and web pages. Some fields, including manager_name, office_location, and profile pictures, aren’t writable.
  • Yahoo doesn’t emit contact.updated or contact.deleted notifications, including for Contacts API writes.
  • Yahoo rejects the filtered CardDAV group query, so Nylas uses a bounded inventory and addressbook-multiget fallback. Large or conflicting group updates can return provider errors.