&metadata_pair=key1:on-site`\n\nYou can't create a query that includes both a provider and metadata filter, other than `calendar_id`. For example, `https://api.us.nylas.com/calendar?metadata_pair=key1:plan-party&title=Birthday` returns an error.\n\n## Reduce response size with field selection\n\nField selection allows you to use the `select` query parameter to specify which fields you want Nylas to include in the response.\n\nYou can use field selection for all Nylas API endpoints, _except_ the following:\n\n- All `DELETE` endpoints.\n- All Attachments endpoints.\n- All Smart Compose endpoints.\n- The Send Message endpoint.\n- The Create a Draft endpoint.\n\nField selection helps to reduce the size of the response, improves latency, and helps you avoid rate limiting issues. You can also use it in cases where you want to avoid working with information from your users that you think might be sensitive.\n\nField selection can evaluate top-level object fields only. You cannot use it to return only nested fields.\n\n\U0001F4DD Note: Nylas strongly suggests you always use field selection, so you only get the data that you need.
\n\nFor example, the following request specifies Nylas should return only the `id` and `name` fields of the Calendar object.\n\n```bash\ncurl --request GET \\\n --url 'https://api.us.nylas.com/v3/grants/me/calendars?select=id,name'\n```\n\nThe response payload includes only the `id` and `name` fields in the `data` object, as in the example below.\n\n```json\n{\n \"request_id\": \"5fa64c92-e840-4357-86b9-2aa364d35b88\",\n \"data\": [\n {\n \"id\": \"5d3qmne77v32r8l4phyuksl2x\",\n \"name\": \"My Calendar\"\n },\n {\n \"id\": \"5d3qmne77v32r23aphyuksl2x\",\n \"name\": \"My Calendar 2\"\n }\n ]\n}\n```\n\n## Nylas encoding\n\nResponse bodies are always UTF-8 encoded JSON objects, unless explicitly documented otherwise.\n"
contact:
url: https://www.nylas.com/
x-provenance:
method: harvested
first_party: true
publisher: Nylas
source: https://developer.nylas.com/_spec-files/nylas-api.yaml
harvested: '2026-08-21'
sha256: 7ff001d571e163b1ffe22178741b59f813d8208ec878157a839a33dc2c13fd35
bytes: 1666223
note: 'Published by Nylas as the unified contract for the Nylas v3 API and stored verbatim; API Evangelist added only this provenance block. Submitted by the provider in api-evangelist/nylas#1 and verified against the live URL before harvest: OpenAPI 3.1.0, 118 paths, 208 operations, 174 component schemas, 100% of operations carrying summary, description, tag and a unique operationId, x-code-samples on 208 of 208. This document REPLACES a 22-operation scaffold API Evangelist derived from reading the documentation, now quarantined under openapi/_scaffold/.'
x-evidence:
- url: https://developer.nylas.com/_spec-files/nylas-api.yaml
what: the published unified contract, harvested verbatim 2026-08-21 (200, text/yaml, 1,666,223 bytes)
- url: https://developer.nylas.com/.well-known/api-catalog
what: RFC 9727 linkset advertising that URL as service-desc for api.us.nylas.com and api.eu.nylas.com (200, application/linkset+json)
security:
- ACCESS_TOKEN: []
- NYLAS_API_KEY: []
tags:
- name: Applications
description: "In the context of the Nylas APIs, an \"application\" is the object record of your Nylas application.\n\n\U0001F50D The term \"application\" can refer to any of three concepts: your Nylas application, the project you're building (\"your application\" or \"your app\"), and applications that you use to connect to service providers (\"provider auth applications\"). We try to be specific in this documentation to avoid confusion. The API endpoints described here are for working with your Nylas application, specifically.
\n\nThe Nylas application is the central resource for your Nylas implementation. It collects the [connectors](/docs/reference/api/connectors-integrations/) that you use to store information about third party services that your application connects to, and stores the [grants](/docs/reference/api/manage-grants/) that you create when using connectors.\n\nNylas applications also allow you to define your specific branding, change the look and feel of the Nylas Hosted authentication flow, and list your application's callback URIs.\n\n## Application callback URIs\n\nYour Nylas application includes a list of allowed callback URIs. These are known URIs that Nylas can direct users to after authentication. You need to define at least _one_ callback URI so your users can complete the auth flow.\n\nYou must include any callback URIs you plan to use in this list. If an auth payload includes a callback URI that isn't on the list, the whole authentication flow fails.\n\n## Application limitations\n\n⚠️ You can create, edit, and delete applications from the Nylas Dashboard. You cannot create, edit, or delete them using the Nylas APIs.
\n\nKeep the following limitations in mind as you work with Nylas applications:\n\n- Applications are the central resource that stores other Nylas resources. You _must_ create an application before you can create any other parts of your Nylas implementation.\n- Applications can be associated with only one project at a time. While your project can have more than one Nylas application to provide different authentication experiences, you cannot share applications, connectors, or grants between more than one project.\n- Applications cannot be nested, and cannot be set up with parent-child relationships.\n- Your application must have _at least one_ callback URI, or else it cannot finish the authentication flow, which means it cannot create grants. Nylas requires grants to access user data.\n - In an ideal scenario, your application will have multiple callback URIs defined.\n"
- name: Authentication APIs
description: "Nylas provides two ways to handle authentication:\n\n- **Bring Your Own (BYO) Authentication**, which uses the [`/v3/connect/custom` endpoint](/docs/reference/api/manage-grants/byo_auth/). In BYO Authentication, you already have refresh tokens for your users, and you just need to create grants for them in Nylas. This endpoint is also used for [virtual calendars](/docs/v3/calendar/virtual-calendars/), [IMAP auth](/docs/v3/auth/imap/), and [bulk auth grants](/docs/v3/auth/bulk-auth-grants/).\n- **Hosted OAuth**, where the user completes an OAuth process on the provider, and the provider returns an access token. Depending on your needs, you can use either the user's access token or a Nylas API key to authorize requests after you complete the OAuth flow. See the [Authentication documentation](/docs/v3/auth/) for more information.\n\n## Hosted authentication with OAuth\n\nOAuth is the modern industry-standard protocol for authorization, and is used by major technology companies like Google, Apple, Microsoft, and others. Nylas supports authentication using the [OAuth 2.0 protocol](https://oauth.net/2/) and an additional option to use PKCE for extra security. [PKCE is an extension of the OAuth 2.0 protocol](https://oauth.net/2/pkce/) that prevents authorization code interception attacks, and makes OAuth 2.0 more secure on mobile devices and client-side applications.\n\nDuring the OAuth 2.0 authentication flow, the user provides the account that they want to authenticate to Nylas, and they're prompted to allow your application's \"scopes\" (for example, `https://www.googleapis.com/auth/gmail.readonly` or `https://www.googleapis.com/auth/userinfo.profile`). Nylas always returns the fully-qualified Google scopes when you make an Authentication request that references a Google grant. For grants authenticated with other providers, Nylas returns the truncated scopes.\n\n### Using Hosted OAuth\n\nTo use Hosted OAuth you first need to create a Nylas application in the Nylas Dashboard, then create a [connector](/docs/reference/api/connectors-integrations/) in that application for each authentication provider. This allows Nylas to get and store each provider's settings, and configure a set of default scopes to apply.\n\nNylas can detect which provider a user is authenticating with and redirect them to the correct provider's authentication system.\n\nIf the user decides to choose different provider settings for an OAuth 2.0 authorization protocol, Nylas allows them to override the default provider connector's settings.\n\nA successful OAuth authorization results in a [grant](/docs/reference/api/manage-grants/) with the scopes that the user allowed.\n\nSee [Create grants with OAuth 2.0 and PKCE](/docs/v3/auth/hosted-oauth-accesstoken/#create-grants-with-oauth-2.0-and-pkce) for more information.\n\n### Adding the \"Sign in with Google\" button\n\nYour Google provider auth app must have a \"Sign in with Google\" button that meets [Google's branding guidelines](https://developers.google.com/identity/branding-guidelines). This applies to the OAuth flow for both personal Gmail (`@gmail.com`) and Workspace email addresses.\n\nFor Hosted authentication, Nylas recommends you do one of the following:\n\n- Configure the OAuth login prompt by setting the `prompt` parameter with `select_provider` or `detect,select_provider`. For more information, see [Configure the OAuth login prompt](/docs/v3/auth/customize-login-prompt/).\n\n ⚠️ If you add a login_hint that is a personal Gmail or Workspace email address, and you don't configure a prompt during the Hosted auth flow, the user is directed immediately to the Google OAuth page without clicking the \"Sign in with Google\" button. This can result in delays or failure in verification.\n
\n\n- Use the pre-approved \"Sign in with Google\" button along with the \"Connect your account\" button (or other provider login buttons) in your application. For more information, see Google's official [Sign in with Google branding guidelines](https://developers.google.com/identity/branding-guidelines).\n\nFor Bring Your Own Authentication, use the pre-approved \"Sign in with Google\" button along with the \"Connect your account\" button (or other provider login buttons) in your application.\n\nLearn more about [Google verification and security assessment](/docs/provider-guides/google/google-verification-security-assessment-guide/).\n"
- name: Manage Grants
description: 'Grants are the main objects that power Nylas, because they _grant_ your Nylas application specific scopes of access (for example, permission to read email messages) to the user''s resources and data on their provider. They also represent access granted to your application for certain resources.
There are several ways to create grants:
- Using [Hosted OAuth and an API key](/docs/v3/auth/hosted-oauth-apikey/).
- Using [Hosted OAuth and an access token](/docs/v3/auth/hosted-oauth-accesstoken/), with [optional PKCE](/docs/v3/auth/hosted-oauth-accesstoken/#create-grants-with-oauth-2.0-and-pkce) for additional security.
- Using [Bring Your Own Authentication](/docs/v3/auth/custom/).
- Using a special [bulk auth grant](/docs/v3/auth/bulk-auth-grants/) (also called a "service account").
You can re-authenticate grants using any of these methods, and Nylas handles all the re-authentication logic internally.
## Grant expiry
Grants, and their access tokens and refresh tokens are controlled by the provider, not Nylas. Nylas can request that the provider invalidate or revoke a grant, but can''t prevent the provider from expiring a grant.
Usually when a provider expires a grant it is after a period of inactivity, and the provider expires the associated access token for security reasons. To prevent grants from expiring, encourage users to actively engage with their accounts and regularly refresh the access token with a valid refresh token.
## Re-authentication and notifications
Grants can become invalid for many reasons (for example, the user changing their password). When a grant becomes invalid, the user must re-authenticate to access your application.
When a grant becomes invalid, Nylas loses access to the affected user''s data and stops sending notifications about changes to its objects. When the user re-authenticates, Nylas looks at when their grant last authenticated successfully. If it was less than 72 hours ago, Nylas looks for any changes that happened since the last successful sync and sends you notifications about those events. This can be _a lot_ of notifications.
If the grant was out of service for more than 72 hours, Nylas doesn''t send backfill notifications. When this happens, look for the `grant.expired` and `grant.updated` notifications and query the Nylas APIs for objects that changed between those timestamps.
## Grant limitations
When working with grants, keep the following limitations in mind:
- You can re-authenticate a grant to add new scopes, remove scopes, or extend its expiry date.
- Each grant belongs to a specific Nylas connector (because they come from a specific provider), in a specific Nylas application. A grant cannot be associated with multiple connectors or applications.
- Grants expire after a pre-defined period of time. When this happens, they must be re-authenticated.
## Grant notifications
You can subscribe to the following triggers so Nylas notifies you about changes to your users'' data:
- `grant.created`
- `grant.updated`
- `grant.deleted`
- `grant.expired`
For more information, see the [Grant notification schemas](/docs/reference/notifications/#grant-notifications).
'
- name: Connectors (Integrations)
description: 'In Nylas, a connector (formerly called an "integration") stores information that allows your Nylas application to connect to a third party services, such as a provider auth application from Google (GCP), Microsoft (Azure), or to an IMAP provider. You must create a connector in your Nylas application for each specific provider before you can create Grants and access user data from that provider.
A Nylas connector stores data about how your Nylas application contacts the provider, the default permissions the Nylas application requests, and is generally the starting point for any authentication with that provider.
## Connector contents
The connector stores a label provided by the user, the provider name or type (for example, `google`/`microsoft`/`imap`/`virtual_calendar`), an expiry time for the hosted authentication link, and the provider settings.
The "provider''s settings" come from the provider itself when you create your provider auth application on Google, Azure, or IMAP. For example, a provider''s settings might contain the provider auth application''s `client_id` and `client_secret`. Nylas stores these values securely and uses them as default credentials when authenticating with that provider.
Nylas follows modern security best practices to encode and encrypt these provider settings, to ensure that they can never be obtained by a third party, including Nylas internal employees.
### What are limitations of connectors?
Connectors are associated with a single [Nylas application](/docs/reference/api/applications/).
You can have only one Nylas connector for each type of provider. For example, your Nylas application can have only one Google connector.
If you want to create a grant for a different provider auth application, (for example, on a different GCP project, but you already have a default Google connector), you can create additional credentials for your connector. Each connector can have multiple credentials, where each credential represents a different provider auth application. For more information, see [Using multiple provider applications](/docs/v3/auth/using-multiple-provider-applications/).
'
- name: Connector credentials
description: 'A Nylas connector credential is a special type of record that securely stores information (such as provider settings) that allows you to connect using an administrator account. Nylas securely stores, hashes, and encrypts the connector credential''s sensitive data, and the contents vary depending on the authentication provider.
Bulk authentication grants use connector credentials to connect or reconnect user accounts to your Nylas application. You can also use them to override a connector''s settings to perform administrative tasks. For more information, see the [Bulk authentication grant documentation](/docs/v3/auth/bulk-auth-grants/).
Both Google and Microsoft bulk authentication grants can use connector credentials.
To override the default values in a provider''s connector settings (for example, the `client_secret` and `client_id`), [create a grant using Bring Your Own Authentication](/docs/v3/auth/bring-your-own-authentication/) and provide the connector credential in your request payload, along with the values to override.
## Connector credential limitations
Keep the following limitations in mind as you work with connector credentials:
- A connector credential _must_ be connected to an existing Nylas connector.
- Each connector credential must have a unique name.
- When you make a [Create Credential request](/docs/reference/api/connector-credentials/create_credential/), Nylas checks if a connector credential with the same parameters exists. If one _does_ exist, Nylas uses that connector credential instead of creating one.
'
- name: Workspaces
description: 'Workspaces group and organize grants in a Nylas application by a common attribute, such as the email address domain (for example, `nylas.com`).
## Assign grants to workspaces
Nylas offers two endpoints to manage workspaces and the grants they contain:
- [**Automatically Group Grants into Workspaces**](/docs/reference/api/workspaces/autogroup-workspace/): Starts a background job that, based on your filters, processes existing grants in your Nylas application and automatically sorts them to existing workspaces. If necessary, Nylas automatically creates new workspaces.
- [**Update Workspace Assignments**](/docs/reference/api/workspaces/manually-assign-workspace/): Manually specify a workspace ID and up to 500 grants to add or remove from that workspace.
## Default workspace
A Nylas application can have a _default workspace_, which Nylas creates automatically when the application is created and manages on your behalf. Applications created before default workspaces were introduced might not have one. When you retrieve workspaces, Nylas identifies the default workspace with `"default": true`, and the application object exposes its ID as `default_workspace_id`.
When a new grant is created without an explicit `workspace_id`, Nylas first tries to auto-group it into a workspace that has `auto_group` enabled and a `domain` that matches the grant''s email address domain. If no domain workspace matches, Nylas assigns the grant to the application''s default workspace, if one exists.
The default workspace is protected: you can update only its `policy_id` and `rule_ids` values (changes to `name` or `auto_group` return an error), and you can''t delete it. A workspace''s `domain` can''t be changed after creation, on any workspace.
## Policies and rules
Workspaces can carry a [policy](/docs/v3/agent-accounts/policies-rules-lists/) (`policy_id`) and [rules](/docs/v3/agent-accounts/policies-rules-lists/#rules) (`rule_ids`). Agent Accounts in a workspace use the policy attached to the workspace for limits and spam settings, and the rules attached to the workspace for mail filtering.
## Workspace limitations
- Workspaces are designed to group grants by the top-level domain (TLD) of users'' email addresses. Nylas allows you to manually assign grants to any workspace, but that workspace must have `auto_group` set to `false`.
- When `auto_group` is set to `false`, Nylas doesn''t automatically assign grants to that workspace. You''ll need to manually assign grants to the workspace using the [Update Workspace Assignments endpoint](/docs/reference/api/workspaces/manually-assign-workspace/).
- When `auto_group` is `true`, Nylas automatically assigns new grants to the workspace. You can move grants to a different workspace by making an [Update Workspace Assignments request](/docs/reference/api/workspaces/manually-assign-workspace/).
'
- name: Manage API keys
description: "The Manage API Keys endpoints let you create, list, and delete API keys from your Nylas application outside of the Nylas Dashboard.\n\n## Nylas Service Account\n\n⚠️
Before you can use the Manage API Keys endpoints, you need to create a Nylas Service Account. If you have a contract with us, you can
contact Nylas Support for more information.
\n\nAfter Nylas Support creates a Service Account for your application, they send you a JSON file with the following information:\n\n\n```json\n{\n \"type\": \"service_account\",\n \"private_key_id\": \"\",\n \"private_key\": \"\",\n \"organization_id\": \"\",\n \"region\": \"us\"\n \"permissions\": [\"apikey.create\", \"apikey.delete\", \"apikey.get\"]\n}\n```\n\nYou use the information in this file to generate the headers that sign your requests (for example, the `X-Nylas-Signature` header uses your private key's RSA, a 2048-bit key, and an SHA-256 hashed string of the path, method, timestamp, nonce, and payload.). Be sure to [store this information securely](/docs/dev-guide/best-practices/#store-secrets-securely).\n"
- name: Manage Domains
description: 'The Manage Domains endpoints let you register, verify, update, and delete email domains for use with [Transactional Send](/docs/v3/getting-started/transactional-send/) and [Nylas Agent Accounts](/docs/v3/agent-accounts/).
Before you can use these endpoints, you need a [Nylas Service Account](/docs/v3/auth/nylas-service-account/) to authenticate your requests. Nylas Service Account authentication uses cryptographic request signing with four custom headers (`X-Nylas-Kid`, `X-Nylas-Timestamp`, `X-Nylas-Nonce`, `X-Nylas-Signature`).
## Domain verification
After you register a domain, you must verify DNS records before you can use it. Call the **Get domain info** endpoint to retrieve the DNS records you need to configure, then call the **Verify domain** endpoint after you''ve added them to your DNS provider.
The verification types are:
| Type | Required for | Description |
| ----------- | ---------------------------------- | ---------------------------------------- |
| `ownership` | All domains | Proves you control the domain. |
| `dkim` | Transactional Send, Agent Accounts | Authenticates outgoing mail. |
| `spf` | Transactional Send, Agent Accounts | Authorizes Nylas to send on your behalf. |
| `feedback` | Transactional Send, Agent Accounts | Enables bounce reporting. |
| `mx` | Agent Accounts | Routes incoming mail to Nylas. |
Nylas tracks `dmarc` and `arc` records but does not currently enforce or verify them. Setting up DMARC is highly recommended to prevent emails going to spam.
For more information, see [Managing domains](/docs/v3/email/domains/).
'
- name: Policies
description: 'The Policies endpoints let you define the operational configuration for Nylas Agent Accounts, including message limits, attachment constraints, spam detection settings, and linked rules for inbound message filtering. Each policy is scoped to your application and can be assigned to one or more Agent Accounts, or attached to a [workspace](/docs/reference/api/workspaces/) to apply its limits and spam settings to the Agent Accounts it contains.
Policies let you control:
- **Limits** — Attachment sizes, counts, allowed types, total storage, daily message quotas, and retention periods for the inbox and spam folders.
- **Spam detection** — DNS-based block list (DNSBL) checking, header anomaly detection, and sensitivity tuning.
- **Rules** — Link filtering rules (created via the Rules API) to automatically process inbound messages based on sender criteria.
Policy limits are validated against your plan''s maximum values. If a limit field is omitted, it defaults to the plan maximum. If a requested value exceeds the plan limit, the API returns an error.
'
- name: Rules
description: 'The Rules endpoints let you define automated filtering and routing logic for Nylas Agent Accounts. Each rule specifies a `trigger` (`inbound` or `outbound`), matching conditions, and actions to perform when those conditions are met.
**Inbound rules** run when mail arrives. Conditions match the sender — `from.address`, `from.domain`, or `from.tld`. Actions include blocking the message at the SMTP level, marking as spam, assigning to a folder, marking as read or starred, archiving, and trashing.
**Outbound rules** run before a send is submitted to the email provider. Conditions can match sender data (`from.address`, `from.domain`, `from.tld`), recipient data (`recipient.address`, `recipient.domain`, `recipient.tld`), or the send type via `outbound.type` (`compose` for new messages, `reply` for replies). A `block` action on an outbound rule rejects the send with HTTP 403 before it reaches the provider, so no message is delivered and no sent copy is stored. Non-blocking actions (`mark_as_spam`, `archive`, `mark_as_read`, `mark_as_starred`, `assign_to_folder`, `trash`) apply to the stored sent copy. `recipient.*` fields match against **any** recipient — including To, CC, BCC, and SMTP envelope recipients.
Inbound and outbound rules are isolated. Inbound rules never run during sends, and outbound rules never run on message receipt, so stored sent copies aren''t re-evaluated against inbound rules.
Rules are evaluated in priority order (lower numbers first). Inbound rules are applied through the recipient grant''s policy. Outbound rules are currently evaluated from the sending application''s enabled outbound rules. The `block` action is terminal and cannot be combined with other actions.
Rules support the `in_list` condition operator, which checks field values against Lists (managed via the Lists API) for dynamic, maintainable allow and block lists. `in_list` works for `from.*` and `recipient.*` fields but not for `outbound.type`, which accepts only `is` and `is_not`.
Rule executions are audited per grant. List evaluation records with `GET /v3/grants/{grant_id}/rule-evaluations` to see which inbound or outbound rules ran, what normalized input was considered, and which actions were applied.
'
- name: Lists
description: 'The Lists endpoints let you manage typed collections of values (email addresses, domains, or top-level domains) that can be referenced by Rules using the `in_list` condition operator. Lists provide a way to maintain dynamic allow lists and block lists that are evaluated during inbound rule processing and outbound send evaluation without needing to update individual rules.
Each list has a `type` that determines what kind of values it accepts and which rule condition fields it can be matched against:
- **`domain`** — Domain names (for example, `example.com`). Matched against the `from.domain` or `recipient.domain` rule condition.
- **`tld`** — Top-level domains (for example, `com`, `xyz`). Matched against the `from.tld` or `recipient.tld` rule condition.
- **`address`** — Full email addresses (for example, `user@example.com`). Matched against the `from.address` or `recipient.address` rule condition.
List `type` is set at creation time and cannot be changed. Items within a list are managed via the `/v3/lists/{list_id}/items` sub-resource endpoints. Values are automatically normalized (lowercased and trimmed) and validated against the list''s `type`. Duplicate additions are silently ignored. You can submit up to 1000 items per add or remove request, and each item value can be at most 500 characters.
'
- name: Webhook Notifications
description: 'Your application receives information about changes to user accounts and data through Nylas webhooks.
🔍 The term "webhook" can refer to any of three component parts: a location where you receive notifications (the "webhook URL" or "webhook endpoint"), a subscription to events that you want notifications for ("webhook triggers"), or the information payload that is sent when a trigger condition is met (the "webhook notification"). We try to be specific in this documentation to avoid confusion.
To configure webhooks, you first need a webhook URL in your project where your app can receive incoming webhook payloads, and a list of triggers that you want to receive notifications for. See the [list of available trigger types](/docs/reference/notifications/) for more information.
Webhooks in Nylas are not compatible with Ngrok because of throughput limiting concerns. Nylas recommends you use [VS Code port forwarding](https://code.visualstudio.com/docs/editor/port-forwarding), [Hookdeck](https://hookdeck.com/), or a similar webhook tool.
## Testing webhooks
Nylas includes two utility API endpoints to help you identify problems with your webhook configuration.
Use the [Send Test Event endpoint](/docs/reference/api/webhook-notifications/send_test_event/) to check if your project''s webhook destination is configured correctly. This endpoint sends a test webhook payload, and listens for a success acknowledgement from the webhook destination.
Use the [Get Mock Notification Payload endpoint](/docs/reference/api/webhook-notifications/get_mock_webhook_payload/) to see example notification payloads for the different Nylas events.
## Monitor grant status
The most important webhooks to subscribe to are those related to grant status: `grant.created`, `grant.updated`, `grant.deleted`, and `grant.expired`. They allow you to automate important grant lifecycle processes, like onboarding messages, data refreshes, and backend deletions.
The `grant.expired` trigger notifies you when a user needs to re-authenticate their account. When you receive a `grant.expired` notification, you can take appropriate action (for example, notifying the user or starting a background re-authentication process).
📝 When a grant becomes invalid, Nylas cannot access the user''s data and does not send you webhook notifications about it. When you re-authenticate a grant, Nylas looks at when the grant last authenticated successfully. If it was less than 72 hours ago, Nylas looks for any changes that happened since the time of the last successful sync, and sends you notifications about them. This can be a lot of notifications.
If the grant has been out of service for more than 72 hours, Nylas does _not_ send backfill notifications. In this case, look for the `grant.expired` and `grant.updated` notifications, and query the Nylas API for objects that changed between those timestamps.
## iCloud limitation for Calendar notifications
Because iCloud doesn''t support the `primary` property for calendars, Nylas sends `calendar.updated` notifications for changes to all calendars on an iCloud account.
## Gmail metadata notifications
Nylas sends [`message.created.metadata` and `message.updated.metadata` notifications](/docs/reference/notifications/#message-metadata-notifications) for Google grants that include the `/gmail.metadata` scope. These notifications have limited data because of the restrictive scope. Even if a grant has more permissive scopes, Google falls back to the `/gmail.metadata` permissions.
When you subscribe to a `message.*` webhook trigger, Nylas automatically sends `message.*.metadata` notifications as well. You don''t need to subscribe to these triggers separately, and they don''t appear as a configuration option in the Nylas Dashboard. For more information, see our list of [available trigger types](/docs/reference/notifications/).
## Payload size limit and truncation
Nylas sends webhook notifications as JSON payloads that contain the object that triggered the notification, up to a maximum payload size of 1MB. If a webhook notification exceeds the size limit, Nylas truncates the payload by removing the body content, and adds the `.truncated` suffix to the webhook trigger name (for example, `message.created.truncated`). This reduces the size of the payload and improves performance.
When you receive a truncated webhook notification, you''ll need to re-query the Nylas APIs to get the data. For example, if you receive a `message.updated.truncated` notification, make a [Get Message request](/docs/reference/api/messages/get-messages-id/) that includes the message ID.
If you subscribe to a webhook trigger that can be truncated, Nylas automatically sends you `.truncated` notifications as well. You don''t need to subscribe to webhook triggers with the `.truncated` suffix separately, and the suffix doesn''t appear as a option in the Nylas Dashboard. See the [list of available trigger types](/docs/reference/notifications/) for more information.
You can monitor for `.truncated` notifications to create automations that retrieve the full affected object. For example, you can create an automation that makes a [`GET /v3/grants//messages/` request](/docs/reference/api/messages/get-messages-id/) when your application receives a `message.updated.truncated` notification.
## Payload compression
Set `compressed_delivery` to `true` on a webhook destination and Nylas gzip-compresses each notification before `POST`ing it to your endpoint, adding a `Content-Encoding: gzip` header. Compressed payloads are also opaque to firewalls and WAFs that would otherwise block requests containing HTML in email bodies. Verify the `X-Nylas-Signature` header against the raw compressed body _before_ decompressing. For full setup and when to use it, see [Reducing payload size with compression](/docs/dev-guide/best-practices/compression/).
## How to handle webhook failures
Nylas implements "circuit breaker" logic to handle failing webhooks. See [improvements to failure notifications](/docs/new/in-v3/webhooks-changes/#improvements-to-webhook-failure-notifications) and [Failing and failed webhooks](/docs/v3/notifications/#failing-and-failed-webhooks) for more information.
- **Failing state**: If Nylas cannot deliver a webhook notification to the destination endpoint for 95% of webhooks over a 15-minute period, Nylas marks the endpoint as `failing` but continues sending notifications to it. Nylas also sends you a message when this happens so you can troubleshoot the issue.
- **Failed state**: If Nylas cannot deliver 95% of webhook notifications to a `failing` endpoint over the next 72 hours, Nylas marks the endpoint as `failed` and stops sending notifications to it. Nylas also sends you a message when this happens so you can address the issue.
⚠️ Nylas does not automatically restart or reactivate failed webhooks.
This change gives you full control over when your webhook endpoint becomes active again, so you can verify that it''s working as expected before you restart normal webhook traffic.
## Duplicate webhook notifications
Nylas guarantees "at least once" delivery of webhooks. You might receive duplicate webhook notifications because of the provider''s behavior (for example, when Google and Microsoft Graph send upserts).
## Webhook triggers
- `contact.updated`: A contact was modified or updated.
- `contact.deleted`: A contact was deleted.
- `calendar.created`: A calendar was created.
- `calendar.updated`: A calendar was updated or modified.
- `calendar.deleted`: A calendar was deleted.
- `event.created`: An event was created on a user''s calendar.
- `event.updated`: An event was updated or modified.
- `event.deleted`: An event was deleted.
- `grant.created`: A new grant was authenticated.
- `grant.updated`: A grant was modified, updated, or re-authenticated.
- `grant.deleted`: A grant was deleted as a result of the user making a [Delete Grant request](/docs/reference/api/manage-grants/delete_grant_by_id/).
- `grant.expired`: A grant''s credentials have expired, and the user must re-authenticate.
- `message.created`: A message was created.
- `message.created.cleaned`: A cleaned (parsed) version of a newly created message was processed. Requires Clean Conversations to be enabled.
- `message.updated`: A message was updated.
- `message.send_success`: A scheduled message was sent and delivered successfully. You must set the `send_at` parameter in a message to use this trigger. For more information, see [Schedule messages to send in the future](/docs/v3/email/scheduled-send/).
- `message.send_failed`: A scheduled message was sent, but was not delivered. You must set the `send_at` parameter in a message to use this trigger. For more information, see [Schedule messages to send in the future](/docs/v3/email/scheduled-send/).
- `message.bounce_detected`: (Available for Google, Microsoft Graph, iCloud, and Yahoo) A message bounced or was not delivered.
- `message.opened`, `message.opened.legacy`: A participant opened a tracked message.
- `message.link_clicked`, `message.link_clicked.legacy`: A participant clicked a link in a tracked message.
- `thread.replied`, `thread.replied.legacy`: A participant replied to a message in a tracked thread.
- `folder.created`: A folder or label was created.
- `folder.updated`: A folder or label was modified or updated.
- `folder.deleted`: A folder or label was deleted.
- `booking.created`: A new Scheduler event was created.
- `booking.rescheduled`: A Scheduler event was rescheduled through Scheduler.
- `booking.cancelled`: A Scheduler event was cancelled through the Scheduler.
- `booking.pending`: A pending booking was created.
- `booking.reminder`: Nylas sent a reminder about a booking.
For more information on webhook trigger types, and for schema examples, see the [notification schemas](/docs/reference/notifications/).
## Scheduler events in Calendar webhooks
Calendar events that Nylas Scheduler creates also produce standard `event.*` notifications. Nylas stamps these events with metadata so you can identify them in Calendar webhooks:
- `source`: Always `scheduler`.
- `key5`: The Scheduler Configuration ID.
- `scheduler_last_start`, `scheduler_last_end`, `scheduler_updated_at`: Unix timestamps (as strings) that record the meeting time Scheduler most recently set, at booking creation and on each reschedule.
To tell Scheduler-driven changes apart from edits made directly on the organizer''s calendar, compare an `event.updated` notification''s `when` times against `scheduler_last_start` and `scheduler_last_end`: if the times match, the change came through Scheduler (Nylas also sends a `booking.rescheduled` notification), and if they differ, the event was changed directly on the calendar.
These metadata entries share the event''s customer-visible `metadata` object. If you update an event''s metadata using the Events API, include the Scheduler-stamped entries in your request — updates replace the metadata object as a whole.
'
- name: Pub/Sub Notifications
description: 'Nylas offers two ways to get notifications of what''s happening on the provider. You can either subscribe to webhook notifications, or you can set up a notification channel.
Nylas offers Pub/Sub and Amazon SNS notification channels. These can be used in place of, or in addition to, normal webhook notifications.
To use Pub/Sub notifications, you first need to set up a Pub/Sub queue on Google Cloud Platform. For detailed set up instructions see the [Pub/Sub notifications documentation](/docs/v3/notifications/pubsub-channel/).
To use Amazon SNS notifications, you need to set up an SNS topic and IAM role in your AWS account. For detailed set up instructions see the [Amazon SNS notifications documentation](/docs/v3/notifications/sns-channel/).
Nylas notification channels use the same notification [trigger types and schemas](/docs/reference/notifications/) as webhook notifications, and require the same [provider scopes](/docs/dev-guide/scopes/).
## Payload compression
Both Pub/Sub and SNS channels accept a `compressed_delivery` boolean that gzip-compresses each notification payload before delivery. Nylas adds a `content_encoding` message attribute (`gzip` for Pub/Sub, `gzip+base64` for SNS) so your subscriber knows which messages to decompress. We strongly recommend enabling it on SNS channels, where the 256 KB message limit makes compression the simplest way to avoid payload truncation. For setup and decode patterns, see [Reducing payload size with compression](/docs/dev-guide/best-practices/compression/).
## Monitor grant status
The most important notifications to subscribe to are those related to grant status: `grant.created`, `grant.updated`, `grant.deleted`, and `grant.expired`. They allow you to automate important grant lifecycle processes, like onboarding messages, data refreshes, and backend deletions.
The `grant.expired` trigger notifies you when a user needs to re-authenticate their account. When you receive a `grant.expired` notification, you can take appropriate action (for example, notifying the user or starting a background re-authentication process).
📝 When a grant becomes invalid, Nylas cannot access the user''s data and does not send you notifications about it. When you re-authenticate a grant, Nylas looks at when the grant last authenticated successfully. If it was less than 72 hours ago, Nylas looks for any changes that happened since the time of the last successful sync, and sends you notifications about them. This can be a lot of notifications.
If the grant has been out of service for more than 72 hours, Nylas does _not_ send backfill notifications. In this case, look for the `grant.expired` and `grant.updated` notifications, and query the Nylas API for objects that changed between those timestamps.
'
- name: Amazon SNS Notifications
description: 'Amazon SNS notification channels allow you to receive Nylas event notifications through Amazon Simple Notification Service (SNS) instead of webhooks.
To use Amazon SNS notifications, you need to set up an SNS topic and an IAM role in your AWS account. The topic ARN must start with `arn:aws:sns:`. The IAM role must allow Nylas to assume it via STS `AssumeRoleWithWebIdentity` and must have `sns:Publish` permission on the topic. For detailed set up instructions, see the [Amazon SNS notification channel documentation](/docs/v3/notifications/sns-channel/).
The Amazon SNS notification channels use the same notification [trigger types and schemas](/docs/reference/notifications/) as webhook notifications, and require the same [provider scopes](/docs/dev-guide/scopes/).
Nylas strongly recommends setting `compressed_delivery` to `true` when you create an SNS channel. SNS enforces a 256 KB message size limit, and gzip compression is the simplest way to keep large `message.*` notifications inside it. Nylas adds a `content_encoding: gzip+base64` message attribute so your subscriber knows which messages to decompress. For setup and the decode pattern, see [Reducing payload size with compression](/docs/dev-guide/best-practices/compression/).
'
- name: Messages
description: 'The Nylas Send API allows you to send messages immediately, and schedule them to be sent in the future (asynchronously). You can save scheduled messages either in Nylas, or as Draft objects on the provider. The Send API uses the same commands to manage messages across all providers, and can refer to specific messages using the provider''s `message_id`.
Nylas uses webhooks to let you know when an email message has been sent. The webhook''s message includes a status, a reason description, and the Nylas request ID. For more information, see the [notifications documentation](/docs/v3/notifications/).
## Adding attachments to messages
Use the Messages endpoints to add and modify files attached to email messages as you send them. The [Attachments APIs](#tag--Attachments) allow you to download or get the metadata about an existing attachment, but you use the Messages API to add or modify the attachments. For more information, see [Working with email attachments](/docs/v3/email/attachments/).
### Provider IDs for messages
Nylas uses an object''s provider ID to refer to the object, and different providers return differently formatted IDs. For IMAP messages, Nylas extracts the ID from the `message-id` header. For Google and Microsoft, the object ID comes from the provider''s internal ID.
## Metadata on messages
You can add metadata to new and existing messages by including the `metadata` sub-object in your `POST`, `PUT`, or `PATCH` request. For more information, see the [Metadata documentation](/docs/dev-guide/metadata/).
[Agent Account](/docs/v3/agent-accounts/) grants support metadata on messages, with the same 50-pair limit and the same five indexed reserved keys as connected grants.
## Messages scopes
The table below lists the Messages endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :------------------------------------------------------- | :------------------------------------------------------------------- | :------------------------------------------------------------------------------------- |
| **GET** `/messages`
**GET** `/messages/` | `/gmail.readonly` ☑️
`/gmail.modify` | `Mail.Read` ☑️
`Mail.ReadWrite`
`Mail.Read.Shared``Mail.ReadWrite.Shared` |
| **PUT**`/messages/` | `/gmail.modify` ☑️ | `Mail.ReadWrite` ☑️
`Mail.ReadWrite.Shared` |
| **DELETE** `/messages/` | `/gmail.modify` ☑️
`https://mail.google.com/` (for hard-delete) | `Mail.ReadWrite` ☑️
`Mail.ReadWrite.Shared` |
| **POST** `/messages/send` | `/gmail.send` ☑️
`/gmail.compose`
`/gmail.modify` | `Mail.ReadWrite` ☑️
`Mail.ReadWrite.Shared` |
No scopes are required for the `/messages/schedules` endpoints, because scheduled messages are stored with Nylas. You will need `gmail.send` or `Mail.ReadWrite` to send scheduled messages, however.
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
## Messages notifications
You can subscribe to the following triggers so Nylas notifies you about changes to your users'' data:
- `message.created`
- `message.updated`
You can subscribe to the following triggers to get notifications about the status of a scheduled message:
- `message.send_success`
- `message.send_failed`
- `message.bounce_detected` (Available for Google, Microsoft Graph, iCloud, and Yahoo.)
To receive message notifications, you must [enable specific scopes](/docs/dev-guide/scopes/#email-api-scopes) that allow Nylas to monitor for these events. For more information, see the [Message notification schemas](/docs/reference/notifications/#message-notifications).
## Message tracking and send status monitoring
You can configure options to track when a message you sent has been opened, when links inside of it are clicked, and when someone replies to a thread. For more information, see the [message tracking documentation](/docs/v3/email/message-tracking/).
Nylas includes a [`message.bounce_detected` notification](/docs/reference/notifications/#message-bounce-detected-notifications) for Google, Microsoft Graph, iCloud, and Yahoo that triggers when a message that you send bounces. You can subscribe to the trigger to monitor for bounced messages.
You can use the [`message.send_success`](/docs/reference/notifications/#message-send-success-notifications) and [`message.send_failed`](/docs/reference/notifications/#message-send-failed-notifications) triggers to monitor the status of messages that you send using Scheduled Send. For these triggers to work, you must set the `send_at` parameter in your [Send Message request](/docs/reference/api/messages/send-message/). For more information, see [Schedule messages to send in the future](/docs/v3/email/scheduled-send/).
## Search messages
Search for messages by making a [`GET /v3/grants//messages` request](/docs/reference/api/messages/get-messages/) that includes any of the following query parameters:
- `subject`, `thread_id`
- `any_email`, `to`, `from`, `cc`, `bcc`
- `received_before`, `received_after`
- `in`, `unread`, `starred`, `has_attachment`
- `search_query_native`
- `fields`
⚠️
Nylas doesn''t support filtering for folders using keywords or attributes (for example,
in:inbox returns a
400 error). Instead, you should use the folder ID with
in to get the data you need.
The [`search_query_native` parameter](/docs/dev-guide/best-practices/search/#search-messages-and-threads-using-search_query_native) accepts provider-specific query strings for connected grants and [Nylas full-text search syntax](/docs/v3/agent-accounts/email-search/) for Agent Accounts. The value that you specify _must_ be URL-encoded.
For more information and a list of provider considerations, see [Searching with Nylas](/docs/dev-guide/best-practices/search/).
## Query IMAP server directly
Set the `query_imap` query parameter to `true` in your [Get Message](/docs/reference/api/messages/get-messages-id/) or [Get all Messages](/docs/reference/api/messages/get-messages/) requests to query the IMAP server directly instead of the Nylas database. This lets you get the most up-to-date information from the IMAP server, or data older than the default three-month retention time.
When you use the `query_imap` query parameter in a Get all Messages request, you must also set the `in` query parameter. This tells Nylas which folder to query. Nylas includes the specified folder ID only in the returned messages'' `folder` fields, even if the message is in multiple folders.
Keep in mind that most IMAP servers are slow and have low [rate limits](/docs/dev-guide/platform/rate-limits/). Nylas might take more time to return responses compared to requests that don''t use the `query_imap` query parameter. If an account has many folders, you''re querying for a large message, or you''re also using the `has_attachment` query parameter, your request can take even longer.
Sometimes, you might receive a `404` error for valid message IDs. This is because some IMAP servers don''t support searching for email headers.
'
- name: Transactional send
description: 'Nylas'' Transactional Send endpoint lets you send messages directly from an email domain that you''ve verified with Nylas. You can use this to send password reset emails, account verifications, or system notifications.
'
- name: Signatures
description: 'The Nylas Signatures API lets you create and store HTML email signatures on Nylas, and reference them by ID when sending messages or creating drafts. Nylas appends the signature to the end of the email body at send time.
Nylas signatures are managed entirely through this API and are separate from any signatures configured in the user''s email provider (Gmail, Outlook, etc.). Provider signatures are not synced to Nylas, and are not applied to emails sent through the Nylas API.
Each grant supports up to 10 signatures, so users can maintain variants for different contexts (for example, "Work", "Personal", or "Mobile"). Signatures are automatically deleted when the parent grant is deleted.
For more information, see the [Using email signatures](/docs/v3/email/signatures/) documentation.
'
- name: Drafts
description: 'Drafts represent messages that have been composed, but not yet sent. The Nylas Email API uses the same commands to manage drafts across providers, and can refer to specific drafts using the provider''s `draft_id`.
The `/drafts` endpoints allow you to create and save drafts without sending them immediately. A draft may contain all components of a standard message, including recipients, a subject, body content, and attachments. The endpoints offer full Create, Read, Update, and Delete (CRUD) functions.
## Adding attachments to drafts
You use the Drafts endpoints to create and modify draft messages, including the files attached to them. The [Attachments APIs](#tag--Attachments) allow you to download or get the metadata about an existing attachment, but you use the Drafts API to add or modify the attachments. For more information, see [Working with email attachments](/docs/v3/email/attachments/).
When you add attachments to a draft, the format you use depends on the total size of the HTTP payload of your message. If the total size is more than 3MB, you must use the `multipart/form-data` schema. This format is subject to provider limits of 25MB for the full request.
## Metadata on drafts
You can add metadata to new and existing drafts by including the `metadata` sub-object in your `POST`, `PUT`, or `PATCH` request. For more information, see the [Metadata documentation](/docs/dev-guide/metadata/).
[Agent Account](/docs/v3/agent-accounts/) grants support metadata on drafts, with the same 50-pair limit and the same five indexed reserved keys as connected grants.
## Drafts scopes
The table below lists the Drafts endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :-------------------------------------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------------------------------------------- |
| **GET** `/drafts`**GET** `/drafts/` | `/gmail.readonly` ☑️`/gmail.compose` | `Mail.Read` ☑️`Mail.ReadWrite``Mail.Read.Shared``Mail.ReadWrite.Shared` |
| **POST** `/drafts`**PUT** `/drafts/`**DELETE** `/drafts/` | `/gmail.compose` ☑️ | `Mail.ReadWrite` ☑️`Mail.ReadWrite.Shared` |
| **POST** `/drafts/` | `/gmail.compose` ☑️`/gmail.modify` | `Mail.ReadWrite` ☑️`Mail.ReadWrite.Shared` |
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
## Query IMAP server directly
Set the `query_imap` query parameter to `true` in your [Get Draft](/docs/reference/api/drafts/get-draft-id/) or [Get all Drafts](/docs/reference/api/drafts/get-drafts/) requests to query the IMAP server directly instead of the Nylas database. This lets you get the most up-to-date information from the IMAP server, or data older than the default three-month retention time.
When you use the `query_imap` query parameter in a Get all Drafts request, Nylas includes the specified folder ID only in the returned drafts'' `folder` fields, even if the draft is in multiple folders.
Keep in mind that most IMAP servers are slow and have low [rate limits](/docs/dev-guide/platform/rate-limits/). Nylas might take more time to return responses compared to requests that don''t use the `query_imap` query parameter. If an account has many folders, you''re querying for a large draft, or you''re also using the `has_attachment` query parameter, your request can take even longer.
## EWS query considerations
You _must_ enable search indexing for all mailboxes on your on-premises Microsoft Exchange server configuration for Nylas query parameters to work correctly.
'
- name: Threads
description: 'A thread is a grouping of messages which are responses to the same original message. Threads display conversations in a logical and hierarchical way, depending on when the messages were sent and which of the messages in a chain they respond to.
Instead of displaying messages as individual and unrelated items, threads group related messages together based on any combination of the following:
- Subject line
- Message reference
- In-reply-to
- Recipients and senders
- Time and chronology
- Folder context
Threading provides an organized and coherent view of conversations, especially when several people are involved and there have been many replies. Threading allows participants to more easily follow the flow of a conversation, and understand the context and progression of the discussion.
## Search threads
Search for threads by making a [`GET /v3/grants//threads` request](/docs/reference/api/threads/get-threads/) that includes any of the following query parameters:
- `subject`
- `any_email`, `to`, `from`, `cc`, `bcc`
- `latest_message_before`, `latest_message_after`
- `in`, `unread`, `starred`, `has_attachment`
- `search_query_native`
⚠️
Nylas doesn''t support filtering for folders using keywords or attributes (for example,
in:inbox returns a
400 error). Instead, you should use the folder ID with
in to get the data you need.
The [`search_query_native` parameter](/docs/dev-guide/best-practices/search/#search-messages-and-threads-using-search_query_native) accepts provider-specific query strings for connected grants and [Nylas full-text search syntax](/docs/v3/agent-accounts/email-search/) for Agent Accounts. The value that you specify _must_ be URL-encoded.
For more information and a list of provider considerations, see [Searching with Nylas](/docs/dev-guide/best-practices/search/).
## Threads rate limits
The Threads endpoints make a significant number of calls to the provider for each API request you make. Because of this, you might encounter rate limits when working with large threads of messages. Nylas recommends taking the following steps to avoid rate limits when using the Threads endpoints:
- Specify a lower `limit` to reduce the number of results Nylas returns.
- Add query parameters to your request to filter for specific threads.
- Use the `select` parameter to tell Nylas to return just the top-level fields you need.
'
- name: Folders
description: "To simplify your experience, the Nylas Email API uses the same commands to manage both folders and labels, and can refer to specific folders using the provider's `folder_id`. The Email API also exposes provider-specific fields (for example, Google's `background_color` field).\n\nEmail providers use folders and labels to store and organize messages. Depending on the provider (Google, some IMAP providers, and so on), a message can be contained in more than one folder.\n\n\n\n## Folders scopes\n\nThe table below lists the Folders endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.\n\nThe ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you're already using one of the permissive scopes, you don't need to add the more restrictive scope.\n\n| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |\n| :------------------------------------------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------------------------------------------- |\n| **GET** `/folders`
**GET** `/folders/` | `/gmail.labels` ☑️
`/gmail.modify` | `Mail.Read` ☑️
`Mail.ReadWrite`
`Mail.ReadWrite.Shared`
`Mail.Read.Shared` |\n| **POST** `/folders`
**PUT** `/folders/`
**DELETE** `/folders/` | `/gmail.labels` ☑️
`/gmail.modify` | `Mail.ReadWrite` ☑️
`Mail.ReadWrite.Shared` |\n\nFor more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).\n\n## Folders notifications\n\nYou can subscribe to the following triggers so Nylas notifies you about changes to your users' data:\n\n- `folder.created`\n- `folder.updated`\n- `folder.deleted`\n\nFor more information, see the [Folder notification schemas](/docs/reference/notifications/#folder-notifications).\n\n## Folders limitations\n\nKeep the following limitations in mind when you're working with folders:\n\n- Because providers structure folders in different ways, Nylas doesn't support nested folders. Instead, Nylas flattens sub-folders and displays them in the same list as top-level folders.\n - For Microsoft, you can use the `parent_id` to reflect the folder hierarchy in your project.\n - On IMAP, the hierarchy is reflected in the folder name (for example, `Accounting.Taxes` or `INBOX\\Accounting\\Taxes`).\n- Because of how IMAP providers handle folders and labels, the folder names that Nylas returns aren't always the same as those listed in the provider's UI (for example, the \"Trash\" folder might be \"Deleted Messages\" in a Nylas response). Instead of relying on names, you should [use attributes and IDs to get the data you need](/docs/v3/email/folders/#folder-and-label-behavior).\n- IMAP servers use provider-specific formats to represent the folder name and hierarchy. When you make a [Create Folder request](/docs/reference/api/folders/post-folder/) for an IMAP account, Nylas creates a folder with the name you pass. If the name includes the IMAP separator that corresponds with the server settings, Nylas creates a sub-folder based on the folder name.\n- Nylas doesn't support using keywords to reference folders on the provider (for example, `in:inbox` returns a [`400` error](/docs/api/errors/400-response/)). Instead, Nylas recommends you use specific folder `id`s to get the data you need.\n- It might take up to 10 minutes for folders to be available in Nylas after you authenticate an IMAP grant.\n"
- name: Attachments
description: 'You can use the `attachments` schema in a [Send Message request](/docs/reference/api/messages/send-message/) to send attachments, regardless of the email provider. You use the [Drafts](/docs/reference/api/drafts/) endpoints to add and modify files attached to drafts. The Attachments endpoints let you download or get the metadata for existing attachments. For more information, see [Working with email attachments](/docs/v3/email/attachments/).
If you''re using draft support, the draft (including the attachment) is stored on the provider. If you''re not using draft support, Nylas stores the attachment.
You can make a [Get Attachment Metadata request](/docs/reference/api/attachments/get-attachments-id/) to retrieve a single attachment''s metadata using its ID.
## What counts as an attachment?
In Nylas, an attachment is any file included either inline as part of a message, or attached to a message as a file.
Some major email providers, such as Google and Microsoft, have their own cloud storage ("drive") services. These files usually appear as links in the message body instead of attachments on the Message object. Google Drive lets users attach files either as a link, or a file. Microsoft One Drive attachments always appear as links in the message body.
## Attachment size discrepancies
When Nylas returns information about an attachment, its listed size might be different from the actual size of the file. This is because of provider encryption methods, message headers, and rounding on the provider side. For example, if you receive a 3480-byte attachment in an email, Nylas might list it as 3680 bytes.
## Attachments scopes
The table below lists the Attachments endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :----------------------------------------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------------------------------------------- |
| **GET** `/attachments/`**GET** `/attachments//download` | `/gmail.readonly` ☑️`/gmail.modify` | `Mail.Read` ☑️`Mail.ReadWrite``Mail.ReadWrite.Shared``Mail.Read.Shared` |
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
## Query IMAP server directly
Set the `query_imap` query parameter to `true` in your [Get Attachment Metadata](/docs/reference/api/attachments/get-attachments-id/) or [Download Attachment](/docs/reference/api/attachments/get-attachments-id-download/) requests to query the IMAP server directly instead of the Nylas database. This lets you get the most up-to-date information from the IMAP server, or data older than the default three-month retention time.
Keep in mind that most IMAP servers are slow and have low [rate limits](/docs/dev-guide/platform/rate-limits/). Nylas might take more time to return responses compared to requests that don''t use the `query_imap` query parameter. If an account has many folders, or you''re querying for a large attachment, your request can take even longer.
## Microsoft attachment size discrepancies
If you''re working with Microsoft grants, you might notice a small difference between the attachment size in Nylas'' response and the actual size of the downloaded file. This is because Nylas'' attachment size calculation includes any MIME encoding headers. Nylas returns this value to be consistent with the provider, and so that it doesn''t have to pre-process all attachment content.
When working with attachments on Microsoft grants, we recommend you...
- Treat the metadata `size` field as an estimate for UI display purposes.
- Always use the actual downloaded file for storage calculations and file operations.
- Implement flexible buffer handling when the exact byte count of a file matters to your project.
- Test your Nylas integration with a number of different attachment types and sizes.
'
- name: Smart compose
description: 'The Smart Compose endpoints extend the Nylas Messages API. Currently, Smart Compose supports only two methods of getting AI responses: you can either receive them as a REST response in a single JSON blob, or use server-sent events (SSE) to stream the response tokens as Nylas receives them.
If you want to receive responses using the REST method, add the `Accept: application/json` header. Nylas will return a single JSON blob. If you use this method, you might want to add a "working" indicator to your UI, as response times may vary.
To enable SSE for a request, add the `Accept: text/event-stream` header.
For more information, see the [Smart Compose documentation](/docs/v3/email/smart-compose/).
## Smart Compose scopes
The table below lists the Smart Compose endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :------------------------------------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------------------------------------------- |
| **POST** `/messages/smart-compose`**POST** `/messages//smart-compose` | `/gmail.readonly` ☑️`/gmail.modify` | `Mail.Read` ☑️`Mail.ReadWrite``Mail.ReadWrite.Shared``Mail.Read.Shared` |
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
'
- name: Calendar
description: 'The Nylas Calendar API allows you to create and manage calendars, and access the events they contain. Nylas uses the same commands to manage calendars across providers, and you can refer to specific calendars using the provider''s `calendar_id`.
Depending on the provider, a calendar might be accessed by only one person, or shared among several users. Some common calendars might include Personal, Work, or Shared calendars.
A calendar might contain overlapping events or conflicting schedules. You can use the [Get Availability endpoint](/docs/reference/api/calendar/post-availability/) to find the best time for an event by identifying time periods that have no conflicting events among all participants.
## Find a calendar ID
You must specify a `calendar_id` in all calls you make to the Nylas Calendar API. You can use `primary` to specify the primary calendar associated with a grant, or you can look up the ID of the calendar that you want to work with and use that.
For virtual calendars, the `primary` calendar is the first created for a virtual account. You _cannot_ delete a virtual calendar that''s designated as `primary`.
For iCloud, there is no `primary` calendar.
## Free/Busy information
The [Get Free/Busy Schedule endpoint](/docs/reference/api/calendar/post-calendars-free-busy/) is available for all providers, including Virtual Calendars, except for iCloud.
The [Get Availability endpoint](/docs/reference/api/calendar/post-availability/) doesn''t support the `free_busy` object.
## Virtual calendars
Nylas allows you to create virtual calendars for users and resources that might not have calendars on your providers (for example, external contractors or meeting rooms). You can use the Nylas Calendar and Events APIs with the virtual accounts that power virtual calendars, just like you would any other account. Virtual accounts don''t provide email or contacts features, so you can''t use them with the Email or Contacts APIs.
For more information, see [Using virtual calendars](/docs/v3/calendar/virtual-calendars/).
## Metadata on calendars
You can add metadata to new and existing calendars by including the `metadata` sub-object in your `POST`, `PUT`, or `PATCH` request. For more information, see the [Metadata documentation](/docs/dev-guide/metadata/).
## Calendar scopes
The table below lists the Calendar endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------ | :----------------------------------------------------- |
| **GET** `/calendars`**GET** `/calendars/`**POST** `/calendars/free-busy`**POST** `/calendars/availability` | `/calendar.readonly` ☑️`/calendar` | `Calendars.Read` ☑️`Calendars.ReadWrite` |
| **POST** `/calendars`**PUT** `/calendars/`**DELETE** `/calendars/` | `/calendar` ☑️ | `Calendars.ReadWrite` ☑️ |
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
## Calendar activity notifications
You can subscribe to the following triggers so Nylas notifies you about changes to your users'' calendar data:
- `calendar.created`
- `calendar.updated`
- `calendar.deleted`
For more information, see the [Calendar webhook notification schemas](/docs/reference/notifications/#calendar-notifications).
## Microsoft event considerations
Microsoft Outlook events are often shared across all calendars in a user''s account. If the user creates an event on one of their calendars, you can retrieve it using another calendar ID from their grant.
'
- name: Events
description: "Events represent scheduled items on a calendar. The Nylas Events API uses the same commands to manage events across providers, and can refer to specific events using the provider's `event_id` parameter. Events can be public, private, or shared among a group of users. They might include details like participants, locations, and timing, along with other information.\n\nThe Events API includes the [Send RSVP endpoint](/docs/reference/api/events/send-rsvp/), which allows you to send RSVPs directly from your Nylas application, even for participants who might not have access to edit a specific event.\n\n## Metadata on events\n\nYou can add metadata to new and existing events by including the `metadata` sub-object in your `POST`, `PUT`, or `PATCH` request. For more information, see the [Metadata documentation](/docs/dev-guide/metadata/).\n\n[Agent Account](/docs/v3/agent-accounts/) grants support metadata on events, with the same 50-pair limit and the same five indexed reserved keys as connected grants.\n\n## Virtual calendars\n\nNylas allows you to create virtual calendars for users and resources that might not have calendars on your providers (for example, external contractors or meeting rooms). You can use the Nylas Calendar and Events APIs with the virtual accounts that power virtual calendars, just like you would any other account. Virtual accounts don't provide email or contacts features, so you can't use them with the Email or Contacts APIs.\n\nFor more information, see [Using virtual calendars](/docs/v3/calendar/virtual-calendars/).\n\n## Events scopes\n\nThe table below lists the Events endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.\n\nThe ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you're already using one of the permissive scopes, you don't need to add the more restrictive scope.\n\n| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |\n| :---------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------- |\n| **GET** `/events`**GET** `/events/` | `/calendar.events.readonly` ☑️`/calendar.events``/calendar` (Required to use `primary` keyword when referencing calendars.) | `Calendars.Read` ☑️`Calendars.ReadWrite` |\n| **POST** `/events`**PUT** `/events/`**DELETE** `/events/`**POST** `/events//send-rsvp` | `/calendar.events` ☑️`/calendar` (Required to use `primary` keyword when referencing calendars.) | `Calendars.ReadWrite` ☑️ |\n\nFor more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).\n\n## Events notifications\n\nYou can subscribe to the following notification triggers so Nylas notifies you about changes to your users' event data:\n\n- `event.created`\n- `event.updated`\n- `event.deleted`\n\nThese are separate from the event reminders which you might send to your users. For more information, see the [Event webhook notification schemas](/docs/reference/notifications/#event-notifications).\n\n## Microsoft event considerations\n\nMicrosoft Outlook events are often shared across all calendars in a user's account. If the user creates an event on one of their calendars, you can retrieve it using another calendar ID from their grant.\n\n## iCloud query considerations\n\nIf you're searching for an event within a certain time range on an iCloud account, the difference between `start` and `end` can't be greater than six months. If you include a time range greater than six months, Nylas returns an \"Invalid request\" error similar to the following example.\n\n```json\n\"error\": {\n \"type\": \"invalid_request_error\",\n \"message\": \"The maximum time range for iCloud event queries is 6 months.\"\n}\n```\n\nFor more information about searching for events, see [Searching with Nylas](/docs/dev-guide/best-practices/search/#search-for-events).\n"
- name: Room resources
description: 'The Nylas Contacts API allows you to return information about rooms that you can book for meetings, conferences, and other events.
## Room resource booking scopes
The table below lists the Microsoft and Google scopes for room resource bookings. All scopes must include the fully qualified URI path for the provider, as defined in the table headers. These have been omitted from the scopes due to space constraints.
The ☑️ character indicates the most restrictive scopes you can use for each provider.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :---------------------------------------------- | :------------------------------------------------------ | :----------------------------------------------------- |
| **GET** `/v3/grants//resources` | `/admin.directory.resource.calendar.readonly` ☑️️ | `Place.Read.All` ☑️️ |
For more information, see [Using scopes to request user data](/docs/dev-guide/scopes/).
'
- name: Contacts
description: 'The Nylas Contacts API allows you to create and manage contacts, and organize them into contact groups. Nylas uses the same commands to manage contacts across providers, and can refer to a specific contact using the provider''s `contact_id`.
## Contacts scopes
The table below lists the Contacts endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------- | :----------------------------------------------------- |
| **GET** `/contacts`**GET** `/contacts/`**GET** `/contact_groups` | `/contacts.readonly` ☑️`/contacts.other.readonly` ☑️`/directory.readonly`\* ☑️ | `Contacts.Read` ☑️`People.Read`\* ☑️ |
| **POST** `/contacts`**PUT** `/contacts/`**DELETE** `/contacts/` | `/contacts` ☑️ | `Contacts.ReadWrite` ☑️ |
📝 Note: To access Contacts with the inbox source, you must use the contacts.other.readonly Google scope and the People.Read Microsoft scope. For Contacts with the domain source, you must use the directory.readonly Google scope and the People.Read Microsoft scope.
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
## Contacts notifications
You can subscribe to the following triggers so Nylas notifies you about changes to your users'' data:
- `contact.updated`
- `contact.deleted`
For more information, see the [Contact notification schemas](/docs/reference/notifications/#contact-notifications).
'
- name: Notetaker
description: 'Nylas Notetaker is a real-time meeting bot that you can invite to your online meetings. It records and transcribes your discussion, and delivers results to you using the Nylas API and webhook notifications.
The [`/v3/grants//notetakers` endpoints](/docs/reference/api/notetaker/) let you interact with Nylas Notetaker while referencing a specific grant so you can use Notetaker''s [calendar sync features](/docs/v3/notetaker/calendar-sync/) for your authenticated users.
The [`/v3/notetakers` endpoints](/docs/reference/api/standalone-notetaker/) let you send Notetakers that aren''t connected to a grant as **standalone Notetakers**.
## Calendar sync
Notetaker works with the Nylas Calendar API to automatically sync with calendars and events. When you sync Notetaker with a grant''s calendar or event, Nylas tracks their join times and meeting links so the Notetaker is always sent to the meeting on time.
## Webhook notifications
Nylas sends [webhook notifications](/docs/reference/notifications/#notetaker-notifications) when a Notetaker bot is created, updated, or deleted, and when the recording media is available.
'
- name: Standalone Notetaker
description: 'Nylas Notetaker is a real-time meeting bot that you can invite to your online meetings. It records and transcribes your discussion, and delivers results to you using the Nylas API and webhook notifications.
The `/v3/notetakers` endpoints let you interact with Nylas Notetaker without referencing a grant. This lets all your users — even those who haven''t authenticated with your Nylas application — use Notetaker in their meetings.
'
- name: Application-level templates
description: 'Application-level templates let you create reusable messages with dynamic content. Each template is linked to the Nylas application associated with the API key specified in a [Create Template request](/docs/reference/api/application-level-templates/create-app-level-template/).
Nylas supports the following templating engines:
- [Handlebars](https://handlebarsjs.com/)
- [mustache }}](https://mustache.github.io/)
- [Nunjucks](https://mozilla.github.io/nunjucks/)
- [Twig](https://twig.symfony.com/)
We recommend you use [mustache }}](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/) if you need a simple implementation. If you need more advanced formatting, conditions, or layouts, we recommend [Nunjucks](https://mozilla.github.io/nunjucks/) or [Twig](https://twig.symfony.com/).
'
- name: Grant-level templates
description: 'Grant-level templates let you create reusable messages with dynamic content. Each template is linked to the grant specified in a [Create Template request](/docs/reference/api/grant-level-templates/create-grant-level-template/).
Nylas supports the following templating engines:
- [Handlebars](https://handlebarsjs.com/)
- [mustache }}](https://mustache.github.io/)
- [Nunjucks](https://mozilla.github.io/nunjucks/)
- [Twig](https://twig.symfony.com/)
We recommend you use [mustache }}](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/) if you need a simple implementation. If you need more advanced formatting, conditions, or layouts, we recommend [Nunjucks](https://mozilla.github.io/nunjucks/) or [Twig](https://twig.symfony.com/).
'
- name: Application-level workflows
description: 'Application-level workflows automatically send messages to certain users when a defined event is triggered. For example, if you want to send a confirmation message when a user schedules a booking, you can create a workflow that listens for [`booking.created` events](/docs/reference/notifications/#booking-created-notifications).
Each workflow is linked to the Nylas application associated with the API key specified in a [Create Workflow request](/docs/reference/api/application-level-workflows/create-workflow/).
'
- name: Grant-level workflows
description: 'Grant-level workflows automatically send messages to certain users when a defined event is triggered. For example, if you want to send a confirmation message when a user schedules a booking, you can create a workflow that listens for [`booking.created` events](/docs/reference/notifications/#booking-created-notifications).
Each workflow is linked to the grant specified in the [Create Workflow request](/docs/reference/api/grant-level-workflows/create-grant-workflow/).
'
- name: Configurations
description: 'A configuration is a collection of event settings and preferences. Nylas Scheduler stores Configuration objects in the Scheduler database and loads them as Scheduling Pages in the Scheduler UI.
A configuration can be either private if it uses a session, or public if it does not. By default, Nylas creates public configurations (`requires_session_auth: false`). To create a private configuration, set `requires_session_auth` to `true`.
After you create a private configuration, you can make a [`POST /v3/scheduling/sessions` request](/docs/reference/api/sessions/post-sessions/) that includes the Configuration object ID to create a session.
## Agent Accounts as the organizer
The `grant_id` in the path can be an [Agent Account](/docs/v3/agent-accounts/) grant, which makes the Agent Account the organizer of the Configuration. Guests then book against the agent''s own calendar and receive confirmation email from the agent''s own address, with no OAuth connection involved.
Two limits apply when an Agent Account is a participant:
- Set `availability.calendar_ids` to `["primary"]` and `booking.calendar_id` to `"primary"`. Scheduler reads and writes the Agent Account''s primary calendar only.
- Round-robin Configurations aren''t supported. An Agent Account can''t be a host under `max-fairness` or `max-availability`, though one-on-one, collective, and group Configurations all work.
The scopes table below covers Google and Microsoft grants. Agent Accounts have no OAuth token, so they authenticate with your API key alone. For the full walkthrough, see [Use Scheduler with Agent Accounts](/docs/v3/scheduler/agent-accounts/).
## Configurations scopes
The table below lists the Configurations endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :-------------------------------------------------------------------------------------------------- | :------------------------------------------------------ | :----------------------------------------------------- |
| **POST** `/scheduling/configurations`**PUT** `/scheduling/configuration/` | `/calendar.readonly` ☑️`/calendar` | `Calendars.Read` ☑️`Calendars.ReadWrite` |
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
'
- name: Group Events
description: 'Group meetings let you host events with multiple participants. Unlike one-on-one meetings, group events are designed for collaborative scheduling where multiple attendees are invited to the same event.
'
- name: Sessions
description: 'Nylas Scheduler uses session IDs to authorize requests to the [`/v3/scheduling/availability`](/docs/reference/api/availability/) and [`/v3/scheduling/bookings`](/docs/reference/api/bookings/) endpoints.
When you create a session, you must include the ID of an existing [Configuration object](/docs/reference/api/configurations/). Sessions are only required for private configurations (`requires_session_auth: true`).
## Time to live
For security purposes, Nylas recommends you set the `time_to_live` value for each session and refresh the sessions as they expire.
'
- name: Availability
description: 'Nylas Scheduler uses the `/v3/scheduling/availability` endpoint to retrieve availability information. When you make a request, Nylas validates the provided session ID and uses it to retrieve the related Configuration object.
When a Configuration participant is an [Agent Account](/docs/v3/scheduler/agent-accounts/), Scheduler reads busy time from that account''s primary calendar only. Set the participant''s `availability.calendar_ids` to `["primary"]`; additional calendars on the Agent Account don''t affect the returned slots.
## Availability scopes
The table below lists the Availability endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.
The ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you''re already using one of the permissive scopes, you don''t need to add the more restrictive scope.
| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |
| :--------------------------------- | :------------------------------------------------------ | :----------------------------------------------------- |
| **GET** `/scheduling/availability` | `/calendar.readonly` ☑️`/calendar` | `Calendars.Read` ☑️`Calendars.ReadWrite` |
For more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).
'
- name: Bookings
description: "Nylas Scheduler uses the `/v3/scheduling/bookings` endpoint to manage bookings.\n\nBookings work the same way when the organizer is an [Agent Account](/docs/v3/scheduler/agent-accounts/): the event is created on the Agent Account's primary calendar, and the confirmation, reschedule, cancellation, and reminder email all send from the Agent Account's own address. Each of those messages counts against the account's [daily send quota](/docs/v3/agent-accounts/send-limits/#sending-limits).\n\n## Booking types\n\nNylas Scheduler supports two booking types, `booking` and `organizer-confirmation`.\n\n`booking` represents a regular booking flow. When the booking type is `organizer-confirmation`, Nylas creates an event marked \"Pending\" in the organizer's calendar. It then sends an confirmation request email to the organizer, which includes a link to a page where the organizer can confirm or cancel the booking.\n\n### Finalizing pending bookings\n\nThe [`PUT /v3/scheduling/bookings/{booking_id}` request](/docs/reference/api/bookings/put-bookings-id/) allows the organizer to confirm or cancel a pending booking.\n\n## Booking flow\n\nThe Scheduling Component provides information about the selected time slot, and any additional information that the user added, to the [`/v3/scheduling/bookings` endpoint](/docs/reference/api/bookings/post-bookings/). The Bookings endpoint performs the following tasks:\n\n1. Validates the provided session ID and uses it to retrieve the related Configuration object.\n2. Confirms if the selected time slot is still available.\n3. Retrieves the booking participant's `grant_id`, using the list of participants' email addresses in the Configuration object.\n4. Creates an event. \n If the booking type is set to `organizer-confirmation`, a placeholder event is created in the organizer's calendar.\n5. Creates a booking entry in the database and maps the provider's event ID and Scheduler's `booking_id`.\n If the booking type is set to `organizer-confirmation`, a booking entry with the `pending` status is created. The booking entry includes the placeholder event's `booking_id` and the `additional_fields` data provided in the request.\n6. Nylas creates a booking reference based on the configuration ID and the booking ID. You can use the booking reference to reschedule and cancel the event.\n7. (Optional) Emits a booking (`booking.created`) or a pending booking (`booking.pending`) webhook, depending on the booking type.\n\n## Bookings scopes\n\nThe table below lists the Bookings endpoints and which scopes they require. The table shortens the full scope URI for space reasons, so add the prefix for the provider when requesting scopes.\n\nThe ☑️ in each column indicates the most restrictive scope you can request for each provider and still use that API. More permissive scopes appear under the minimum option. If you're already using one of the permissive scopes, you don't need to add the more restrictive scope.\n\n| Endpoint | Google Scopes`https://www.googleapis.com/auth/...` | Microsoft Scopes`https://graph.microsoft.com/...` |\n| :----------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------ | :----------------------------------------------------- |\n| **POST** `/scheduling/bookings`**DELETE** `/scheduling/bookings/`**PATCH** `/scheduling/bookings/` | `/calendar.events` ☑️`/calendar` | `Calendars.ReadWrite` ☑️ |\n\nFor more information about scopes, see [Using scopes to request user data](/docs/dev-guide/scopes/).\n"
- name: App migration
description: 'Before you begin, you should already have:
- Linked your v2 and v3 Nylas organizations. If you''re not sure if your organizations are linked and you have a contract with us, [contact Nylas Support](/docs/support/#contact-nylas-support).
- Created v3 applications to serve as the destinations for your v2 settings and connected account information.
- [Set up equivalent provider auth apps as needed](/docs/v2/upgrade-to-v3/upgrade/auth/), especially if your users are authenticating with Microsoft.
- [Set up v3 notification infrastructure](/docs/v2/upgrade-to-v3/upgrade/webhooks/). You''ll use this to keep track of object that update while you''re migrating your applications.
You make Migration API requests using the v3 API route, using an API key from the destination v3 application.
For each application to be migrated:
1. [Link apps](#post-/v3/migration-tools/link-v2v3-apps)
2. [Import app settings](#post-/v3/migration-tools/import-v2-app)
3. [Migrate a test user](#post-/v3/migration-tools/grants/-account_id-/clone) and/or [Start a batch migration](#post-/v3/migration-tools/snapshot-batch-clone)
Make sure you use the correct region! In Nylas v3, you mange applications for both the U.S. and E.U. regions using the same Dashboard. If you''re migrating a v2 application to a v3 one, make sure you create the v3 application in the correct region.
'
- name: Data migration
description: 'In Nylas v2, you used the unique Nylas ID to locate data and objects in Nylas''s synced data. In Nylas v3, you use the provider ID directly. These APIs look up the provider IDs for your v2 data.
Because every project is different, we leave it up to you to decide how your project updates the v2 IDs to v3 provider IDs.
These APIs are for one-time translation for migration purposes only. You can retry these APIs if you encounter issues, but they will be rate limited and you should not use them as part of your project''s code or object handling logic.
Some data objects that exist in Nylas v2 may not have provider IDs available, meaning they do not exist on the provider. When this happens, Nylas returns the `v3_resource_id` as `None`.
'
- name: v2 Redirects
description: 'Nylas Scheduler uses the `/v3/scheduling/should-redirect/` endpoint to redirect existing v2 Scheduling Pages to v3.
'
paths:
/v3/applications:
get:
operationId: get_application
tags:
- Applications
summary: Get application
description: Gets the application object
x-code-samples:
- lang: bash
label: cURL
source: "curl --request GET \\\n --url 'https://api.us.nylas.com/v3/applications' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst applicationDetails = await nylas.applications.getDetails();\n\nconsole.log({ applicationDetails });\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\napplication = nylas.applications.info()\napplication_id = application[1]\nprint(\"Application ID:\", application_id)\n"
- lang: ruby
label: Ruby SDK
source: "# frozen_string_literal: true\n\n# Load gems\nrequire 'nylas'\n\n# Initialize Nylas client\nnylas = Nylas::Client.new(\n api_key: ''\n)\n\napplication = nylas.applications.get_details()\nputs application\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class getApplication {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n Response application = nylas.applications().getDetails();\n \n System.out.println(application);\n }\n}"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\n\nfun main(args: Array) {\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val application = nylas.applications().getDetails()\n \n print(application)\n}"
security:
- NYLAS_API_KEY: []
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/ApplicationObject'
description: Returns Application object
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/400'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
patch:
operationId: update_application
tags:
- Applications
summary: Update an application
description: 'Updates a Nylas application using the client ID associated with the specified API key.
⚠️ This endpoint will be removed in the future when application settings are available in the Nylas Dashboard.
When you make a `PATCH` request, Nylas replaces all data in the nested object with the information
included in your request. For more information, see
[Updating objects](/docs/reference/api/#updating-objects).'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request PATCH \\\n --url 'https://api.us.nylas.com/v3/applications' \\\n --header 'Content-Type: application/json' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --data '{\n \"branding\": {\n \"name\": \"\",\n \"icon_url\": \"\",\n \"website_url\": \"\",\n \"description\": \"\"\n },\n \"hosted_authentication\": {\n \"background_image_url\": \"\",\n \"alignment\": \"\",\n \"color_primary\": \"\",\n \"color_secondary\": \"\",\n \"title\": \"\",\n \"subtitle\": \"\",\n \"background_color\": \"\",\n \"spacing\": 10\n },\n \"callback_uris\": [\n {\n \"id\": \"\",\n \"url\": \"\",\n \"platform\": \"\",\n \"settings\": {\n \"origin\": \"\",\n \"bundle_id\": \"\",\n \"package_name\": \"\",\n \"sha1_certificate_fingerprint\": \"\"\n }\n }\n ]\n }'\n"
security:
- NYLAS_API_KEY: []
requestBody:
required: true
description: ''
content:
application/json:
schema:
$ref: '#/components/schemas/ApplicationObject'
responses:
'200':
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
example: true
data:
$ref: '#/components/schemas/ApplicationObject'
description: Returns application object
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/400'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
/v3/applications/redirect-uris:
get:
operationId: get_all_callback_uris
tags:
- Applications
summary: Get an application's callback URIs
description: Returns a list of callback URIs for the specified Nylas application.
x-code-samples:
- lang: bash
label: cURL
source: "curl --request GET \\\n --url 'https://api.us.nylas.com/v3/applications/redirect-uris' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst redirectUris = await nylas.applications.redirectUris.list();\n\nconsole.log(\"Redirect URIs:\", redirectUris);\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\napplication_redirect_uris = nylas.applications.redirect_uris.list()\nprint(\"Application Redirects:\", application_redirect_uris.data)\n"
- lang: ruby
label: Ruby SDK
source: "# frozen_string_literal: true\n\n# Load gems\nrequire 'nylas'\n\n# Initialize Nylas client\nnylas = Nylas::Client.new(\n api_key: ''\n)\n\nredirect_uris, _ = nylas.applications.redirect_uris.list\n\nredirect_uris.each do |uri|\n puts uri[:url]\nend\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.ListResponse;\nimport com.nylas.models.NylasApiError;\nimport com.nylas.models.NylasSdkTimeoutError;\nimport com.nylas.models.RedirectUri;\n\npublic class GetApplicationCallbackUris {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n ListResponse redirectUris = nylas.applications().redirectUris().list();\n\n System.out.println(\"Redirect URIs: \" + redirectUris.getData());\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\n\nfun main() {\n val nylas = NylasClient(apiKey = \"\")\n\n val redirectUris = nylas.applications().redirectUris().list()\n\n println(\"Redirect URIs: ${redirectUris.data}\")\n}\n"
security:
- NYLAS_API_KEY: []
responses:
'200':
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
example: true
data:
type: array
items:
$ref: '#/components/schemas/RedirectURIObject'
description: Returns a list of callback URIs
'400':
description: Bad Request
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
example: false
error:
$ref: '#/components/schemas/400'
'404':
description: Not Found
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
error:
$ref: '#/components/schemas/404'
post:
operationId: add_callback_uri
tags:
- Applications
summary: Add callback URI to application
description: 'Adds a callback URI to the specified Nylas application. Nylas uses callback URIs to redirect users
to your project after they complete the authentication flow. If you don''t specify a `platform`,
Nylas defaults to `web`.
The OAuth protocol requires that you include the `client_secret` field for calls made to this
endpoint, depending on the `platform` you define. If you''re using
[OAuth 2.0 with PKCE](/docs/v3/auth/hosted-oauth-accesstoken/#create-grants-with-oauth-2.0-and-pkce)
and your platform is `js`, `ios`, `android`, or `desktop`, the `client_secret` field is not
required.'
security:
- NYLAS_API_KEY: []
requestBody:
required: true
description: ''
content:
application/json:
schema:
type: object
required:
- url
oneOf:
- $ref: '#/components/schemas/webDesktopCallbackNoSettings'
- $ref: '#/components/schemas/JsCallbackwSettings'
- $ref: '#/components/schemas/iosCallbackwSettings'
- $ref: '#/components/schemas/AndroidCallbackwSettings'
discriminator:
propertyName: platform
mapping:
web: '#/components/schemas/webDesktopCallbackNoSettings'
desktop: '#/components/schemas/webDesktopCallbackNoSettings'
js: '#/components/schemas/JsCallbackwSettings'
ios: '#/components/schemas/iosCallbackwSettings'
android: '#/components/schemas/AndroidCallbackwSettings'
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/RedirectURIObject'
description: Returns callback URI
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/400'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request POST \\\n --url 'https://api.us.nylas.com/v3/applications/redirect-uris' \\\n --header 'Content-Type: application/json' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --data '{\n \"platform\": \"web\",\n \"url\": \"\",\n \"id\": \"\"\n }'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst redirectUri = await nylas.applications.redirectUris.create({\n requestBody: {\n url: \"\",\n platform: \"web\",\n },\n});\n\nconsole.log(\"Redirect URI created:\", redirectUri);\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nredirect_uri = nylas.applications.redirect_uris.create(\n request_body={\n \"url\": \"https://example.com/oauth/exchange\",\n \"platform\": \"web\",\n },\n)\n\nprint(\"Created redirect URI:\", redirect_uri)\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.CreateRedirectUriRequest;\nimport com.nylas.models.NylasApiError;\nimport com.nylas.models.NylasSdkTimeoutError;\nimport com.nylas.models.Platform;\nimport com.nylas.models.RedirectUri;\nimport com.nylas.models.Response;\n\npublic class CreateRedirectUri {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n CreateRedirectUriRequest requestBody = new CreateRedirectUriRequest.Builder(\n \"\", Platform.WEB)\n .build();\n\n Response redirectUri = nylas.applications().redirectUris().create(requestBody);\n\n System.out.println(\"Redirect URI created: \" + redirectUri.getData());\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.CreateRedirectUriRequest\nimport com.nylas.models.Platform\n\nfun main() {\n val nylas = NylasClient.Builder(\"\").build()\n\n val requestBody = CreateRedirectUriRequest.Builder(\"\", Platform.WEB)\n .build()\n\n val redirectUri = nylas.applications().redirectUris().create(requestBody)\n\n println(\"Redirect URI created: ${redirectUri.data}\")\n}\n"
/v3/applications/redirect-uris/{id}:
parameters:
- example: 0556d035-6cb6-4262-a035-6b77e11cf8fc
name: id
schema:
type: string
in: path
required: true
get:
operationId: get_application_callback_uri
tags:
- Applications
summary: Return a callback URI
description: Returns the specified callback URI.
x-code-samples:
- lang: bash
label: cURL
source: "curl --request GET \\\n --url 'https://api.us.nylas.com/v3/applications/redirect-uris/' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nasync function getRedirectUri() {\n try {\n const redirectUris = await nylas.applications.redirectUris.find({\n redirectUriId: \"\",\n });\n\n console.log(\"Callback URI:\", redirectUris);\n } catch (error) {\n console.error(\"Couldn't get callback URI:\", error);\n }\n}\n\ngetRedirectUri();\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nredirect_uri = nylas.applications.redirect_uris.find(\n redirect_uri_id=\"\",\n)\n\nprint(redirect_uri)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\t\n\nnylas = Nylas::Client.new(\n\t\tapi_key: \"\"\n)\n\nredirect_uris = nylas.applications.redirect_uris.find(redirect_uri_id: \"\")\n\nputs redirect_uris"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class GetApplicationURIs {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n Response redirect_uris = nylas.applications().redirectUris().find(\"\");\n\n System.out.println(redirect_uris);\n }\n}"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\n\nfun main(args: Array) {\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val redirecturis = nylas.applications().redirectUris().find(\"\")\n\n print(redirecturis)\n}"
security:
- NYLAS_API_KEY: []
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/RedirectURIObject'
description: Returns callback URI
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
patch:
operationId: update_callback_uri
tags:
- Applications
summary: Update a callback URI
description: 'Updates the specified callback URI.
If you don''t define the `platform`, Nylas doesn''t modify the existing settings.
When you make a `PATCH` request, Nylas replaces all data in the nested object with the information
included in your request. For more information, see
[Updating objects](/docs/reference/api/#updating-objects).'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request PATCH \\\n --url 'https://api.us.nylas.com/v3/applications/redirect-uris/' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'\n --data '{\n \"url\": \"\"\n }'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst updated = await nylas.applications.redirectUris.update({\n redirectUriId: \"\",\n requestBody: {\n url: \"\",\n },\n});\n\nconsole.log(\"Redirect URI updated:\", updated);\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nredirect_uri = nylas.applications.redirect_uris.update(\n redirect_uri_id=\"\",\n request_body={\n \"url\": \"https://example.com/oauth/exchange\",\n \"platform\": \"web\",\n },\n)\n\nprint(\"Updated redirect URI:\", redirect_uri)\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.NylasApiError;\nimport com.nylas.models.NylasSdkTimeoutError;\nimport com.nylas.models.RedirectUri;\nimport com.nylas.models.Response;\nimport com.nylas.models.UpdateRedirectUriRequest;\n\npublic class UpdateRedirectUri {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n UpdateRedirectUriRequest requestBody = new UpdateRedirectUriRequest.Builder()\n .url(\"\")\n .build();\n\n Response updated = nylas.applications().redirectUris()\n .update(\"\", requestBody);\n\n System.out.println(\"Redirect URI updated: \" + updated.getData());\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.UpdateRedirectUriRequest\n\nfun main() {\n val nylas = NylasClient.Builder(\"\").build()\n\n val requestBody = UpdateRedirectUriRequest.Builder()\n .url(\"\")\n .build()\n\n val updated = nylas.applications().redirectUris().update(\"\", requestBody)\n\n println(\"Redirect URI updated: ${updated.data}\")\n}\n"
security:
- NYLAS_API_KEY: []
requestBody:
required: true
description: ''
content:
application/json:
schema:
type: object
required:
- platform
- url
oneOf:
- $ref: '#/components/schemas/webDesktopCallbackNoSettings'
- $ref: '#/components/schemas/JsCallbackwSettings'
- $ref: '#/components/schemas/iosCallbackwSettings'
- $ref: '#/components/schemas/AndroidCallbackwSettings'
discriminator:
propertyName: platform
mapping:
web: '#/components/schemas/webDesktopCallbackNoSettings'
desktop: '#/components/schemas/webDesktopCallbackNoSettings'
js: '#/components/schemas/JsCallbackwSettings'
ios: '#/components/schemas/iosCallbackwSettings'
android: '#/components/schemas/AndroidCallbackwSettings'
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/RedirectURIObject'
description: Returns callback URI
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/400'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
delete:
operationId: delete_callback_uri
tags:
- Applications
summary: Delete a callback URI
description: Deletes the specified callback URI.
x-code-samples:
- lang: bash
label: cURL
source: "curl --request DELETE \\\n --url 'https://api.us.nylas.com/v3/applications/redirect-uris/' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nasync function deleteRedirectUriId() {\n try {\n const response = await nylas.applications.redirectUris.destroy({\n redirectUriId: \"\",\n });\n\n console.log(\"Callback URI deleted:\", response);\n } catch (error) {\n console.error(\"Couldn't delete callback URI:\", error);\n }\n}\n\ndeleteRedirectUriId();\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nresponse = nylas.applications.redirect_uris.destroy(\n redirect_uri_id=\"\",\n)\n\nprint(response)\n"
- lang: ruby
label: Ruby SDK
source: "# frozen_string_literal: true\n\nrequire 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: ''\n)\n\nredirect_uris = nylas.applications.redirect_uris.destroy(redirect_uri_id: \"\")\n\nputs redirect_uris"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class DeleteApplicationURIs {\n public static void main(String[] args) throws \n NylasSdkTimeoutError, NylasApiError {\n\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n DeleteResponse redirect_uris = \n nylas.applications().redirectUris().destroy(\"\");\n System.out.println(redirect_uris);\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\n\nfun main(args: Array) {\n\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val redirecturis = nylas.applications().redirectUris().destroy(\"\")\n print(redirecturis)\n}\n"
security:
- NYLAS_API_KEY: []
responses:
'200':
$ref: '#/components/responses/200-delete'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
/v3/connectors:
post:
operationId: create_connector
tags:
- Connectors (Integrations)
summary: Create a connector
description: 'Create a connector in your Nylas application.
Connectors are how your Nylas application stores information it needs to connect to external
services. Creating a connector is the first step in setting up authentication for your project.
See [Supported providers](/docs/provider-guides/#supported-providers) for more information.'
security:
- NYLAS_API_KEY: []
requestBody:
required: true
description: ''
content:
application/json:
schema:
oneOf:
- type: object
title: Google
description: Google connector. Requires GCP OAuth app credentials.
required:
- provider
properties:
provider:
type: string
description: The provider type. For Google providers, set to `google`.
example: google
settings:
type: object
description: GCP provider auth app credentials and settings.
required:
- client_id
- client_secret
properties:
client_id:
type: string
description: The GCP app's client ID.
example: abc-def
client_secret:
type: string
description: The GCP app's client secret.
example: xyz-abc-def
topic_name:
type: string
description: Google Pub/Sub topic name. Required if using Email webhooks.
example: topic-123
scope:
type: array
items:
type: string
description: Set the default scopes for each connector. These scopes are overridden by scopes set on the specific grant.
example:
- https://www.googleapis.com/auth/userinfo.email
- https://www.googleapis.com/auth/userinfo.profile
- https://www.googleapis.com/auth/gmail.readonly
- type: object
title: Microsoft
description: Microsoft connector. Requires Azure OAuth app credentials.
required:
- provider
properties:
provider:
type: string
description: The provider type. For Microsoft providers, set to `microsoft`.
example: microsoft
settings:
type: object
description: Your Azure provider auth app credentials and settings, as stored in Entra ID.
required:
- client_id
- client_secret
properties:
client_id:
type: string
description: The Azure auth app's client ID.
example: abc-def
client_secret:
type: string
description: The Azure auth app's client secret.
example: xyz-abc-def
tenant:
type: string
description: Microsoft tenant ID.
example: abc-123-def-456
scope:
type: array
items:
type: string
description: 'Set the default scopes for each connector. Scopes set on individual grants override these scopes.
For Microsoft Graph connectors, the Nylas API accepts both the full URI version of a scope name (for example, `https://graph.microsoft.com/Calendars.Read`), as well as the short form (for example, `Calendars.Read`).'
example:
- User.Read
- Mail.Read
- type: object
title: Zoom
description: Zoom connector for managing meetings on behalf of users.
required:
- provider
properties:
provider:
type: string
description: The provider type. For Zoom providers, set to `zoom`.
example: zoom
settings:
type: object
description: 'Zoom provider credentials and settings. You can copy them from your [Zoom App](https://developers.zoom.us/docs/zoom-apps/) in [Zoom Developer Platform](https://developers.zoom.us/docs/). The Zoom Nylas connector does not support default scopes, so do not include them in the connector request.
However, you must configure the required [granular scopes](https://developers.zoom.us/docs/integrations/oauth-scopes-granular/) directly on your Zoom OAuth app. To use Zoom conferencing with Nylas events, your Zoom app needs: `meeting:write:meeting` (create), `meeting:update:meeting` (update), and `meeting:delete:meeting` (delete).'
required:
- client_id
- client_secret
properties:
client_id:
type: string
description: The Zoom app's client ID.
example: abc-def
client_secret:
type: string
description: The Zoom app's client secret.
example: xyz-abc-def
- type: object
title: iCloud
description: iCloud connector. No app credentials required.
required:
- provider
properties:
provider:
type: string
description: 'The provider type, in this case `icloud`. See
[Authenticating iCloud accounts](/docs/provider-guides/icloud/) for more
information.'
example: icloud
- type: object
title: IMAP
description: IMAP connector for generic IMAP/SMTP mail servers.
required:
- provider
properties:
provider:
type: string
description: 'The provider type, in this case `imap`. See
[Using IMAP accounts and data](/docs/provider-guides/imap/) for more information.'
example: imap
- type: object
title: EWS
description: EWS connector for Exchange on-premises servers.
required:
- provider
- settings
properties:
provider:
type: string
description: 'The provider type (in this case, `ews`). See
[Authenticating Exchange on-premises accounts](/docs/provider-guides/exchange-on-prem/)
for more information.'
example: ews
scopes:
type: string
description: Scopes settings tell Nylas to request specific data objects from the provider.
enum:
- ews.messages
- ews.calendar
- ews.contacts
examples:
- ews.messages
- ews.calendar
- ews.contacts
- type: object
title: Virtual calendars
description: Nylas-managed virtual calendar. No external provider.
required:
- provider
properties:
provider:
type: string
description: The provider type. For virtual calendars, set to `virtual-calendar`.
example: virtual-calendar
- type: object
title: Yahoo
description: Yahoo connector. Requires Yahoo OAuth app credentials.
required:
- provider
properties:
provider:
type: string
description: 'The provider type (in this case, `yahoo`). See
[Authenticating Yahoo accounts](/docs/provider-guides/yahoo/) for more information.'
example: yahoo
settings:
type: object
description: Yahoo provider credentials.
required:
- client_id
- client_secret
properties:
client_id:
type: string
description: The Yahoo app's client ID.
example: abc-def
client_secret:
type: string
description: The Yahoo app's client secret.
example: xyz-abc-def
scope:
type: array
items:
type: string
description: Set the default scopes for each connector. These scopes are overridden by scopes set on the specific grant.
example:
- email
- profile
- mail-w
- type: object
title: Nylas (Agent Account)
description: Connector for Nylas-hosted [Agent Account](/docs/v3/agent-accounts/) email and calendar mailboxes. Agent Account connectors don't support the `scope` field.
required:
- provider
properties:
provider:
type: string
description: The provider type (in this case, `nylas`).
example: nylas
responses:
'201':
description: Connector Created
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request.
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/ConnectorObject'
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/400'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request POST \\\n --url 'https://api.us.nylas.com/v3/connectors' \\\n --header 'Content-Type: application/json' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --data '{\n \"provider\": \"google\",\n \"settings\": {\n \"client_id\": \"\",\n \"client_secret\": \"\",\n \"topic_name\": \"\"\n },\n \"scope\": [\n \"https://www.googleapis.com/auth/userinfo.email\",\n \"https://www.googleapis.com/auth/userinfo.profile\"\n ]\n }'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nasync function createConnector() {\n try {\n const connector = await nylas.connectors.create({\n requestBody: {\n name: \"google\",\n provider: \"google\",\n settings: {\n clientId: \"\",\n clientSecret: \"\",\n },\n scope: [\n \"openid\",\n \"https://www.googleapis.com/auth/userinfo.email\",\n \"https://www.googleapis.com/auth/gmail.modify\",\n \"https://www.googleapis.com/auth/calendar\",\n \"https://www.googleapis.com/auth/contacts\",\n ],\n },\n });\n\n console.log(\"Connector created:\", connector);\n } catch (error) {\n console.error(\"Error creating connector:\", error);\n }\n}\n\ncreateConnector();\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nconnector = nylas.connectors.create(\n request_body={\n \"provider\": \"google\",\n \"settings\": {\n \"client_id\": \"\",\n \"client_secret\": \"\",\n },\n \"scopes\": [\n \"openid\",\n \"https://www.googleapis.com/auth/userinfo.email\",\n \"https://www.googleapis.com/auth/gmail.modify\",\n \"https://www.googleapis.com/auth/calendar\",\n \"https://www.googleapis.com/auth/contacts\",\n ],\n }\n)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: \"\"\n)\n\nrequest_body = {\n provider: \"google\",\n settings: {\n clientId: \"\",\n clientSecret: \"\",\n },\n scope: [\n 'openid',\n 'https://www.googleapis.com/auth/userinfo.email',\n 'https://www.googleapis.com/auth/gmail.modify',\n 'https://www.googleapis.com/auth/calendar',\n 'https://www.googleapis.com/auth/contacts',\n ]\n}\n\nnylas.connectors.create(request_body: request_body)"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class connector {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n List scope = new ArrayList<>();\n scope.add(\"openid\");\n scope.add(\"https://www.googleapis.com/auth/userinfo.email\");\n scope.add(\"https://www.googleapis.com/auth/gmail.modify\");\n scope.add(\"https://www.googleapis.com/auth/calendar\");\n scope.add(\"https://www.googleapis.com/auth/contacts\");\n\n GoogleCreateConnectorSettings settings = new GoogleCreateConnectorSettings(\n \"\",\n \"\",\n \"\"\n );\n\n CreateConnectorRequest request = new CreateConnectorRequest.Google(settings, scope);\n\n nylas.connectors().create(request);\n }\n} "
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.CreateConnectorRequest\nimport com.nylas.models.GoogleCreateConnectorSettings\n\nfun main(args: Array) {\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n var scope = listOf(\n \"openid\",\n \"https://www.googleapis.com/auth/userinfo.email\",\n \"https://www.googleapis.com/auth/gmail.modify\",\n \"https://www.googleapis.com/auth/calendar\",\n \"https://www.googleapis.com/auth/contacts\"\n )\n\n val settings : GoogleCreateConnectorSettings = GoogleCreateConnectorSettings(\n \"\",\n \"\",\n \"\"\n )\n\n val request : CreateConnectorRequest = CreateConnectorRequest.Google(settings, scope)\n \n nylas.connectors().create(request)\n}"
get:
operationId: get_connector_all
tags:
- Connectors (Integrations)
summary: List connectors
description: List the connectors in your Nylas application.
security:
- NYLAS_API_KEY: []
parameters:
- name: limit
in: query
schema:
type: integer
required: false
description: Limit the number of results in a connector list.
- name: offset
in: query
schema:
type: integer
required: false
description: Offset the list of results in a connector list.
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request.
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
type: array
items:
$ref: '#/components/schemas/ConnectorObject'
limit:
type: integer
example: 10
offset:
type: integer
example: 0
description: Returns an array of Connector objects.
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request GET \\\n --url 'https://api.us.nylas.com/v3/connectors' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst listConnectors = async () => {\n try {\n const connectors = await nylas.connectors.list({});\n\n console.log(\"Connectors:\", connectors);\n } catch (error) {\n console.error(\"Error fetching connectors:\", error);\n }\n};\n\nlistConnectors();\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nconnectors = nylas.connectors.list\n\nprint(\"Connectors:\", connectors)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: \"\",\n)\n\nconnectors = nylas.connectors.list()\n\nputs connectors\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class ListDraft {\n public static void main(String[] args) throws \n NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = \n new NylasClient.Builder(\"\").build();\n\n ListResponse connectors =\n nylas.connectors().list();\n System.out.println(connectors);\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\n\nfun main(args: Array) {\n \n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val connectors = nylas.connectors().list()\n println(connectors)\n}\n"
/v3/connectors/{provider}:
get:
operationId: get_connector_by_provider
tags:
- Connectors (Integrations)
summary: Get connector
description: Returns a connector for the specified provider.
security:
- NYLAS_API_KEY: []
parameters:
- $ref: '#/components/parameters/provider'
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/ConnectorObject'
description: Returns a connector object
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request GET \\\n --url 'https://api.us.nylas.com/v3/connectors/' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst getConnector = async () => {\n try {\n const connector = await nylas.connectors.find({\n provider: \"google\",\n });\n\n console.log(\"Connector\", connector);\n } catch (error) {\n console.error(\"Error fetching connector:\", error);\n }\n};\n\ngetConnector();\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nconnector = nylas.connectors.find(\n provider=\"google\"\n)\n\nprint(\"Connector:\", connector)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: \"\",\n)\n\nconnectors = nylas.connectors.find(provider: \"google\")\n\nputs connectors\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class ListDraft {\n public static void main(String[] args) throws \n NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = \n new NylasClient.Builder(\"\").build();\n\n Response connector = \n nylas.connectors().find(AuthProvider.GOOGLE);\n System.out.println(connector);\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.AuthProvider\n\nfun main(args: Array) {\n\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val connector = \n nylas.connectors().find(AuthProvider.GOOGLE)\n println(connector)\n}\n"
patch:
operationId: update_connector_by_provider
tags:
- Connectors (Integrations)
summary: Update a connector
description: 'Update the connector for the specified provider.
When you make a `PATCH` request, Nylas replaces all data in the nested object with the information
included in your request. For more information, see
[Updating objects](/docs/reference/api/#updating-objects).'
security:
- NYLAS_API_KEY: []
parameters:
- $ref: '#/components/parameters/provider'
requestBody:
required: true
description: ''
content:
application/json:
schema:
type: object
properties:
settings:
type: object
description: Oauth provider credentials and settings
example:
tenant: common
scope:
type: array
description: Oauth "scope" parameter
example:
- Mail.Read
- User.Read
- offline_access
items:
type: string
active_credential_id:
type: string
description: (Optional) The ID of the "default" credential record of this Connector. This credential will be used as a default for communication with the provider.
example: c123f8e1a-eb1c-41c0-b6a6-d2e59daf7f47
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/ConnectorObject'
description: Returns the connector object (previously called an integration) for the provider you specify.
'400':
description: Bad Request
content:
application/json:
schema:
$ref: '#/components/schemas/400'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request PATCH \\\n --url 'https://api.us.nylas.com/v3/connectors/' \\\n --header 'Content-Type: application/json' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --data '{\n \"name\": \"google\"\n }'"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nconnector = nylas.connectors.update(\n provider=\"google\",\n request_body={\n \"name\": \"google\"\n }\n)\n\nprint(\"Connector:\", connector)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: \"\"\n)\n\nrequest_body = {\n scope: [\n 'https://www.googleapis.com/auth/contacts'\n ]\n}\n\nconnector = nylas.connectors.update(provider: \"google\", request_body: request_body)\n\nputs connector\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class ListDraft {\n public static void main(String[] args) throws \n NylasSdkTimeoutError, NylasApiError {\n\n NylasClient nylas = \n new NylasClient.Builder(\"\").build();\n\n List scope = new ArrayList<>();\n scope.add(\"https://www.googleapis.com/auth/contacts\");\n\n GoogleConnectorSettings settings = new GoogleConnectorSettings();\n\n UpdateConnectorRequest.Google request = new UpdateConnectorRequest.Google.Builder()\n .settings(settings)\n .scope(scope)\n .build();\n\n nylas.connectors().update(AuthProvider.GOOGLE, request);\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.AuthProvider\nimport com.nylas.models.GoogleConnectorSettings\nimport com.nylas.models.UpdateConnectorRequest\n\nfun main(args: Array) {\n\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val settings : GoogleConnectorSettings = \n GoogleConnectorSettings()\n\n val request = \n UpdateConnectorRequest.Google(settings)\n\n val connector = \n nylas.connectors().update(AuthProvider.GOOGLE, \n request)\n println(connector)\n}\n"
delete:
operationId: delete_connector_by_provider
tags:
- Connectors (Integrations)
summary: Delete a connector
description: 'Deletes the connector for the provider you specify. All grants on the connector stop working right away, and its credentials are deleted too.
To learn what gets removed and when, see [Deleting resources and data](/docs/dev-guide/platform/deleting-resources/).'
parameters:
- $ref: '#/components/parameters/provider'
security:
- NYLAS_API_KEY: []
responses:
'200':
$ref: '#/components/responses/200-delete'
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
'404':
description: Not Found
content:
application/json:
schema:
$ref: '#/components/schemas/404'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request DELETE \\\n --url 'https://api.us.nylas.com/v3/connectors/' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\\n --header 'Content-Type: application/json'"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst provider = \"google\";\n\ntry {\n await nylas.connectors.destroy({ provider });\n console.log(`Connector with ID ${provider} removed successfully.`);\n} catch (error) {\n console.error(\"Error removing connector:\", error);\n}\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nprovider = \"google\"\n\nrequest = nylas.connectors.destroy(\n provider,\n)\n\nprint(request)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: \"\",\n)\n\nconnector = nylas.connectors.destroy(provider: \"google\")\n\nputs connector\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class ListDraft {\n public static void main(String[] args) throws \n NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n DeleteResponse connector = \n nylas.connectors().destroy(AuthProvider.GOOGLE);\n System.out.println(connector);\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.AuthProvider\n\nfun main(args: Array) {\n\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val connector = \n nylas.connectors().destroy(AuthProvider.GOOGLE)\n println(connector)\n}\n"
/v3/providers/detect:
post:
operationId: detect_provider_by_email
tags:
- Connectors (Integrations)
summary: Detect provider
description: Returns the provider if one is detected. This operation is rate limited to 20 calls per minute for each Nylas application ID.
x-code-samples:
- lang: bash
label: cURL
source: "curl --request POST \\\n --url 'https://api.us.nylas.com/v3/providers/detect?email=&all_provider_types=false' \\\n --header 'Content-Type: application/json' \\\n --header 'Accept: application/json' \\\n --header 'Authorization: Bearer ' \\"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\nconst detectProvider = async () => {\n try {\n const response = await nylas.auth.detectProvider({\n email: \"\",\n });\n\n console.log(\"Detected provider:\", response);\n } catch (error) {\n console.error(\"Error detecting provider:\", error);\n }\n};\n\ndetectProvider();\n"
- lang: python
label: Python SDK
source: "from nylas import Client\n\nnylas = Client(\n \"\",\n \"\",\n)\n\nresponse = nylas.auth.detect_provider({\n \"email\": \"\",\n})\n\nprint(\"Detected provider:\", response)\n"
- lang: ruby
label: Ruby SDK
source: "require 'nylas'\n\nnylas = Nylas::Client.new(\n api_key: \"\"\n)\n\nprovider, _ = nylas.auth.detect_provider({ email: \"\" })\n\nputs provider\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.*;\n\npublic class detect_provider {\n public static void main(String[] args) throws NylasSdkTimeoutError, NylasApiError {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n ProviderDetectParams params = new ProviderDetectParams.Builder(\"\").build();\n Response provider = nylas.auth().detectProvider(params);\n\n System.out.println(provider);\n }\n}"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.ProviderDetectParams\n\nfun main(args: Array) {\n val nylas: NylasClient = NylasClient(\n apiKey = \"\"\n )\n\n val params = ProviderDetectParams(\"\")\n val provider = nylas.auth().detectProvider(params)\n\n print(provider)\n}"
security:
- NYLAS_API_KEY: []
parameters:
- in: query
name: email
description: Email for detection
required: true
schema:
type: string
- in: query
name: all_provider_types
description: Search by all providers regardless of if they have an existing connector
schema:
default: false
type: boolean
responses:
'200':
content:
application/json:
schema:
type: object
properties:
request_id:
type: string
description: ID of the request
example: 5967ca40-a2d8-4ee0-a0e0-6f18ace39a90
data:
$ref: '#/components/schemas/AutodetectObject'
description: Returns the autodetected provider
'401':
description: Not Authenticated
content:
application/json:
schema:
$ref: '#/components/schemas/401'
/v3/connect/auth:
get:
operationId: get_oauth2_flow
tags:
- Authentication APIs
summary: Hosted OAuth - Authorization Request
description: 'The initial OAuth 2.0 authorization request. Use this endpoint with the required query parameters to start the OAuth 2.0 process. The query parameters pass details to the Nylas API about how the user should authenticate, and where they should go after authenticating.
This endpoint supports the authorization code flow and optional PKCE settings for client-side only applications. For more information, see the [Hosted OAuth with access token](/docs/v3/auth/hosted-oauth-accesstoken/) and [Hosted OAuth with access token and PKCE](/docs/v3/auth/hosted-oauth-accesstoken/#create-grants-with-oauth-2.0-and-pkce) documentation.'
x-code-samples:
- lang: bash
label: cURL
source: "curl --request GET \\\n --url 'https://api.us.nylas.com/v3/connect/auth?client_id=&redirect_uri=https%3A%2F%2Fyourapp.com%2Fcallback&response_type=code&provider=google&login_hint=user@example.com'\n"
- lang: javascript
label: Node.js SDK
source: "import Nylas from \"nylas\";\n\nconst nylas = new Nylas({\n apiKey: \"\",\n apiUri: \"\",\n});\n\n// Build a hosted-authentication URL. Redirect the user to this URL to start\n// the OAuth flow; Nylas calls back to your `redirectUri` with an authorization\n// code that you exchange for a grant via `nylas.auth.exchangeCodeForToken()`.\nconst authUrl = nylas.auth.urlForOAuth2({\n clientId: \"\",\n provider: \"google\",\n redirectUri: \"http://localhost:3000/oauth/exchange\",\n loginHint: \"email_to_connect@example.com\",\n accessType: \"offline\",\n});\n\nconsole.log(authUrl);\n"
- lang: python
label: Python SDK
source: "@app.route(\"/nylas/auth\", methods=[\"GET\"])\ndef login():\n if session.get(\"grant_id\") is None:\n config = URLForAuthenticationConfig({\"client_id\": \"\", \n \"redirect_uri\" : \"http://localhost:5000/oauth/exchange\"})\n\n url = nylas.auth.url_for_oauth2(config)\n return redirect(url)\n else:\n return f'{session[\"grant_id\"]}'\n\n@app.route(\"/oauth/exchange\", methods=[\"GET\"])\ndef authorized():\n if session.get(\"grant_id\") is None:\n code = request.args.get(\"code\")\n\n exchangeRequest = CodeExchangeRequest({\"redirect_uri\": \"http://localhost:5000/oauth/exchange\",\n \"code\": code, \"client_id\": \"\"})\n\n exchange = nylas.auth.exchange_code_for_token(exchangeRequest)\n session[\"grant_id\"] = exchange.grant_id\n\n return redirect(url_for(\"login\"))\n"
- lang: ruby
label: Ruby SDK
source: "# frozen_string_literal: true\n\nrequire 'nylas'\nrequire 'sinatra'\n\nnylas = Nylas::Client.new(\n api_key: \"\"\n)\n\nset :show_exceptions, :after_handler\n\nerror 404 do\n 'No authorization code returned from Nylas'\nend\n\nerror 500 do\n 'Failed to exchange authorization code for token'\nend\n\n# Build the hosted-authentication URL and redirect the user there.\nget '/nylas/auth' do\n config = {\n client_id: \"\",\n provider: 'google',\n redirect_uri: 'http://localhost:4567/oauth/exchange',\n login_hint: '',\n access_type: 'offline'\n }\n\n url = nylas.auth.url_for_oauth2(config)\n redirect url\nend\n\n# Receive the authorization code and exchange it for a grant.\nget '/oauth/exchange' do\n code = params[:code]\n status 404 if code.nil?\n\n begin\n response = nylas.auth.exchange_code_for_token({\n client_id: \"\",\n redirect_uri: 'http://localhost:4567/oauth/exchange',\n code: code\n })\n rescue StandardError\n status 500\n else\n \"Grant_Id: #{response[:grant_id]} \\n Email: #{response[:email]}\"\n end\nend\n"
- lang: java
label: Java SDK
source: "import com.nylas.NylasClient;\nimport com.nylas.models.AccessType;\nimport com.nylas.models.AuthProvider;\nimport com.nylas.models.UrlForAuthenticationConfig;\n\npublic class HostedAuthUrl {\n public static void main(String[] args) {\n NylasClient nylas = new NylasClient.Builder(\"\").build();\n\n // Build a hosted-authentication URL. Redirect the user to this URL to start\n // the OAuth flow; Nylas calls back to your `redirectUri` with an authorization\n // code that you exchange for a grant via `nylas.auth().exchangeCodeForToken()`.\n UrlForAuthenticationConfig config = new UrlForAuthenticationConfig.Builder(\n \"\",\n \"http://localhost:3000/oauth/exchange\")\n .provider(AuthProvider.GOOGLE)\n .accessType(AccessType.OFFLINE)\n .loginHint(\"email_to_connect@example.com\")\n .build();\n\n String url = nylas.auth().urlForOAuth2(config);\n\n System.out.println(url);\n }\n}\n"
- lang: kotlin
label: Kotlin SDK
source: "import com.nylas.NylasClient\nimport com.nylas.models.AccessType\nimport com.nylas.models.AuthProvider\nimport com.nylas.models.UrlForAuthenticationConfig\n\nfun main() {\n val nylas = NylasClient.Builder(\"\").build()\n\n // Build a hosted-authentication URL. Redirect the user to this URL to start\n // the OAuth flow; Nylas calls back to your `redirectUri` with an authorization\n // code that you exchange for a grant via `nylas.auth().exchangeCodeForToken()`.\n val config = UrlForAuthenticationConfig.Builder(\n \"\",\n \"http://localhost:3000/oauth/exchange\")\n .provider(AuthProvider.GOOGLE)\n .accessType(AccessType.OFFLINE)\n .loginHint(\"email_to_connect@example.com\")\n .build()\n\n val url = nylas.auth().urlForOAuth2(config)\n\n println(url)\n}\n"
parameters:
- in: query
name: client_id
required: true
description: Your Nylas application's client ID (or application ID).
schema:
type: string
- in: query
name: provider
required: false
description: 'The connector provider type that you set up with Nylas for this application. If the provider
isn''t set, the user is directed to the Nylas Hosted login page and prompted to select their
provider. Multiple providers can be set as a comma-separated list.'
schema:
type: string
enum:
- google
- microsoft
- imap
- icloud
- yahoo
- ews
- zoom
- in: query
name: redirect_uri
required: true
description: Your project's callback URI (used as the OAuth `redirect_uri`). This is where the OAuth provider sends a user after they authenticate using Hosted OAuth. This must be URL-encoded.
schema:
type: string
example: redirect_uri=https%3A%2F%2Fapp.example.com&
- in: query
name: response_type
required: true
description: Specifies the type of response Nylas returns for the authorization flow. Should be set to `code` for the OAuth 2.0 flow, and `adminconsent` for the Microsoft admin consent service flow.
schema:
type: string
enum:
- code
- adminconsent
- in: query
name: scope
description: 'A space-delimited list of scopes that identify the resources that your application may access
on the user''s behalf. If no scopes are set, Nylas uses the default connector scopes.'
schema:
type: string
- in: query
name: prompt
required: false
description: '(Optional) The prompt for the Hosted login page. This parameter can accept multiple values
separated by a comma, without spaces in between. The order of the prompts affects the UI of
the Hosted login page.
If `provider` is not set, the user is redirected to the provider page directly, and the prompt
is ignored.'
schema:
type: string
default: select_provider
enum:
- select_provider
- detect
- select_provider,detect
- detect,select_provider
- in: query
name: state
description: (Optional) The state of the grant, returned after authentication. The maximum length is 256 characters.
schema:
type: string
- in: query
name: login_hint
description: Prefill the login name (usually the email address) during the authentication flow. If a grant already exists for the provided email address, Nylas automatically re-authenticates the grant.
schema:
type: string
- in: query
name: access_type
description: Specifies whether Nylas should return a refresh token along with the exchange token. This isn't suitable for client-side or JavaScript applications.
schema:
type: string
enum:
- offline
- online
- in: query
name: code_challenge
description: Specifies a Base64-encoded `code_verifier` without padding. The verifier is used as a server-side challenge during the authorization code exchange.
schema:
example: e96bf6686a3c3510e9e927db7069cb1cba9b99b022f49483a6ce3270809e68a2
type: string
- in: query
name: code_challenge_method
description: Specifies the method used to encode the `code_verifier`. The verifier is used as a server-side challenge during the authorization code exchange.
schema:
example: S256
type: string
enum:
- plain
- S256
default: plain
- in: query
name: credential_id
description: 'The ID of an existing Nylas connector''s credential record.
If you set the `response_type` value to `code` then you can use the credential to override an OAuth connector''s default settings and create a grant. You need to [create a credential record](/docs/reference/api/connector-credentials/create_credential/) before you can make a credential override request. If not provided, connector''s default "active_credential_id" is used.
If you set the `response_type` value to `adminconsent`, with provider Microsoft, then this will be the OAuth of Microsoft''s Service Account Admin Consent flow. You need to [set up the Microsoft connector with an Admin Consent credential before you can make this request](/docs/v3/auth/bulk-auth-grants/#set-up-microsoft-admin-consent-flow).'
schema:
type: string
example: e19f8e1a-eb1c-41c0-b6a6-d2e59daf7f47
- in: query
name: options
description: '(Google only) Set to `exclude_google_granted_scopes` to exclude Google-granted scopes from the
authorization request.'
schema:
type: string
example: options=exclude_google_granted_scopes
responses:
'302':
description: Redirects user to provider's authorization page
headers:
Location:
description: Location header.
schema:
type: string
format: url
example: 'https://accounts.google.com/o/oauth2/auth/oauthchooseaccount?prompt=consent&login_hint=email@google.com&access_type=offline&state= &redirect_uri=https://api.us.nylas.com/v3/connect/callback&response_type=code&client_id=
'
'400':
$ref: '#/components/responses/400'
/v3/connect/token:
post:
operationId: exchange_oauth2_token
tags:
- Authentication APIs
summary: Hosted OAuth - Token exchange
description: "The standard OAuth token endpoint for Hosted Authentication. This endpoint doesn't require authentication, as it is part of the auth process.\nYou can pass one of the following `grant_type` values:\n- `authorization_code`: Exchange the `code` Nylas returns from the OAuth 2.0 authorization flow for tokens (`access_token` and `refresh_token`). - `refresh_token`: Use the existing `refresh_token` for an existing grant to issue a new `access_token`. You _must_ pass your API key in the `client_secret` field.\n - `client_credentials`: Issue a new short-lived (1 hour) `access_token` using an existing `grant_id`. You _must_ pass your API key in the `client_secret` field. This is mainly used in Scheduler implementations.\n\nThis endpoint accepts both `application/json` and `application/x-www-form-urlencoded` request body types. The body parameters are the same for both, with the same naming conventions.\nFor more information, see the [Hosted authentication with access token documentation](/docs/v3/auth/hosted-oauth-accesstoken/).\n### Failed token exchange requests\nEach OAuth `code` is a unique, one-time-use credential. If your token exchange fails, you must restart the OAuth process. If you try to pass the original `code` in another token exchange request, the provider rejects the `code` and Nylas returns an error."
security: []
requestBody:
required: true
description: ''
content:
application/json:
schema:
oneOf:
- type: object
title: Exchange code
description: Exchange an authorization code for access and refresh tokens.
required:
- code
- client_id
- client_secret
- redirect_uri
- grant_type
properties:
client_id:
example:
type: string
description: Your Nylas application's client ID.
client_secret:
example:
type: string
description: Your Nylas application's API key.
grant_type:
example: authorization_code
type: string
description: Supports exchanging a `code` for a token, or refreshing an access token using a `refresh_token` and `client_credentials` for issuing short-lived access based on the grant id provided.
enum:
- authorization_code
code:
type: string
description: The `code` from the OAuth 2.0 authorization flow.
redirect_uri:
example: https://example.com/callback-handler
format: url
type: string
description: 'The URL that Nylas uses to redirect the user to your project after they complete
the authorization flow. This should match the `callback_uri` or `redirect_uri` that
you used to get the `code` during your initial
[authorization request](/docs/reference/api/authentication-apis/get_oauth2_flow/).'
code_verifier:
example: nylas
type: string
description: 'The plaintext `code` verifier (`code_challenge`) that you created in your
[authorization request](/docs/reference/api/authentication-apis/get_oauth2_flow/).'
- type: object
title: Refresh access token
description: Use a refresh token to issue a new access token.
required:
- refresh_token
- client_id
- client_secret
- grant_type
properties:
client_id:
example:
type: string
description: Your Nylas application's client ID.
client_secret:
example:
type: string
description: Your Nylas application's API key.
grant_type:
example: refresh_token
type: string
description: Supports exchanging a `code` for a token, or refreshing an access token using a `refresh_token` and `client_credentials` for issuing short-lived access based on the grant id provided.
enum:
- refresh_token
refresh_token:
example:
type: string
description: Required to refresh or request a short-lived access token.
- type: object
title: Client credentials
description: Issue a short-lived access token for an existing grant.
required:
- grant_id
- client_id
- client_secret
- grant_type
properties:
client_id:
example:
type: string
description: Your Nylas application's client ID.
client_secret:
example:
type: string
description: Your Nylas application's API key.
grant_type:
example: refresh_token
type: string
description: Supports exchanging a `code` for a token, or refreshing an access token using a `refresh_token` and `client_credentials` for issuing short-lived access based on the grant id provided.
enum:
- client_credentials
grant_id:
example:
type: string
description: Required to request a short-lived access token for a specific grant.
responses:
'200':
description: The token exchange was successful.
content:
application/json:
schema:
type: object
title: data
properties:
access_token:
example:
type: string
description: Supports exchanging a `code` for a token, or refreshing an access token using a `refresh_token`.
expires_in:
example: 3600
type: integer
default: 3600
description: The remaining lifetime of the access token, in seconds.
id_token:
example:
type: string
description: 'A JSON web token (JWT) that contains identity information about a user. It''s digitally
signed by Nylas.'
email:
example: example@gmail.com
type: string
description: The email address associated with the provider token exchange.
refresh_token:
example: