To find every third-party API your services call, combine three views: what the code says it calls (hostnames, SDK imports, config), what the network shows it calls (egress, DNS and proxy logs), and what teams say they use. Each view misses things the others catch, so you need all three.
Why one method is never enough
Code search finds integrations that are written down. It misses calls built from a hostname stored in a database, a feature flag or an environment variable. Network logs find what actually runs, but they only show a destination, not which team or feature depends on it. Interviews give the business reason, but people forget the small integrations added two years ago.
OWASP puts the problem plainly in its API Security Top 10: organizations need visibility of how their APIs share data with external third parties, and a missing inventory of those flows is a weakness. The inventory is where the three views meet.
The three views compared
| View | What it finds | What it misses |
|---|---|---|
| Code and config search | SDK imports, hardcoded hostnames, config keys | Hostnames built at runtime, calls from scripts outside the repo |
| Outbound traffic logs | Real destinations, call volume, last seen | Which team owns it, why it exists |
| Team interviews and billing records | Business purpose, paid services | Free tiers, forgotten trials |
Steps
- Search the code. Look for import statements of vendor SDKs, URLs starting with https in source and config files, and environment variable names that end in URL, HOST or ENDPOINT. Record each hostname you find.
- Pull outbound destinations. Take a 30 day sample from your egress proxy, NAT gateway logs or DNS resolver logs. Group by registrable domain and drop your own domains and cloud provider control planes.
- Reconcile the two lists. A host in the logs but not in the code is a lead. So is a host in the code with no traffic: it may be dead, or it may only run once a quarter.
- Ask each product team to review their rows. Send a short list per team and ask three questions: is this still used, who owns it, and what data goes to it.
- Record one row per integration. Keep it light at first: hostname, vendor, owning team, purpose, data sent, and the date you last confirmed it.
- Schedule the repeat. The first pass is the hardest. A recurring check against egress logs keeps it honest.
Common traps
Do not stop at the SDK list. Plenty of integrations are a plain HTTP call with no library at all, so a dependency manifest will never show them. Do not treat a CDN or a font host as harmless without looking: browser-side calls belong in the inventory too, even though they come from a page rather than a service.
Also watch for non-production traffic. Staging services often call real vendor accounts with real data.
Try it yourself
Open the demo below and look at how a dependency inventory lists packages and where they come from. Note which entries you would also need to record by hand because they never appear in a manifest.
Click through it at your own pace, or open it full screen.
Quick check
Is a dependency scan enough to find third-party APIs?
No. It finds libraries that wrap APIs. Direct HTTP calls, browser scripts and no-code connectors need code search, traffic logs or interviews.
How much traffic history do I need?
Thirty days is a practical start. Add a longer window for integrations that run monthly or quarterly, such as billing exports.
Who should hold the final list?
One named person or team, with each row owned by the product team that uses the integration.
Safeguard's SBOM and dependency scanning and asset discovery can supply the code-side list, and you can run a free scan at gold.safeguard.sh/scan. Network and team knowledge still have to come from your own logs and people.
Sources
Last reviewed: 19 October 2026.
