An API key lets your own code call the SendOps API. It belongs to your organization, carries a fixed set of permissions you choose when you create it, and never expires on its own.

If you are automating **your own** organization — a nightly report, a contact sync, a deployment script — an API key is the simplest thing that works. If you are building a product that connects to **your customers'** SendOps organizations, you want an [OAuth client](/api-integrations/oauth-clients) instead.

API keys live under **Workspace → API Keys**. Only the **Owner** and **Org Admin** roles can see or manage them.



## Creating a key


<Step title="Open Workspace → API Keys">
  Select **Workspace** in the sidebar, then the **API Keys** tab.
</Step>
<Step title="Choose a name and environment">
  The name is for you — it appears in the key list and in the audit log, so make it say where the key is used ("nightly-report-job" beats "key 2").

  Pick **Live** or **Test**. Both read and write the same real data; the only difference is rate limit. Test keys run at 10% of your plan's per-minute ceiling, which makes them right for CI and smoke tests that would otherwise burn your live budget.
</Step>
<Step title="Select permissions">
  Choose the scopes the key needs. There is deliberately no "select all" — a key should carry the least it can.
</Step>
<Step title="Copy the key">
  The key is shown **once**. We store only a hash of it, so we cannot show it to you again. Put it straight into your secrets manager.
</Step>



  Anyone holding the raw key can call the API as your organization. Never commit one to version control. If a key leaks, revoke it immediately — see [Revoking a key](#revoking-a-key).


## What a key can do

A key's permissions are the scopes you selected, and nothing more. You can only grant scopes you yourself hold: an Org Admin cannot mint a key more powerful than an Org Admin.

Editing a key's scopes later takes effect immediately — there is no propagation delay and no need to reissue the key.

For the full scope catalogue and what each one unlocks, see the [Authentication reference](https://developers.sendops.dev/api-reference/authentication) on the developer docs.

## Rotating a key

Rotation issues a **new** secret while the old one keeps working for **24 hours**. That grace window is the point: you can deploy the new secret everywhere, confirm traffic has moved, and let the old one lapse without a moment of downtime.


  The name, scopes, and environment all carry over. Only the secret changes.


Rotate when someone with access leaves, when a key has been in place a long time, or the moment you suspect exposure. If you think a key is actively being abused, **revoke** it instead — rotation leaves the old secret valid for a day.

## Revoking a key

Revoking is immediate and permanent. The next request using that key gets `401 Unauthorized`. There is no undo and no grace period.

## Audit trail

Key creation, scope changes, rotation, and revocation are all recorded in the [Audit Log](/team/audit-log), with the acting user and the key's display prefix — the first characters after `sk_live_` / `sk_test_`. The prefix is stored in plain text precisely so a key can be identified in logs without exposing the secret.

## API keys vs. OAuth clients

| | API key | OAuth client |
|---|---|---|
| Acts as | Your organization | Your customer's organization, or your own |
| Set-up | Create a key, paste it | Register a client, implement a flow |
| Credential lifetime | Until you rotate or revoke | 15-minute access tokens |
| A user must approve | No | Yes, for the connect flow |
| Right for | Automating your own org | Building a product others connect |

API keys are **not** deprecated and are not going away. For most automation they remain the simpler choice. See [OAuth Clients](/api-integrations/oauth-clients) when you need a customer to grant your product access to *their* SendOps data.