API key
An API key is the credential a program uses to call an email API. It identifies the account, carries a set of permissions, and travels in an authorization header rather than in the URL. A key is a secret: keep it in your server's environment, never in client code or a repository, and revoke it the moment you suspect it has leaked.
At a glance
- Category
- Authentication
- Travels in
- An Authorization header, as a bearer token
- Stored as
- A hash — the plaintext is shown once, at creation
- Scopes
- Full access, or sending only, optionally locked to one domain
- Revoking
- Immediate, and independent of every other key
How it works
A key is minted once, displayed once, and stored only as a hash, so nobody — including the service that issued it — can read the original back out later. Your code keeps it in an environment variable and sends it on every request in an authorization header, normally as a bearer token. The server hashes what arrives, looks for a record with the same hash, and reads the account and the permissions attached to it. Nothing else in the request identifies you, which is why the header is the whole of the security model.
Why it matters
A key is the entirety of your authority over an account, so its blast radius is whatever it is allowed to do. A key scoped to sending only cannot read your contacts or delete a domain, and one locked to a single domain cannot send as another, which turns a leak from a crisis into a chore. Rotation is cheap when every service holds its own key and expensive when twenty of them share one, because then every rotation is a coordinated deploy rather than a single setting.
Example
A production service reads its key from an environment variable at start-up and never writes it to a log. Staging holds a different key, scoped to sending only and locked to the staging domain, so a loop in a test job cannot reach real customers. When a contractor's service is retired, the one key it used is revoked on its own and everything else keeps running, because no two services were ever sharing a credential in the first place.
Common mistakes
- 01Committing a key to a repository, where it survives in the history long after the line is deleted.
- 02Putting a key in front-end code, where anyone who opens the network tab can read it and send as you.
- 03Giving every service the same key, so a single leak forces a rotation across the whole estate at once.
- 04Keeping a key nobody can name the owner of, which is exactly the key you will be afraid to revoke.
In Rasket
Keys start with rk_, are shown once and stored only as a hash, and each one is either full access or sending only, optionally locked to a single domain. Authentication
Related terms
Frequently asked questions
What should I do if a key leaks?
Revoke it first and investigate afterwards. A revoked key stops working immediately, so the cost of revoking one you did not need to is a deploy, while the cost of waiting is every message somebody else can send as you.
Can I get a key back after it is shown?
No. Only a hash is kept, so there is nothing to show you a second time. If a key is lost, create a new one, deploy it, and revoke the old one once nothing is using it.
How many keys should a team have?
One per service that sends, rather than one per person. That way a rotation touches exactly one deployment, and the audit trail says which system sent a message rather than which human owns the account.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.