Skip to content
Skip to main content

Creating grants with Hosted Authentication and an API key

Last updated:

Nylas supports Hosted OAuth to get the user’s authorization for scopes and create their grant. You can then use their grant ID and your application-specific API key to access their data and make other requests. This allows you to use the same request method for everything in your project, including endpoints that don’t specify a grant (for example, the webhook endpoints).

How Hosted OAuth with an API key creates a grant

Recommended for server-side apps. Your backend exchanges the one-time code with your API key and keeps only the grant ID. Nylas stores and refreshes the user's provider tokens, so every later request uses your API key and that grant ID.
Diagram as text
  • You, once: Tell Nylas where to send users back: Register your app's callback URL once, so Nylas knows where to return users after they sign in. Do it in the Dashboard (Hosted authentication > Callback URIs) or with POST /v3/applications/redirect-uris, platform web.
  • Your app: Send the user to sign in: Your app redirects the user to a Nylas sign-in page that says which app is asking and where to send the user afterwards.
    • Request details: GET /v3/connect/auth with client_id, redirect_uri, and response_type=code. Optional:
    • Request details: provider: skip the provider picker, for example google.
    • Request details: login_hint: prefill the user's email address.
    • Request details: scope: request specific scopes. Without it, Nylas uses the connector's default scopes.
    • Request details: state: a value Nylas returns to you unchanged, up to 256 characters.
    • URI not registered → Request rejected: Nylas only sends users back to callback URLs you registered. The redirect_uri must match one exactly.
  • User: Signs in: On the provider's consent screen (Google, Microsoft, Yahoo, Zoom), or in a Nylas-hosted form for IMAP, iCloud, and EWS passwords.
  • Nylas: Send the user back with a code: Once the user approves, Nylas returns them to your callback URL with a one-time code. The code proves the user said yes, but it doesn't give access by itself.
  • Your backend: Trade the code for a grant ID: Your backend sends the code to Nylas together with your API key. Nylas checks both, finishes connecting the user's account (a grant), and returns its grant ID.
    • Request details: POST /v3/connect/token with client_id, your API key as client_secret, grant_type=authorization_code, the code, and the same redirect_uri as before.
    • Code already used, or redirect_uri differs → Exchange fails: A code works only once. Send the user through sign-in again to get a new code.
  • Your backend: Save the grant ID and use it: Store the grant ID with your user's record. To read or send their email and calendar, call the API with that grant ID and your API key. Nylas keeps the user's provider tokens refreshed, so you never handle them.
    • Request details: /v3/grants/{grant_id}/... with Authorization: Bearer <NYLAS_API_KEY>.
  1. The user clicks a link or button in your project to start an authorization request.
  2. Nylas forwards the user to their provider where they complete the authorization flow.
  3. The provider directs the user to the Nylas callback URI and includes URL parameters that indicate whether the authorization succeeded or failed, along with other information.
  4. If the authorization succeeded, Nylas creates an unverified grant record.
  5. Nylas forwards the user to your project’s callback URI and includes a one-time code as a URL parameter.
  6. Your project uses the code to perform a token exchange with Nylas.
  7. When the token exchange completes successfully, Nylas marks the grant record as verified and creates a grant ID for the user.

The first step of the authentication process is to start an authorization request. Usually this is a button or link that the user clicks.

Your project redirects the user to the authorization request endpoint and includes their information as a set of query parameters, as in the example below. When the user goes to this URL, Nylas starts a secure authentication session and redirects them to their provider’s website.

If you’ve registered a custom hostname, swap api.<region>.nylas.com for it in this URL and everything else about the flow stays the same. See whitelabel Hosted Authentication.

Each provider displays their authorization consent and approval steps differently. The steps are visible only to the user.

Nylas Hosted OAuth supports the optional state parameter. If you include it in an authorization request, Nylas returns the unmodified value to your project. You can use this as a verification check, or to track information about the user that you need when creating a grant or logging them in.

For more information about the state parameter, see the OAuth 2.0 specification and the official OAuth 2.0 documentation.

After the user completes the authorization process, their provider sends them to Nylas’ redirect URI (https://api.us.nylas.com/v3/connect/callback) and includes URL parameters with information about the user. Nylas uses the information in the parameters to find your application using its client ID and, if the authentication succeeded, create an unverified grant record for the user.

Nylas then uses your application’s callback URI to direct the user back to your project, along with a one-time code.

https://myapp.com/callback-handler?code=<CODE>

If you specified a state in the initial authorization request, Nylas includes it as a URL parameter.

Make a POST /v3/connect/token request to exchange the user’s code for an access token. Nylas returns an access token and other information about the user.

Nylas marks the user’s grant as verified and sends you their grant ID and email address.

After you complete the OAuth flow and receive a grant ID, verify that your authentication is working before building it into production code. The commands below use the Nylas CLI — install it first if you haven’t already.

List all connected grants to confirm the authentication succeeded with nylas auth list:

Test a simple API call with your grant ID and API key using nylas email list:

If both commands succeed, your grant is verified and ready to use. If you see errors, double-check that:

  • Your NYLAS_API_KEY is set correctly in your environment
  • The grant ID matches the one returned from the OAuth flow
  • The user completed the authorization process successfully

Now that you have a grant ID for your user, you can make requests on their behalf with your application’s API key and their grant ID.