Before a team adds a third-party API, the design review should ask what data leaves, how the call authenticates, what happens when the vendor is down, who owns it, and how to remove it. If those five answers are written in the inventory row, the integration is ready to ship.
Why ask early
An integration is cheapest to change before it is in production. Once customers depend on the feature, a question like "should we really send full profiles to this vendor?" turns into a migration project. A short review at design time costs minutes.
OWASP's description of the data flow blindspot is a useful framing: a sensitive data flow to a third party with no business justification or approval, no inventory, and no visibility of which data types are shared. The questions below close each of those gaps.
The ten questions
- What is the business purpose? One sentence, written down.
- What data goes out? List fields, not just "user data". Could any be dropped or masked?
- Is personal or regulated data included? If yes, route to privacy review before build, not after.
- How does the call authenticate? API key, OAuth or mutual TLS, and which scopes. Request the narrowest scopes the feature needs.
- Where is the credential stored and who rotates it? Name a person or team.
- Which environments will call it? Decide whether staging uses a sandbox account rather than the production one.
- What happens when the API is slow or down? Timeouts, retries, a fallback, and what the user sees.
- What does the API send back, and do we trust it? Treat responses as untrusted input and validate them before use.
- How do we find out about changes? Subscribe to the vendor's changelog or deprecation notices and name who reads them.
- How do we exit? If you had to disable or replace it in a week, what would break?
Turn answers into the row
Do not leave answers in meeting notes. The review is done when the inventory row exists and has an owner, a data classification and a last confirmed date. A merge check that blocks a new SDK import without a linked row makes this routine.
When to skip the full review
Low-risk cases, such as a public weather feed with no customer data and no credentials, can use a short form. Reserve the full ten for integrations that touch customer data, payments, source code or production credentials.
Try it yourself
The demo shows a pull request gate. Consider where a check for a linked inventory row would sit among the other rules.
Click through it at your own pace, or open it full screen.
Quick check
Who runs this review?
The product team leads it. Security and privacy join when personal data, payments or credentials are involved.
Is a sandbox account worth the effort?
Usually yes. It keeps real customer data out of non-production calls and limits damage from test mistakes.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
