Inventory inbound webhooks by listing every URL on your side that a vendor calls: the path, the vendor that sends to it, the team that owns it, how you verify the sender, and what the endpoint can change. These endpoints are integrations too, and they are public by design.
Why webhooks get missed
Most inventories start from outbound calls, because that is what code search and egress logs show. A webhook runs the other way. The vendor calls you, so nothing appears in your egress logs, and the code is often a small route handler that looks like any other endpoint.
OWASP's inventory guidance asks for API hosts to be documented with their environment, who should have network access and the version, and it warns about unnecessarily exposed hosts. A webhook receiver with a public URL fits that description exactly, so it deserves a row.
Where to find them
| Source | What to look for |
|---|---|
| Router and framework route files | Paths with names such as webhook, callback, hook, notify or events |
| API gateway or load balancer config | Public routes that skip your normal login |
| Vendor dashboards | Configured webhook destinations on your accounts |
| Access logs | Inbound requests from vendor address ranges or with vendor user agents |
| Infrastructure code | Routes and rules created for a specific vendor |
The vendor dashboard check matters because it finds URLs registered months ago for features that have since changed.
What to record per endpoint
- Public path and host. Include environment, since staging endpoints are often registered with the vendor too.
- Sender. Vendor and the account used.
- Owner. Team and a named person.
- Verification method. Signature header, shared secret, mutual TLS or source address allowlist. Record which one, and where the secret lives.
- What it can do. Read only, update records, trigger payments, send messages.
- Replay handling. Whether the handler rejects an old or repeated delivery.
- Failure behavior. What happens if your endpoint is down and the vendor retries.
- Last delivery seen. A date that tells you whether it is still live.
Close the gaps you find
An endpoint with no verification is the first fix. An endpoint with no deliveries in months is a candidate for removal: ask the owner, remove the registration at the vendor, then remove the route. Do both ends, or the vendor will keep trying a URL that no longer exists.
Also check that the webhook sender account is one you recognize. A destination registered under a former employee's login is a common orphan.
Link it to the outbound side
Many vendors use both directions: you call their API and they call you back. Link the two rows so a change to one prompts a review of the other.
Quick check
Do webhooks show up in an SBOM?
No. An SBOM lists components. A route handler is your own code, so discover it through route files, gateway config and vendor dashboards.
What is the first fix for an unverified webhook?
Add sender verification, using the method the vendor documents, and reject unverified requests.
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.
