# Datadog API key vs application key
Two keys, two jobs. Agents confuse them constantly because both are long hex strings and the error for using the wrong one is just 403.
## Which is which
- **API key**: belongs to the organization, not a person. The agent uses it to submit metrics, events, logs, traces. Create and rotate it under Organization Settings, API Keys. If this leaks, rotate it: agents everywhere will need the new one, so plan that.
- **Application key**: belongs to a user, inherits that users permissions by default. Used together with an API key for programmatic API access (curl, Terraform provider, scripts). Some API endpoints need extra scopes granted on the app key before they work, see Actions API access in the docs.
## The mapping agents get wrong
| Task | Key needed |
|---|---|
| Install/configure the agent | API key only |
| DogStatsD, APM, log intake via agent | API key only (on the agent) |
| curl to the API, Terraform provider, custom scripts | API key AND application key |
| RUM browser SDK | client token, neither key |
## Symptoms of mixing them up
- Agent install with an application key pasted as the API key: agent starts, intake returns 403, nothing appears. The fix is replacing it with a real API key.
- API call with only an API key and no app key: 401/403 on most endpoints. Add the `DD-APPLICATION-KEY` header.
- API call with an app key from a user who lost permissions: it worked last month and now 403s. Check the key owners role.
## Hygiene
- One-Time Read mode exists for viewing a key value a single time. Use it, then store the key in a secret manager, not in a repo or chat.
- Name keys by purpose (terraform-prod, ci-read) so rotation does not become archaeology.
- Application keys die with offboarding: if the user who created it is deactivated, integrations using it break. Prefer keys owned by a service account user for automation.