Keep API keys safe by storing them in a password or secrets manager, giving each integration its own keys with only the access it needs, setting an expiry, and revoking them the moment one is exposed or someone who had access leaves. Treat them like passwords to your finance systems, because anyone holding one can use it. No genuine supplier will ask you to send one.
In this article
The short version
- Treat API keys like passwords: anyone holding one can use it.
- Store them in a password or secrets manager, never in email, chat, spreadsheets or code.
- Give each integration its own credentials with only the access it needs and a set expiry.
- Rotate or revoke keys when someone who handled them leaves.
- If one leaks, revoke it, replace it, check the request logs and remove the exposed copy.
Why API keys need the same care as passwords
More finance tools now let you create API keys so your own systems can connect to them: a billing system that sends invoices across, a data warehouse that reads payments, a script a contractor built, or an AI agent you've set up to work with your data. Often it's someone in finance or operations, not a developer, who ends up creating and holding them.
API keys work as bearer credentials. Whoever presents one gets the access it carries, with no second check and no login screen. The UK's National Cyber Security Centre describes them in these terms and warns that they often come with broad access and no expiry, so the limits you set when creating them make a real difference.
The good news is that most of the protection comes from habits, not technology. You don't need to understand the code to run the checklist below.
The checklist
Start with where the secrets live:
- Store each one in a password manager or secrets manager the moment you create it, or have your developer put it in an encrypted environment variable on the server that uses it.
- Keep them out of email, chat messages, shared documents, spreadsheets and support tickets. Each of those keeps copies you can't fully delete.
- Keep them out of code and code repositories. The NCSC advises separating secret credentials from source code, and automated tools scan public repositories for them.
- Use them only on servers. A secret placed in a website, mobile app or customer device can be read by anyone who looks.
Then limit what each one can do:
- Create one set of credentials per integration, named after the system that uses it, so you can revoke one without breaking the others.
- Give each only the permissions that system needs. If it only reads invoices, don't give it write access to customers. The NCSC lists least privilege as a core principle for API access.
- Choose the shortest expiry that's practical, and a short one for tests and contractor projects.
Keep a short list of who can see and manage them:
- Limit who can create and manage API keys to a small number of admins.
- Keep a simple register: the name, which system uses it, who owns it, its permissions and when it expires. Leave the secret itself out.
- Put renewals in someone's calendar, so an expiry doesn't take an integration down on a busy Friday.
Plan for people leaving:
- When a member of staff or contractor who handled keys leaves, rotate or revoke the credentials they could see, and update the system that uses them.
- Remove their access to the finance tool and to any password manager vault holding secrets.
Finally, tell your team that no genuine supplier will ask for your API keys by email, phone or chat, and that any such request should be treated as attempted fraud, however convincing it looks.
What to do if a key leaks
If a secret ends up somewhere it shouldn't, such as a forwarded email, a screenshot, a public code repository or a ticket, assume someone else has it.
- Revoke it straight away in the finance tool. Revoking stops it at once. Rotating can leave the old secret working for a while, which isn't what you want here.
- Create a replacement with the same permissions and update the system that uses it.
- Check the tool's request logs for anything you don't recognise, such as unfamiliar IP addresses or records created at odd times.
- Remove the secret from wherever it was exposed, including email threads, chat history and repository history.
- Contact the supplier's support team if you find suspicious activity, describing what happened without sending the secret.
The NCSC also recommends that credential use forms part of your monitoring, so a regular look at request logs is worth building into your month-end routine.
How this works in Adfin
Adfin's API keys follow this checklist by design. Admins create them in the console under Settings, then Developers, then API keys. Each one has a name, permissions set per resource (None, Read or Write) and an expiry of 90 days, 180 days or 12 months. Permissions can't be widened afterwards, and the secret is shown once.
Adfin emails you 30, 7 and 1 day before expiry and adds a dashboard task. Credentials unused for 60 days trigger a warning, and after 90 days unused they're revoked automatically. Rotation gives you a new secret with the same permissions while the old one works for 24 hours, and revocation is immediate and can't be undone. The request logs show each call's path, status, credential, client IP and duration.
Adfin never asks for your API keys, and keeping them safe stays your responsibility, as it would with any supplier. The same habits apply to keys for your bank, payroll and accounting tools.
Related guides
- How to spot and prevent invoice fraud
- Is it safe to let AI email your clients?
- Chasing invoices from a custom or in-house billing system
- Taking payments in the UK: a complete guide
Common questions
Where should a small business store API keys? In a password manager or secrets manager, or in an encrypted environment variable on the server that uses them. Not in email, chat or spreadsheets.
Should every integration have its own API key? Yes. One per integration, with only the access it needs, means you can revoke one without affecting the others.
How often should API keys be changed? Set an expiry when you create them and renew before it runs out. Change them straight away if one is exposed or someone who handled it leaves.
What should I do if I've emailed an API key by mistake? Revoke it, create a replacement, update the system that uses it, delete the email and check the request logs for anything unexpected.
Will Adfin ever ask for my API key? No. Adfin never asks for your API keys, so treat any request for one as suspicious.
What happens to my keys when an admin leaves? They keep working until revoked or expired, so rotate or revoke any the person could see and remove their access to the console.
Sources
- National Cyber Security Centre - Securing HTTP-based APIs: API authentication and authorisation (accurate as of November 2026) https://www.ncsc.gov.uk/collection/securing-http-based-apis/2-api-authentication-and-authorisation
- National Cyber Security Centre - Protect your code repository (accurate as of November 2026) https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository
- National Cyber Security Centre - Phishing attacks: defending your organisation (accurate as of November 2026) https://www.ncsc.gov.uk/guidance/phishing
- Adfin Developer Portal - API keys integration (accurate as of November 2026) https://developer.adfin.com/products/direct-integration/guides/get-started/api-keys
