API Keys and Access: An Integration Security Checklist
By CodexierPublished 5 min read
Every integration between your systems holds a key: an API key, an OAuth token or a service account password. Together they often have more access than any single employee, and far less oversight. A leaked key to your accounting system or CRM is a data breach waiting to happen. This checklist covers how to inventory your connections, limit what each can do, store keys safely, rotate them and remove access when people or suppliers leave.
Inventory of connections and keys
You cannot protect what you do not know exists. Start by listing every connection: webshop to Fortnox, form to CRM, Zapier flows, AI tools with access to your inbox, suppliers with API access to your systems. For each, note the system, the type of credential, its permissions, where it is stored, who created it and when it was last rotated.
Least privilege per integration
Many systems offer scopes or roles for API access. Use them. An integration that only creates invoices should not be able to read salary data. An integration that reads orders should not be able to delete customers. If a system only offers all-or-nothing keys, that is a risk to note and a question to ask the vendor.
| Practice | Why it matters |
|---|---|
| One key per integration | You can revoke one without breaking the others, and logs show which integration did what |
| Narrowest scopes available | A leaked key can do less damage |
| Service accounts, not personal logins | Access does not depend on one employee, and survives their leaving |
| Read-only where possible | Many reporting and sync jobs never need to write |
| IP restrictions where supported | A stolen key cannot be used from anywhere |
Storing keys safely
The most common leaks are mundane: a key pasted into a chat, committed to a code repository, sent by email to a freelancer or stored in a shared spreadsheet. Keys belong in a secret manager, in the hosting platform's environment variables or in the automation platform's encrypted connection settings. Share access to the key through a password manager with audit logs, never by copying the value.
- Never commit keys to Git, even in private repositories; use secret scanning to catch mistakes.
- Never put keys in front-end code or mobile apps, where anyone can read them.
- Use separate keys for test and production.
- Store the keys suppliers need in a shared vault you control, not in their systems only.
Rotation and offboarding
Keys should change on a schedule and whenever the risk changes. When an employee, consultant or supplier with access leaves, every key they could have seen should be rotated, and every OAuth connection they authorised should be moved to a service account. This is where most small companies are exposed: the old web agency still has admin access, and a former employee's token still runs the invoice sync.
Scheduled rotation
Rotate long-lived keys at least yearly, more often for sensitive systems. Put the dates in the inventory.
Event-driven rotation
Rotate immediately on staff or supplier changes, or if a key may have been exposed.
Offboarding checklist
Add integrations and API access to the checklist used when people leave, next to email and laptop.
Logging and alerts
Logging tells you what an integration did, and alerts tell you when it did something unusual. Turn on API access logs where systems provide them. Watch for spikes in volume, access from new locations, failed authentication and exports of large data sets. If a key is misused, those logs are also what you need to assess whether a personal data breach must be reported to IMY within 72 hours.
We apply this checklist in every integration review we do. When you do not need us: if you have two or three integrations and one person in control of them, working through this list yourself is realistic. If you have inherited a tangle of connections from former staff or suppliers, book a free call and we will help you map them. Our APIs explained for business owners is a good primer.
Frequently asked questions
What is the difference between an API key and an OAuth token?
An API key is a static secret that grants access until revoked. An OAuth token is issued after a user or service account authorises access, usually with scopes and an expiry, and can be refreshed. OAuth is generally safer because access is limited and traceable.
How often should we rotate API keys?
At least once a year for long-lived keys, more often for systems holding sensitive data, and immediately when someone with access leaves or a key may have leaked.
Is it safe to give our agency or freelancer API access?
Yes, if they get their own key with limited scopes, it is stored in a vault you control, and it is revoked when the work ends. Avoid sharing your own admin login.
What do we do if a key has leaked?
Revoke it immediately, issue a new one, check logs for misuse, and assess whether personal data was accessed. If so, the GDPR breach rules may require notifying IMY within 72 hours.
Not sure who has access to what?
List the systems you connect. In fifteen minutes we will help you spot the riskiest keys and where to start.
Book a free 15-minute call