# Create and revoke API keys

Source: https://developer.nylas.com/docs/cookbook/use-cases/build/manage-api-keys/

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?

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.

```bash
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?

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

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](/docs/v3/auth/nylas-service-account/) for the signing details.

## What's next

- [Nylas Service Account auth](/docs/v3/auth/nylas-service-account/) for the RSA request signing these endpoints need
- [Authentication overview](/docs/v3/auth/) for where API keys fit the auth model
- [Connect user accounts with OAuth](/docs/cookbook/use-cases/build/connect-user-accounts-oauth/) for the user-facing credential, the grant
- [Handle grant expiry and re-authentication](/docs/cookbook/use-cases/build/handle-grant-expiry/) for the other credential lifecycle