On this page
Two gaps, two questions
| Gap | The question it leaves open | What goes wrong |
|---|---|---|
| No consumer team on record (orphan) | Whom do we tell when this endpoint changes? | A breaking change ships and the team that calls it hears from its users first |
| No owner | Whom do we ask about this endpoint? | Questions, incidents and retirement decisions have nobody to go to |
The two are independent. An endpoint can have an owner and no known consumers, which is the common case for a new endpoint. It can have five consumer teams and no owner, which is common after a reorganisation. Both are worth a look; they need different fixes.
Two meanings of “orphan”
In API security writing, “orphaned”, “zombie” and “shadow” APIs are endpoints that stay reachable while nobody maintains or owns them, and tools find them from traffic: Cloudflare API Shield labels a saved endpoint with no traffic for 32 days cf-risk-zombie. This guide, and Graphwake, use the word for a gap in the record: an endpoint in the spec with no consumer team. An orphan in this sense may be called all day by a team that never said so.
Why it matters
- Changes reach nobody. When an endpoint with no recorded consumers changes, the producer has no one to warn. Either nobody calls it, or someone does and will find out in production.
- Retirement stalls. Without a consumer list nobody can say whether the endpoint is safe to remove, so it stays forever. See how to deprecate an endpoint safely.
- Ownership decays quietly. Teams split, merge and rename. An owner field that pointed at a team that no longer exists is worse than an empty one, because it looks filled.
- Security inventory. The OWASP API Security Top 10 lists improper inventory management (API9:2023): hosts without a clear purpose, no retirement plan, missing or outdated documentation. An endpoint nobody owns is part of that problem.
How to find them from your specs
Your OpenAPI specs list every endpoint that exists. Start there, not from traffic, so the list is complete on one side. With a JSON spec and jq, list each operation as a method and a path:
jq -r '.paths | to_entries[] | .key as $p | .value | keys[]
| select(test("^(get|put|post|delete|patch|head|options|trace)$"))
| "\(ascii_upcase) \($p)"' openapi.json | sort > endpoints.txtThen compare it with whatever records consumers today: a sheet, a wiki page, catalog entries. Here it is a two-column file, METHOD /path,team. The lines that only appear in the spec are your orphans:
cut -d, -f1 consumers.csv | sort -u | comm -23 endpoints.txt -GET /orders/{id}/invoiceDo the same with an owners list to find endpoints without an owner. If owners are set per service, an endpoint without its own owner inherits the service’s; only an endpoint whose service has no owner either is truly unowned.
What to do with each orphan
An orphan is a question, not a verdict. Look at the endpoint’s traffic, then pick one of three answers:
| What you see | What it means | What to do |
|---|---|---|
| Calls from a caller you can name | A consumer that never put itself on record | Ask that team to add itself; how to find which teams use an endpoint covers the search |
| No calls over a full business cycle | Probably unused | Confirm with the owner, then retire it with notice |
| A new endpoint, not released to callers yet | Nobody is meant to call it yet | Leave it, and look again after the first consumer ships |
For an endpoint with no owner, the fix is a decision, not a search: whoever owns the service, or the team that changes the code most often, takes it. Write it down even if it is a guess you will correct.
A weekly routine
Get the list on Monday
Orphan endpoints, endpoints without an owner and services without an owner, sent to the people who can assign owners. Short lists get read; cap each one.
Triage the new lines
Each new orphan gets one of the three answers above. Each unowned service or endpoint gets an owner, or a name and a date for the decision.
Ask, do not chase
Send one message per likely consumer team, naming the endpoint and the evidence. A team that says “not ours” is an answer too.
Watch the count, not the list
The number should fall and then stay low. A sudden rise usually means a new service came in with no consumers mapped yet.
How Graphwake reports orphans
In Graphwake an orphan endpoint is a live endpoint that no consumer team subscribes to. Graphwake reads every endpoint from your OpenAPI specs and the subscriptions teams make, so the comparison above runs on its own and the weekly list arrives without anyone building it.
Weekly ownership report
Every Monday from 08:00 UTC, admins get one email listing orphan endpoints, endpoints without an owner and services without an owner, up to 50 lines each. A week with nothing to report sends nothing. Admins can turn it off.
Optional ownership with inheritance
A service may have an owner team, and an endpoint may have its own. An endpoint without one inherits the service’s owner, so only real gaps show up.
Orphans on the map
The service graph flags each orphan endpoint next to its owner, and the overview counts them. A breaking change on an orphan counts toward the impact score as a blind spot.
Discovery suggests the likely teams
When an orphan is new or changes in a breaking way, Discovery suggests teams from rules such as subscriptions to neighbouring endpoints and shared schemas. Someone confirms before a team subscribes.
For how a team-level map of consumers and owners is built and kept, read API dependency map. For what the consumer list is used for when an endpoint changes, read API breaking change alerts.
When a traffic tool or catalog alone is enough
- You need to know whether an endpoint is called at all. Gateway analytics, access logs or a traffic-based inventory such as Cloudflare API Shield answer that.
- You are hunting endpoints that are live but missing from any spec. API discovery tools that compare traffic with your specs find these “shadow” endpoints.
- You want one owner field for every service, library and database. A software catalog like Backstage covers far more than APIs.
Questions
What is an orphaned API endpoint?
A live endpoint that no team has said it depends on, so a change to it warns nobody. In security writing the word also means an endpoint nobody maintains that is still reachable, usually found from traffic.
Is an orphaned endpoint the same as an unused one?
No. An orphan has no consumer on record; it may still be called by a team that never said so. Check its traffic before you decide it is unused.
How do I find endpoints without an owner?
List every endpoint from your OpenAPI specs and compare it with your owners list. If owners are set per service, an endpoint inherits its service’s owner, so only endpoints of unowned services, without an owner of their own, are gaps.
Should I delete orphaned endpoints?
Only after the traffic shows nobody calls them over a full business cycle and the owner agrees. Otherwise find the caller and put it on record.
Pick an endpoint. See who it reaches. 7-day free trial. Cancel before day 7 and you pay nothing.
Start free trialSources and last verified
- developers.cloudflare.com/changelog/post/2025-11-25-zombie-endpoint-risk-label/
- api-security.owasp.org/editions/2023/en/0xa9-improper-inventory-management
- salt.security/blog/zombie-apis-the-undead-threat-to-your-security
- docs.wallarm.com/api-discovery/rogue-api/
- backstage.io/docs/features/software-catalog/descriptor-format/
Sources checked on 2026-11-09.