> ## Documentation Index
> Fetch the complete documentation index at: https://docs.context.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage API keys

> Restrict API access, inspect usage by key, and rotate shared credentials.

Create and manage API keys in the [dashboard](https://context.dev/dashboard). Each key belongs to one organization. Keep it in a server-side environment variable or secret manager, such as `CONTEXT_DEV_API_KEY`.

## Choose permissions

New keys default to **Full access**. Existing keys also retain full access. Choose **Restricted** when an integration needs only selected operations; a restricted key with no permissions cannot call the API.

| Dashboard group | Scope                              | Allows                                                                                |
| --------------- | ---------------------------------- | ------------------------------------------------------------------------------------- |
| Account logs    | `logs:read`                        | Organization request logs, including retained request input and response content.     |
| Data APIs       | `data:execute`                     | Direct Brand, web, people, company, news, Parse, and utility calls.                   |
| Monitors        | `monitors:read` / `monitors:write` | Read / Manage configurations, runs, changes, limits, usage, and monitor webhooks.     |
| Batches         | `batches:read` / `batches:write`   | Read / Manage jobs, results, submissions, cancellation, deletion, and batch webhooks. |
| WebDBs          | `webdbs:read` / `webdbs:write`     | Read / Manage collections, rows, queries, syncs, previews, and webhooks.              |

**Manage includes Read** for the same group. Permissions apply to every resource in the organization; they do not isolate individual monitors or jobs. Full access includes future API groups, while restricted keys receive only their explicit grants.

For example, grant `data:execute` to an application that calls Answers or scrapes pages, `monitors:read` to a monitor-results viewer, or `batches:write` to a batch worker. Managed monitors and batches can run their workloads without `data:execute`; that scope controls direct data calls. Both direct calls and managed workloads can consume credits.

## Create or edit a key

1. Open the API keys page in the dashboard and create a key or open an existing key's action menu.
2. Choose Full access or Restricted, then select the required groups and Read/Manage levels.
3. Save the key in your server's secret store and use it as a bearer token.
4. Use the API reference for the operation's request and response contract. The dashboard selects compatible keys for supported requests and code samples.

Changes apply to subsequent requests. Requests already accepted, submitted batches, and scheduled monitors continue; cancel or pause those resources separately when you need their work to stop.

## Read versus Manage

Reads include configuration/history/results, POST collection queries, and POST webhook-delivery searches. Mutations, explicit runs, previews, delivery retries, and webhook-secret rotation require Manage for the relevant source.

Shared delivery endpoints check the source resource's monitor or batch permission. Read access omits monitor and WebDB webhook signing secrets. Use an authorized Manage key when configuring or rotating a custom receiver's secret.

## Diagnose denied requests

A missing grant returns `403 INSUFFICIENT_PERMISSIONS`, with `required_permission` when the required scope can be identified. Denial occurs before billing or work execution. Grant only the permission the integration needs, then retry; repeated unchanged requests will keep failing.

Dashboard roles and API-key permissions are independent. An authorized teammate can manage shared keys even when a particular key is restricted. See [Team access](/guides/manage-team-access) for the Owner/Admin/Member model. Key permissions are not spending caps.

## Inspect usage and retire keys

Search keys by name and filter active or disabled keys. A key's usage link opens its last 30 days of credit usage; the usage page keeps the selected key in its URL and filters charts and request logs together. For API-based investigations, use [Request Logs](/api-reference/logs/list) with `key_id` and a key that has `logs:read`.

For rotation, create a replacement, update the application's secret, verify the integration, then disable the old key. Disable or delete retired credentials using their action menu. When offboarding a teammate, rotate shared keys they may have copied; changing their dashboard role or access does not erase an existing copy.