Third-Party Services and API Keys List per App
How to keep a list of third-party services and API keys for each app and find which apps use a service when it reports a vulnerability.
Overview & context
A third-party services list for an app holds, for each service, its name, purpose and a link to where its secrets, such as an API key, are managed. This article describes what such a list should look like and how to use it in AboutTheApp.
1. Why keep a list of services and keys for each app
A list of services for an app answers two questions: what the app uses to run and what access it needs for that. Without such a list, you have to piece this together from several places, such as the repository, environment variables or hosting settings.
A list of service links comes in handy when a service reports a data breach, compromised keys or another vulnerability. You need to quickly find which apps use it, which keys are affected and who has access to them. Likewise, during an outage or even just a pricing change, you need to know which apps are affected.
2. What to record in a services list
For each service, record the name, what the app uses it for, the environments it runs in and a link to where the private data (keys, identifiers, hashes and so on) is stored. Private data doesn't belong in the list. Keep it in your platform's secret variables and a copy in a password manager, as described in the article on the .env file.
| Field | Example | What it's for |
|---|---|---|
| Service | Stripe | Searching by name after a breach or outage |
| Purpose | Checkout payments | Estimating the impact if the service goes down |
| Environments | Production and staging | Which keys to rotate, test or live |
| Link to key management | Service dashboard, API keys section | Where to replace the key |
| Owner | Who has access to the account | Who to contact after a breach |
3. How to keep a services list in AboutTheApp
In AboutTheApp, a service is a resource of the app that you put in a category by purpose: DevOps & Infrastructure, Monitoring & Quality, Security or Business & CRM. AboutTheApp doesn't store passwords or API keys, so a resource holds only the address of the key management page.
- 1
Open the app in the product editor
Click edit on the app's card and go to the Resources section.
- 2
Add a resource for the service
Click Add resource, pick a category and enter the service address, ideally the direct URL of the dashboard, a specific project or an account in the service. Add the service name, for example "Stripe".
- 3
Add a short description
Write the purpose and the environment in the description, for example "Payments, production". Resource search covers the address, name and description.
- 4
Set the visibility
Mark links to password managers as Private. They're shown only to signed-in team members and to people who enter the unlock code.
- 5
Separate the environments
If a customer or an environment has its own account with a service, attach the link directly to it. For the same service, you then see which account belongs to which installation.
4. How to find which apps use a service
Enter a service name or its domain in the dashboard search, and AboutTheApp lists all matching resources across your apps. It searches the address, name and description of a resource, ignores letter case and you only need to enter at least two characters.
Each result shows the product, customer and environment the resource belongs to, plus a Private badge on private links. A resource that applies to every customer is labeled All customers. At most 200 results are shown, so try to narrow the search. Search is available to all roles, including Reader.
When there's a problem with a service, you open the dashboard, enter its name and see right away which apps and environments need a new key, a version update or a disconnected service. Search is only as good as the list, so add a link for each new service as soon as you connect it.
Search finds only text in a resource's address, name or description. It won't match an abbreviation or a typo, so use the same official service name across all apps.
5. What to do when a service reports a breach
When a service reports a breach of data or keys, rotate the keys in every app that uses it and check that the apps work with the new key. It pays to have the procedure written down in advance and an owner assigned.
- 1
Find the affected apps
Search for the service on the dashboard to see all apps, customers and environments where it's used.
- 2
Generate a new key
Open the links you found, create a new key in the service dashboard and revoke the old one. Create a separate key per app and environment if needed.
- 3
Replace the key in the app
Store the new key in the secret variables of the platform where the app runs and a copy in your password manager. Then restart or redeploy the app.
- 4
Verify it works
After deployment, run a smoke test to confirm the service works with the new key.
- 5
Review access
Check who has access to the service account and remove access that isn't needed.
6. Services list vs. application inventory vs. licenses
A services list records what an app uses from outside. An application inventory lists the apps themselves, and third-party licenses describe the libraries the app is built from. You can keep all three for one app in AboutTheApp and keep them in one place.
Frequently asked questions
How do I keep a list of third-party services for an app?
For each app, record the service name, purpose, environments and a link to where the key is managed. The key itself doesn't belong in the list. In AboutTheApp, a service is a resource of the app with a category, name and description.
Where should I store API keys?
In the secret variables of the platform where the app runs, with a copy in a password manager. Don't put them in code, prompts, documentation or AboutTheApp. AboutTheApp keeps only a link to where the key is managed.
How do I find which apps use a given service?
If you keep a services list for each app, search for the service name. In AboutTheApp, the dashboard search covers the address, name and description of resources across all apps, customers and environments.
What should I do when a service announces a data breach?
Find which apps use the service, generate new keys, replace them in the secret variables and redeploy or restart the apps. Have the old key revoked and review access to the service accounts.
Is a private link in AboutTheApp safe for sensitive data?
No. A private link is hidden behind an unlock code, but it isn't a vault. It suits the address of a password manager, but not the passwords themselves.
Does resource search include private links?
Yes, signed-in team members, including the Reader role, see them. Private links are marked Private in the results.
In short
A services list with links to key management and search across apps saves the time and nerves of digging through repositories and various docs when a data breach or a service outage happens.
AboutTheAppWant to know which apps use which service?
Create your app in AboutTheApp for free, add its services and password managers and search them across your apps.