Track vendor deprecations by giving each integration an owner who reads the vendor's changelog, by watching for Sunset headers in responses, and by recording the API version and any known end date in your inventory. Then schedule the migration before the date, not after the first failure.
Why this belongs in the inventory
An old API version is not only a reliability problem. OWASP notes that running multiple versions expands the attack surface and that a lack of retirement strategy leads to running unpatched systems. That advice is aimed at API providers, but as a consumer you face the mirror image: a vendor retires a version, and your service either breaks or keeps calling a version that no longer gets fixes.
What the Sunset header tells you
RFC 8594 defines a Sunset response header that lets a server say a resource is expected to become unresponsive at a specific time. The value is a single HTTP date, for example Sat, 31 Dec 2018 23:59:59 GMT. The RFC says clients should treat the timestamp as a hint, not a guarantee, and that after the time arrives you may see client errors, redirects, or no response at all.
Not every vendor sends it. Treat the header as a bonus signal on top of reading notices.
Steps
- Add two columns. API version in use, and known end date (blank if none).
- Name a reader. One person per vendor subscribes to the changelog, status page or email list for the API you use.
- Log the header. Add a small piece of client middleware that records any Sunset header it sees, with the host and path, and sends it to your logs or metrics.
- Alert on a window. For example, flag any integration with an end date inside 180 days and open a ticket for the owner.
- Plan the migration. Estimate the work, check whether the new version changes data sent or scopes needed, and update the inventory row when done.
- Remove the old version fully. Delete old client code and unused credentials once traffic stops.
Questions to ask for each migration
| Question | Why |
|---|---|
| Does the new version need new scopes or send more fields? | A data flow change may need a privacy review |
| Can both versions run side by side during rollout? | Reduces risk |
| Do webhooks change shape? | Inbound endpoints may need updates |
| Is the SDK version tied to the API version? | The SDK upgrade may carry its own changes |
Unknown end dates
If a vendor gives no dates, record that fact. Review those integrations more often, since you have less warning. Also note any vendor whose SDK has not shipped a release in a long time, which is a signal worth a conversation with the owner.
Quick check
Does every API send a Sunset header?
No. Many do not. Combine it with changelog reading and owner reminders.
Is the Sunset time exact?
RFC 8594 says clients should treat it as a hint. Plan to finish early.
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
- OWASP API Security Top 10 2023, API9 Improper Inventory Management
- RFC 8594, The Sunset HTTP Header Field
Last reviewed: 19 October 2026.
