Using multiple provider applications

Nylas supports using multiple provider auth applications (Credentials) with a single Connector. This allows you to authenticate users with different provider applications while maintaining a single Connector per provider in your Nylas application. For example, this would allow you to have multiple Azure Applications (Credentials) for Microsoft authentication (Connector).

When to use multiple provider applications

Use multiple provider applications when you need to authenticate users with different provider auth apps under the same Connector. Common use cases include:

Enterprise customers who own their provider applications: Some enterprise customers have security or compliance requirements that require them to own and control their provider applications (for example, their own Google Cloud Platform project or Azure app). They can’t use your application’s provider app, but you can still authenticate them by creating a Credential using their provider application credentials.
Separate provider applications per environment: You might want to use different provider applications for development, staging, and production environments while maintaining a single Connector.
Customer-specific provider applications: If different customers require their own provider applications, you can create separate Credentials for each customer’s provider app and authenticate users with the appropriate Credential.

Understanding Connectors and Credentials

Connector refers to the provider type (Microsoft, Google, etc.) in your Nylas application. Each Connector can have multiple Credentials, where each Credential represents a combination of a provider’s client_id and client_secret.

When you create a Connector, Nylas automatically creates a primary Credential using the provider application credentials you provide. This becomes the default Credential too. The primary Credential is identified by the Connector’s active_credential_id field. You can create additional Credentials for the same Connector to use different provider applications.

Each Credential has a unique credential_id that you can use to specify which provider application should be used when authenticating users. Grants belong to specific Credentials, and Nylas uses the Credential’s provider application settings when making API calls on behalf of those grants.

You can change the default Credential that’s used by changing the Connector’s active_credential_id field.

Create a Credential

To use a different provider application with an existing Connector, you need to create a new Credential for that Connector.

First, create your new provider auth app (for example, a new Azure app or Google Cloud Platform project) or have your customer create it. Get the Application ID (client_id) and Secret Key (client_secret) from the provider.

Then, make a Create Credential request to create a new Credential for your Connector. Set credential_type to connector and include the provider’s client_id and client_secret in the credential_data object.

curl --request POST \
  --url 'https://api.us.nylas.com/v3/connectors/<CONNECTOR>/creds' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json, application/gzip' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --data '{
    "name": "CONNECTOR",
    "credential_type": "connector",
    "credential_data": {
      "client_id": "<CLIENT_ID>",         // PROVIDER_CLIENT_ID or NYLAS_CLIENT_ID, depending on credential type.
      "client_secret": "<CLIENT_SECRET>"  // PROVIDER_CLIENT_SECRET or NYLAS_CLIENT_SECRET, depending on credential type.
    }
  }'

The response includes a data.id field, which is the credential_id you’ll use when authenticating users with this provider application.

Authenticate users with a specific Credential

After you create a Credential, you can use its credential_id to authenticate users with that specific provider application. The method you use depends on your authentication flow.

Hosted OAuth authentication

If you’re using Hosted OAuth, add the credential_id as a query parameter when you build your authorization request. Include credential_id along with your other authorization parameters.

When the user completes authentication, they’re authenticated using the provider application associated with the specified credential_id. The token exchange process works the same as a standard Hosted OAuth flow—make a POST /v3/connect/token request to exchange the authorization code for a grant ID.

If you don’t specify a credential_id in your authorization request, Nylas uses the Connector’s active Credential (identified by the Connector’s active_credential_id field).

The credential_id parameter works with response_type=code authorization requests. For Microsoft Service Account Admin Consent flows, the Credential is specified when you create the Credential, not in the authorization URL.

Bring Your Own Authentication

If you’re using Bring Your Own Authentication, include the credential_id in the settings object when you make a POST /v3/connect/custom request.

curl --request POST \
  --url 'https://api.us.nylas.com/v3/connect/custom' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json, application/gzip' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --data '{
    "provider": "google",
    "settings": {
      "credential_id": "<CREDENTIAL_ID>",
      "refresh_token": "<REFRESH_TOKEN>"
    }
  }'

Add credential_id to the settings object in your request. The grant response includes the credential_id field, indicating which Credential (and therefore which provider application) the grant is associated with.

If you don’t specify a credential_id in your request, Nylas uses the Connector’s active Credential.

Migrate grants between Credentials

To migrate a user from one Credential to another, re-authenticate the user with the new credential_id using one of the authentication methods above (Hosted OAuth or Bring Your Own Authentication). Nylas handles the migration and preserves the existing grant—you keep the same grant ID and other grant information.