API keys are the credential behind every Nylas request, so you need to manage them like any other secret: rotate them on a schedule, issue scoped keys for different environments, and revoke one fast if it leaks. Doing that through the dashboard by hand doesn’t fit an automated security posture.
The Nylas admin API manages keys programmatically. You create, list, and revoke keys with API calls, so key rotation becomes a scheduled job instead of a manual chore.
How do I create an API key?
Section titled “How do I create an API key?”Send a POST /v3/admin/applications/{application_id}/api-keys request with a name and an expires_in lifetime in days. The API returns the key value in the create response, so capture it immediately. These admin endpoints don’t authenticate with a normal API key; they require a Nylas Service Account, which signs each request with RSA headers rather than a Bearer token.
curl -X POST "https://api.us.nylas.com/v3/admin/applications/<NYLAS_APPLICATION_ID>/api-keys" \ -H "Content-Type: application/json" \ -H "X-Nylas-Signature: <BASE64_SIGNATURE>" \ -H "X-Nylas-Kid: <SERVICE_ACCOUNT_ID>" \ -H "X-Nylas-Nonce: <NONCE>" \ -H "X-Nylas-Timestamp: 1676412353123" \ -d '{ "name": "example-key", "expires_in": 3600 }'Setting expires_in in days (for example, 30 days for a short-lived key) means a key ages out on its own, which limits the blast radius of a leak.
How do I list and revoke keys?
Section titled “How do I list and revoke keys?”List an application’s keys with GET /v3/admin/applications/{application_id}/api-keys, which returns each key’s ID, name, and expiry without the secret value. To revoke one, send a DELETE to /v3/admin/applications/{application_id}/api-keys/{api_key_id}. The key stops working immediately, which is exactly what you want the moment a key leaks. Keys past their expires_in (for example, 30 days) also stop working on their own.
Together these 3 operations, create, list, and delete, let you run rotation as code: mint a new key, deploy it, then delete the old one.
Things to know about API keys
Section titled “Things to know about API keys”A few constraints shape how you build this. The admin endpoints sit under /v3/admin and require a Service Account, so set that up first; a standard API key can’t call them. Requests are signed with the X-Nylas-Signature, X-Nylas-Kid, X-Nylas-Nonce, and X-Nylas-Timestamp headers, which is 4 headers your signing code must produce per request.
The created key value comes back in the create response, so store it in your secrets manager right away rather than expecting to read it back later. Pair that with a short expires_in, like 30 days, so a key you forget to rotate ages out on its own. See Nylas Service Account auth for the signing details.
What’s next
Section titled “What’s next”- Nylas Service Account auth for the RSA request signing these endpoints need
- Authentication overview for where API keys fit the auth model
- Connect user accounts with OAuth for the user-facing credential, the grant
- Handle grant expiry and re-authentication for the other credential lifecycle