Public APIs
All posts

API Caching: What 87 Public APIs Actually Send

Quick answer: API caching means storing a response so you do not fetch it again: in the client, at a gateway or CDN, or on the server. Whether a client may cache is decided by HTTP headers. We read them on 87 live public APIs: 31% send no caching headers at all, and only 37% answer a conditional re-request with a 304.

Every caching guide explains Cache-Control and ETags from first principles. None of them tell you what the APIs you are about to call actually send, which is the only thing your client can act on.

So we measured it. We run a directory of public APIs, and 240 of the 1,578 live APIs we list (15.2%) are both keyless and CORS-enabled. On 6 October 2026 we called 102 endpoints from that corpus, recorded every caching header on the 87 that answered, then repeated each request with If-None-Match or If-Modified-Since to see whether the server would return 304 Not Modified.

What do public APIs actually send?

| What the response said about caching | APIs | Share | |---|---|---| | Nothing at all: no Cache-Control, ETag, Last-Modified or Expires | 27 | 31% | | A freshness lifetime (max-age above zero) | 31 | 36% | | Revalidate every time (no-cache or max-age=0) | 16 | 18% | | A validator but no Cache-Control | 7 | 8% | | private, public or stale-while-revalidate with no lifetime | 5 | 6% | | no-store (never cache) | 1 | 1% |

Almost a third of public APIs give you no caching signal whatsoever. Open-Meteo, Nominatim, Radio Browser, Bible-api and SEC EDGAR all answered without a single cache header. Your HTTP client will treat that as "heuristically cacheable" at best and uncacheable in practice, so the decision is entirely yours.

Only one API forbids caching outright. JokeAPI sends no-cache, no-store, must-revalidate, which is honest: every call is meant to return a different joke.

How long do APIs say you can cache?

For the 31 APIs that set a lifetime, the median max-age was one hour. The spread is enormous:

| Freshness lifetime | APIs | Example | |---|---|---| | Under a minute to 1 minute | 5 | 4chan boards: 5 seconds | | 5 to 15 minutes | 8 | Open Brewery DB: 300 seconds | | 1 to 4 hours | 5 | REST Countries: 4 hours | | About a day | 5 | Frankfurter: 86,400 seconds | | Two days or more | 8 | Rick and Morty: 90 days, immutable |

The extremes are deliberate. HTTP Cat tells clients to keep its images for ten years, which is right for a picture that will never change. 4chan's five seconds is right for a board list that moves constantly. Both are telling you something true about their data, and your cache should obey.

Five APIs added stale-while-revalidate, which lets a client serve the cached copy instantly while it refreshes in the background. Coinpaprika sends the full modern set: max-age=60, s-maxage=60, stale-while-revalidate=10, stale-if-error=600. If the API goes down, you may keep showing ten-minute-old prices rather than an error.

Do conditional requests actually work?

This is the cheapest form of API caching there is. You keep the response with its ETag or Last-Modified value, and next time you send that value back. If nothing changed, the server replies 304 Not Modified with an empty body.

42 of the 87 APIs (48%) sent a validator: 33 an ETag (22 of them weak, prefixed W/), 12 a Last-Modified date, 3 both. When we sent the validator back:

  • 32 returned 304. Revalidation works as specified.
  • 5 returned a full 200 with a new ETag, because the content genuinely changed. RandomDog and What The Commit return something different on every call, so that is correct.
  • 5 returned a full 200 with the same ETag. The server computes a validator, sends it, and then ignores it when you send it back. VATComply, Quran Cloud and mail.tm behaved this way.

So the honest number is 32 of 87, or 37%: barely a third of public APIs will save you a download when the data has not changed.

What are the three places you can cache an API?

Client-side caching

Your app keeps responses in memory, on disk, or in the browser's HTTP cache. Browsers do this automatically when headers allow it. Server-side code, scripts and most HTTP libraries do not, so you add it yourself. This is the layer you control when calling someone else's API, and it is where the measurements above matter.

Gateway and CDN caching

A shared cache sits in front of the API and answers repeat requests without reaching the origin. 49 of our 87 APIs sat behind Cloudflare, but 27 of those responses came back marked DYNAMIC, meaning the edge was not caching them at all. A CDN in front of an API is not the same as a cached API. s-maxage, which only shared caches obey, appeared on just 5 responses.

Server-side caching

The API caches its own expensive work, such as database queries or computed results, in Redis, Memcached or memory. Clients never see this layer directly. It shows up as faster responses, not as headers.

How should you cache an API that sends no headers?

Most of the time you are on your own, so set a policy per endpoint:

  1. Decide the lifetime from the data, not the API. Exchange rates from Frankfurter change daily. A country list changes yearly. A weather forecast changes hourly. Pick a TTL that matches how often the truth changes.
  2. Store the validators even when there is no Cache-Control. Seven APIs sent an ETag or Last-Modified with no lifetime. Postcodes.io and Disney both returned 304 when asked. Revalidating costs one round trip and no body.
  3. Respect Vary. 18 APIs varied on Origin, so a shared cache must key responses by origin or it will serve one site's CORS headers to another.
  4. Cache errors briefly, or not at all. 15 of our 102 calls failed. A 503 cached for a day is an outage you built yourself.
  5. Cache to stay under the limit. The best reason to cache a free API is that you stop spending its rate limit on data you already have. Our guide to API rate limiting covers what happens when you do not.

What should an API you build send?

If you publish an API, the survey is a list of what to avoid. Send a Cache-Control header on every response, even if it is no-store. Send a strong ETag and honour If-None-Match, because five APIs in our sample did the expensive half of that work and threw away the benefit. Add stale-while-revalidate and stale-if-error if a slightly old answer beats no answer. And pair caching with sane collection design: an endpoint that returns 61,000 records in one response, as we found when we measured pagination, is exactly the response you most want clients to cache.

Frequently asked questions

What are the three types of cache?

For APIs, the three layers are client-side caching (in the app or browser that calls the API), shared caching (a gateway, reverse proxy or CDN between client and server), and server-side caching (the API caching its own database queries or computations). Each layer saves a different cost: the client saves network trips, the shared cache saves origin load, and the server saves compute.

Can an API gateway do caching?

Yes. Most gateways, including AWS API Gateway, Kong and Cloudflare, can cache responses and serve repeat requests without reaching your backend. They follow s-maxage and Cache-Control if you configure them to, and you choose the cache key. Make sure the key includes any header listed in Vary, such as Origin or Authorization.

How do I clear an API cache?

On the client, delete the stored entry or send the request with Cache-Control: no-cache to force revalidation. On a CDN or gateway, use its purge API, by URL or by tag. If you control the API, short lifetimes plus ETags avoid most purging, because clients revalidate cheaply rather than holding stale data.

What is the difference between no-cache and no-store?

no-cache allows storing the response but requires revalidating it with the server before each reuse, which is where ETags and 304s come in. no-store forbids storing it at all. In our sample, 16 APIs asked for revalidation every time, and only one, JokeAPI, used no-store.

Should I cache responses from free public APIs?

Almost always. Caching cuts your latency, protects you from the API's rate limits, and keeps your app working through short outages. Browse the keyless APIs in our development category or open data category and check each one's headers before choosing a lifetime.