Finding vendor connections in your dependency files

When an external API fails, the useful question is which operation in your product depends on it. A dependency file can give you a starting list of vendors to investigate. You still need to check where the code runs and what it calls.

An installed SDK is a candidate connection. It might serve a production request, run only in a background job, or be left over from an experiment. Record that distinction before deciding what deserves an alert.

Start with the packages you declare

Run this from a Node.js project's directory to list its direct production dependencies. It reads your local package.json; it does not install packages or contact any vendors.

node --input-type=module <<'NODE'
import { readFileSync } from 'node:fs';

const { dependencies = {} } = JSON.parse(
  readFileSync('package.json', 'utf8')
);
console.log(Object.keys(dependencies).sort().join('\n'));
NODE

This is an initial inventory, not a complete map. Review other workspace packages and deployment configuration too. Connections made with a generic HTTP client, infrastructure resources, and services called by another service may not have a recognizable SDK in this file. Development dependencies can also matter to your build and release process.

Follow each match to a real operation

Search for the package's imports and configuration. Check the environment in which the call runs, the endpoint it uses, and who owns that path. Use deployed configuration and request records to confirm an active connection.

The same SDK can support very different operations. These are illustrative review questions, not conclusions about your application:

A package name alone does not reveal the configured endpoint. An SDK may use a compatible API hosted elsewhere. Read the configuration before assigning a vendor.

Keep a short record your team can use

For each confirmed connection, write down the affected operation, environment, owner and evidence that it is active. Add the expected behavior if the request fails: an error shown to the user, delayed work, a tested fallback, or a loss of internal visibility.

Prioritize the operation's consequences. Email delivery might be optional for one feature and essential to another product's sign-in flow. A generic ranking of “critical vendors” misses that context.

Where the dependency matters, link to the relevant dashboard or runbook. Verify timeout and retry behavior in the actual integration. Retrying a state-changing request needs the provider's documented safeguards; a vendor incident alone is not an instruction to replay work.

Use the map during an investigation

Compare the vendor's affected product and region with your confirmed connections. Then inspect the outcome of the relevant application requests. A vendor report can explain a failure, but it cannot establish that your users experienced one.

In CheckUpstream, create an account, connect GitHub or GitLab, and choose a public or private repository. The scan finds dependency matches for you to check against your application's actual usage. The setup guide walks through that process.

Keep unverified matches separate from confirmed production connections. The guide to following a failure across vendors explains how to take that inventory into an incident investigation.

Updated September 11, 2026: removed unsupported dependency counts, blanket impact rankings and detection promises. The example now lists packages without treating installation as proof of production use.