Manage API keys

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

Create and manage API keys in the 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 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 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.