An endpoint your code defines and an endpoint your traffic hits are two different facts. The gap between them is where shadow APIs and untested risk live.
Most API security tools answer one of two questions: what does the code expose, or what does traffic reveal. Answer only the first and you miss the shadow endpoint no source you scanned ever declared. Answer only the second and you miss the route that exists in code but no one has exercised yet. The useful answer is the correlation of both.
apPosture labels every endpoint by provenance. Code + Runtime means the SAST attack-map found it and DAST confirmed it answers at runtime - the highest-confidence surface you have. From source means it is declared but not yet observed live. Runtime-only is the one that should make you sit up: live traffic hits a route no scanned code declared - a shadow API, the classic source of an unmonitored breach.
That provenance is not a label for its own sake. It drives prioritisation: a public, sensitive, not-provably-authenticated endpoint is one toxic combination, not three separate facts to triage. It feeds contract-as-truth: attach the declared OpenAPI spec and the diff against what is actually running surfaces documented, shadow, declared-untested and auth-drift endpoints. And it stays out of the request path - we ingest the access logs your gateway already produces rather than inserting an inline proxy, because this is posture management, not a WAF.
The result is one hero risk score on the same A-F curve as the rest of your posture, with the endpoints that are reachable, sensitive and exposed surfaced first - and the shadow APIs you did not know you were running named explicitly.