Skip to content
Skip to main content

Manage Grants

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:

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.

⚠️ If message tracking events occur while a grant is out of service for more than 72 hours, you cannot backfill the notifications. This includes message.opened, message.link_clicked, and thread.replied notifications.

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.

Endpoints

10
POST
Bring Your Own Authentication
POST /v3/connect/custom

Manually creates a grant using the Bring Your Own (BYO) Authentication flow. If you're handling the OAuth flow in your own project or you want to migrate existing users, BYO Auth lets you provide the...

GET
Return all grants
GET /v3/grants

Returns all grants in your Nylas application.

GET
Get a grant
GET /v3/grants/{grantId}

Gets a grant with the provided ID. If the grant's grant status is invalid, the grant has expired and needs to be re-authenticated. See Handling expired grants for best practices on detection and recov...

PATCH
Update a grant
PATCH /v3/grants/{grantId}

Updates the specified grant's display name, provider settings, scope data, or workspace. Common use cases: Rotate a refresh token — If you obtain a new refresh token from a provider (for example, afte...

DELETE
Delete a grant
DELETE /v3/grants/{grantId}

Delete an existing grant by ID. You cannot re-authenticate the deleted grant. If you try to re-authenticate it, Nylas creates a new grant instead. Before deleting a grant, consider whether re-authenti...

GET
Get grant settings
GET /v3/grants/{grant_id}/settings

Returns every public setting for the grant, one key per setting. A setting that isn't set is null. The response schema describes each setting.

GET
Get a grant setting
GET /v3/grants/{grant_id}/settings/{setting_name}

Returns one setting for the grant, in the same shape as Get grant settings. If the setting isn't set, its value is null.

PUT
Create or replace a grant setting
PUT /v3/grants/{grant_id}/settings/{setting_name}

Creates the setting, or replaces it if it already exists. Send the value under the same key as setting name. You don't need to know whether the grant already has a value, and retrying the same request...

DELETE
Delete a grant setting
DELETE /v3/grants/{grant_id}/settings/{setting_name}

Removes the setting and returns the grant to that setting's default behavior. Get grant settings describes each setting's default. Returns 200 whether or not the setting had a value, so retrying the r...

GET
Get current grant
GET /v3/grants/me

Gets a grant using current access token