How do you find who still calls a deprecated API before removing it?

Log every call to the deprecated endpoint with the caller, client version and credential, then group the results to see who is left. Warn them with Deprecation and Sunset headers and direct contact, and remove the endpoint only when the remaining traffic is explained or blocked on purpose.

Why this step gets skipped

Teams announce a deprecation date and then switch the endpoint off when the date arrives. Two things go wrong. A partner you forgot about breaks in production. Or the date slips for ever, because nobody knows who is still calling, and the insecure endpoint stays up.

OWASP's API Security Top 10 puts this under improper inventory management. It says running multiple versions of an API needs extra management and widens the attack surface, and lists as a blind spot any API with no retirement plan for each version. Attackers often get in through old versions that remain unpatched.

What to record

Do not log tokens or request bodies that contain personal data. Log identifiers that let you contact the owner.

Steps

1. Add the logging first, before you announce anything, so you know the baseline.
2. Group callers by credential and app version. A short list of named partners is easy to handle. A long tail of old app versions needs a different plan.
3. Send the signal in the response. RFC 9745 defines a Deprecation header that conveys the date a resource was or will be deprecated, and a deprecation link relation that can point to a page describing the policy. RFC 8594 defines the Sunset header, which tells clients when the resource is expected to become unresponsive.
4. Contact owners directly. Headers are read by software, and many integrations have no one watching logs.
5. Track the count down over time. A weekly chart of remaining callers by credential is enough.
6. Throttle or add friction as the date nears: lower rate limits, warning responses, or a brownout where the endpoint fails for a short period on purpose.
7. Remove it on the sunset date, or extend with a reason recorded for each caller still active.

RFC 8594 describes two stages: first the API is no longer preferred but still works, and second it is decommissioned. The Sunset header fits the second stage, which is when the endpoint becomes unresponsive.

Mobile clients are the long tail

Old app versions cannot be updated by you. Pair the API notice with a minimum supported version check, and an in app update prompt. Decide what happens to the oldest versions: a forced update screen, or loss of the feature. Keep the insecure endpoint only as long as the number of affected users justifies the risk.

What to do with callers that never move

Record the decision. Either block them with a clear error that links to migration steps, or keep the endpoint behind tighter limits for a stated period, with an owner and an end date. Silence is the worst option, since the endpoint stays live and no one owns it.

Safeguard's asset discovery helps you find API hosts and versions you may have lost track of, which is the starting point for any retirement plan. You can try the demo below and run a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how findings are grouped by endpoint, and think about which of your own endpoints would appear for an old version.

Quick check

Sources

• OWASP API Security Top 10 2023, API9 Improper Inventory Management
• RFC 9745, The Deprecation HTTP Response Header Field
• RFC 8594, The Sunset HTTP Header Field

Last reviewed: 19 October 2026.