Third-Party Service and API Key Discovery

Establish the live position before planning change

When you take over a legacy web application, the codebase itself is only part of what you are assuming responsibility for. Most business systems rely on external services: payment processors, email delivery providers, cloud storage, mapping tools, authentication platforms, CRM connectors and dozens of smaller utilities. Each of these connections is controlled by an API key, a secret token or a set of credentials that grants access to a paid or free third-party account.

Third-party service and API key discovery is the process of finding every external dependency, establishing who controls the underlying accounts, and confirming that those credentials will remain available, transferable or replaceable after the handover. It is not a security audit, though it overlaps with security concerns. It is an operational inventory: without it, you risk losing access to services the application depends on, or discovering unexpected costs tied to accounts nobody has reviewed in years.

The core problem is that credentials are rarely stored in one place. They appear in environment variables, configuration files, hardcoded in source code, saved in deployment scripts, stored in secret-management tools, or even recorded in old emails and shared documents. A thorough discovery exercise looks across all of these locations and cross-references what it finds against the actual behaviour of the application.

Why Discovery Matters Before Handover

An incomplete inventory creates several concrete risks. A service might be billed to a personal account belonging to a departing developer, meaning invoices stop being paid or the new team has no administrative access. A key might be tied to a free tier with hard usage limits that the business has never tested against. A credential might have been rotated on the provider side without the application being updated, meaning a failure is already latent. In some cases, the original account holder may have left the organisation and the provider has no process for transferring ownership without their involvement.

Discovery also reveals the true operational surface area of the system. A business might believe it is taking over a single application, only to find it is connected to four separate SaaS platforms, two payment gateways and an email service, each with its own billing cycle, support channel and terms of service. Understanding this before the handover allows you to negotiate scope, cost and responsibility accurately.

Where to Look for API Keys and Service References

A structured discovery process works through the application in layers, starting with the most obvious locations and moving towards the less visible ones.

• Configuration files: Settings files, .env files, JSON or YAML configuration, and XML files often contain keys in plain text or lightly encoded formats.
• Environment variables: Server-level or container-level environment variables may hold credentials that never appear in the repository.
• Source code: Search for patterns such as "api_key", "secret", "token", "auth", "password" and provider-specific terms like "stripe", "sendgrid" or "aws". Keys are sometimes hardcoded, particularly in older codebases.
• Dependency manifests: Package managers and build files reveal which libraries are in use. Some libraries require their own keys or connect to external services by default.
• Deployment scripts and infrastructure-as-code: CI/CD configurations, Terraform files, cloud formation templates and server provisioning scripts may inject credentials at build or deploy time.
• Secret-management tools: If the previous team used a vault or secrets manager, access to that tool is itself a critical dependency.
• Documentation and communications: Wikis, shared drives, project-management boards and email threads sometimes contain credentials that were never moved into a proper configuration system.

Mapping Services to Business Functions

Finding a key is only the first step. You then need to understand what the key does and whether the business still needs that function. Group discovered services into categories that reflect their operational role:

• Transactional services: Payment processing, subscription billing, invoice generation. These directly affect revenue and require immediate continuity planning.
• Communication services: Email delivery, SMS gateways, push-notification providers. Failure here affects customer experience and operational alerts.
• Data services: Cloud storage, database hosting, caching layers, search engines. These underpin the application's core data model.
• Integration services: Connections to accounting software, CRM platforms, HR systems or logistics providers. These affect cross-departmental workflows.
• Operational services: Error tracking, performance monitoring, logging, uptime checking. Losing these reduces visibility but does not usually break functionality.
• Utility services: Geocoding, image processing, PDF generation, date handling. Often low-risk but can cause subtle failures if removed.

For each service, record the provider name, the purpose it serves, the account identifier where visible, the billing contact if known, and whether the key appears to be in active use or is potentially legacy code that is no longer called.

Verifying Active Usage

Not every key you find is actively used. Legacy applications accumulate technical debt, and old integrations may have been replaced without the original credentials being removed. Where possible, verify usage by checking application logs for recent calls to the service, reviewing code paths that reference the key, or temporarily monitoring network traffic in a staging environment. If you cannot verify usage safely, flag the key as unconfirmed rather than assuming it is active or inactive.

Common Mistakes

The most frequent error is treating discovery as a one-time search of the codebase. Keys migrate over time. A developer might move a credential from a config file into a secrets manager, but forget to remove the original copy. The old key might still work, creating a false sense of security if you only find one of the two copies. Another common mistake is assuming that because a key works today, the account it connects to is properly owned and billed. A key can remain valid on a lapsed personal account for months before the provider suspends it.

Failing to distinguish between keys and the accounts behind them causes significant problems. You might gain access to a key that allows API calls, but have no administrative access to the account itself. This means you cannot view invoices, change billing details, rotate the key or add team members. When the original account holder leaves, you may face a protracted recovery process with the provider.

Overlooking non-API dependencies is another gap. Some services connect through webhooks rather than API calls, meaning there is no key in your codebase to find. Instead, the external service sends data to a URL on your server. If that URL changes during a migration and you have not updated the webhook configuration on the provider side, the integration silently breaks.

Limitations of the Discovery Process

Discovery has inherent boundaries. You can only find what is accessible to you. If the previous supplier or team retains control of infrastructure, secrets managers or private repositories, you are relying on their cooperation to produce a complete list. Contracts and access agreements should address this explicitly before the handover begins.

Encoded or obfuscated credentials present another limitation. Some applications encode keys using base64 or custom schemes that are not immediately recognisable as credentials. Without running the application and observing its behaviour, these can be difficult to identify from static analysis alone.

Discovery also cannot tell you whether a service is compliant with your business's current data-protection, privacy or regulatory requirements. A legacy integration might send customer data to a provider whose terms no longer meet your obligations. That is a separate assessment, but discovery should flag every external data flow so that assessment can happen.

Key Checks Before Completing Handover

• Account ownership: For every active service, confirm who owns the provider account, whether it is a business or personal account, and whether administrative access can be transferred.
• Billing responsibility: Verify who receives invoices, what the current spend is, and whether any services are on expiring trials or promotional pricing.
• Key rotation: Determine when each key was last rotated and whether the provider has a rotation policy. Plan to rotate keys as part of the handover rather than continuing to use credentials that may have been shared beyond the current team.
• Scope and permissions: Check whether each key has the minimum permissions required for its function. Legacy keys sometimes have broader access than necessary, particularly if they were created for initial setup and never restricted.
• Redundancy: Identify any services that have no fallback. If a single email provider handles all transactional and operational messages, what happens if that service has an outage?
• Contractual terms: Review whether any service agreements have auto-renewal clauses, minimum commitment periods, or data-retention policies that affect your exit options later.
• Webhook configurations: List any services that send data to your application via webhooks and confirm the target URLs will remain correct after any infrastructure changes.

Keep the decision traceable

Third-party service and API key discovery is not a technical luxury. It is a basic safeguard that prevents operational surprises after a legacy system changes hands. The practical outcome should be a documented register of every external dependency, the status of its account and credentials, and a clear plan for maintaining or replacing each one going forward. Without that register, you are accepting unknown cost, unknown risk and unknown control gaps as part of the handover.