Skip to content

Authenticating with a Nylas Service Account

The Nylas Service Account is in beta. The authentication mechanism and features may change before general availability.

Nylas Service Accounts are different from Google and Microsoft “Service Accounts”. Google and Microsoft Service Accounts are used for bulk authentication grants. Nylas Service Accounts are an organization-level authentication mechanism that uses cryptographic request signing to access admin APIs like the Manage Domains API.

A Nylas Service Account authenticates your requests to organization-level Nylas admin APIs. Unlike API keys and access tokens, Nylas Service Account authentication uses RSA cryptographic request signing. Each request includes a signature generated from your private key, which Nylas verifies server-side.

Currently, Nylas Service Account authentication is used by:

To get a Nylas Service Account, contact Nylas Support. They will provide you with a credentials JSON file.

Your Nylas Service Account credentials file contains the following fields:

FieldDescription
nameA human-readable name for the service account.
typeThe credential type. Always "service_account".
private_key_idThe unique identifier for your private key. Used as the X-Nylas-Kid header value.
private_keyYour RSA private key in PEM format. Used to sign requests.
organization_idThe ID of your Nylas organization.
regionThe Nylas data center region (us or eu).

Store your credentials file securely. The private key grants access to organization-level admin APIs. Never commit it to version control or expose it in client-side code. Use a secrets manager or environment variables.

Every request authenticated with a Nylas Service Account must include these four custom headers:

HeaderDescription
X-Nylas-KidThe private_key_id from your credentials file. Identifies which key Nylas should use to verify the signature.
X-Nylas-TimestampThe current time in seconds as a Unix timestamp. Must be within 5 minutes of the server time.
X-Nylas-NonceA unique, randomly generated string (minimum 16 characters) for each request. Nylas rejects duplicate nonces to prevent replay attacks.
X-Nylas-SignatureA Base64-encoded RSA-SHA256 signature of the request. See Generating the signature for details.

To generate the X-Nylas-Signature header value, follow these steps:

  1. Build the canonical data object containing:

    • path — the API endpoint path (for example, /v3/admin/domains)
    • method — the HTTP method in lowercase (for example, get, post)
    • timestamp — the same Unix timestamp used in X-Nylas-Timestamp
    • nonce — the same nonce used in X-Nylas-Nonce
    • payload — (only for POST/PUT/PATCH) the canonical JSON request body as a string. Omit this field for GET and DELETE requests.
  2. Serialize to canonical JSON. The keys must be sorted alphabetically with no extra whitespace.

  3. Hash the canonical JSON. Compute a SHA-256 digest of the serialized string.

  4. Sign the hash. Sign the SHA-256 digest using RSA PKCS#1 v1.5 with your private key (2048-bit minimum).

  5. Encode the signature. Base64-encode the resulting signature bytes.

Keep your system clock synchronized. Nylas rejects requests where the X-Nylas-Timestamp header differs from the server time by more than 5 minutes. Use NTP to keep your clock accurate.

The following Go program generates signed curl commands for testing the Manage Domains API. For production use, integrate the signing logic directly into your application.

Usage: Set the required environment variables and run the program.