---
title: "Comment by Ahmet Özel on \"Third-Party API Deprecations: Catch Them Before Prod\" | Hashnode"
description: "The once-per-host-and-path-per-day key reduces noise, but it can also hide a more urgent notice received later that day. Two explicitly pinned API versions may"
url: "https://hashnode.com/posts/third-party-api-deprecations-catch-them-before-prod/6aef1c75fbc11263e07871b4/comment/6aefedbd79d2cc6736b2bf6c"
---

[Discussion](https://hashnode.com/posts/third-party-api-deprecations-catch-them-before-prod/6aef1c75fbc11263e07871b4)

Comment [Third-Party API Deprecations: Catch Them Before Prod](https://hashnode.com/posts/third-party-api-deprecations-catch-them-before-prod/6aef1c75fbc11263e07871b4)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[4d ago](https://hashnode.com/posts/third-party-api-deprecations-catch-them-before-prod/6aef1c75fbc11263e07871b4/comment/6aefedbd79d2cc6736b2bf6c)

The once-per-host-and-path-per-day key reduces noise, but it can also hide a more urgent notice received later that day. Two explicitly pinned API versions may share a path while returning different Sunset dates; the first response wins the cache key even if the second version is retiring sooner.

I would include the configured API version and a fingerprint of the deprecation metadata in deduplication, then aggregate repeated events for alerting. A fixture with the same path and two different Sunset headers would check that both migration obligations reach the dependency register without logging every successful request.

[Muhammad Ali Mughal](https://hashnode.com/@ali978123)

[4d ago](https://hashnode.com/posts/third-party-api-deprecations-catch-them-before-prod/6aef1c75fbc11263e07871b4/comment/6aefedbd79d2cc6736b2bf6c#reply-6aeff44ded2d82a0b04d7580)

Thanks Ahmet — that's a real hole in the snippet. Cache::add keyed only on host + path + date means the first response of the day wins, so a later call on the same path with an earlier Sunset (or a second pinned version that shares the path) never gets logged.

I'd tighten the key the way you suggest: include the configured API version and a hash of the Deprecation, Sunset, and Link values. Each distinct notice still logs once; identical repeats stay quiet. A small aggregator can then roll those distinct keys up for the owner instead of one line per request.

A fixture that hits the same path twice with two different Sunset dates is exactly the right regression: both obligations should reach the register, and matching headers should still dedupe.

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[3d ago](https://hashnode.com/posts/third-party-api-deprecations-catch-them-before-prod/6aef1c75fbc11263e07871b4/comment/6aefedbd79d2cc6736b2bf6c#reply-6af154e73097fe7d1baf91cd)

For the Link contribution to that hash, I would select the deprecation and sunset relations rather than hash the entire header verbatim. An integration can also return pagination links or other changing relations; those would create distinct keys even when the migration notice is unchanged.

The event can still retain the complete raw header for inspection. A fixture with identical deprecation metadata but two different pagination cursors would check that operational request variation does not defeat the deduplication you just added.