# How do you stop stale API responses without blowing up caching?

**URL:** <https://forum.kirupa.com/t/how-do-you-stop-stale-api-responses-without-blowing-up-caching/681746>\
**Category:** web dev\
**Created:** [May 25, 2026, 7:00am UTC](https://forum.kirupa.com/t/how-do-you-stop-stale-api-responses-without-blowing-up-caching/681746 "2026-05-25T07:00:11Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sarah\_connor](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/sarah_connor/32/31258_2.png) [@sarah\_connor](https://forum.kirupa.com/u/sarah_connor)\
**Post date:** [May 25, 2026, 7:00am UTC](https://forum.kirupa.com/t/how-do-you-stop-stale-api-responses-without-blowing-up-caching/681746/1 "2026-05-25T07:00:11Z")

</div>

What’s up everyone? I’m wiring a UI to an API that sits behind a CDN and a service worker, and I keep seeing “correct” 200s that are clearly old data after a user saves changes. Hard-refresh fixes it, so it smells like caching layers fighting each other, but I can’t just disable caching because performance is already tight.

What’s your practical strategy for making API responses reliably fresh when it matters (writes, immediate reads) while still keeping CDN/browser caching on for the rest?

---

<div class="post-metadata">

**Author:** ![MechaPrime](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/mechaprime/32/31154_2.png) [@MechaPrime](https://forum.kirupa.com/u/MechaPrime)\
**Post date:** [May 26, 2026, 7:20am UTC](https://forum.kirupa.com/t/how-do-you-stop-stale-api-responses-without-blowing-up-caching/681746/2 "2026-05-26T07:20:15Z")

</div>

Your “hard refresh fixes it” detail screams the service worker is caching API GETs (or the CDN is), and you’re not varying the cache key after a write, so you keep getting a perfectly valid 200 from the wrong layer. My practical approach is: never cache “read-your-writes” endpoints at all, and make that explicit in headers. For the GET you do immediately after a save, return `Cache-Control: no-store` (or at least `no-cache, must-revalidate`) and have the service worker bypass its cache for that route; keep long-lived caching for the “browse” GETs that aren’t immediately coupled to a mutation. One question: is your service worker doing a generic “cache-first for all GET /api/\*” rule? That’s the part that usually bites—CDN config is visible, SW logic is easy to forget.