Cache-Control

Caching IANA permanent response reached by regulation 3 spellings

Cache-Control is the instruction set for every cache between you and the caller. It is thoroughly specified, decades old, and largely unused by API providers — 109 providers in the catalog declare it, against tens of thousands that return cacheable data and say nothing about it.

Saying nothing is not neutral. A response with no cache directives is subject to heuristic caching, and an intermediary is entitled to make its own decisions about how long to keep it. When the payload contains protected health information or financial data, that is the gap the HIPAA Security Rule and the GLBA Safeguards Rule are pointed at — not because either names this header, but because “don’t leave PHI in a shared cache” has to be expressed somewhere, and this is where.

The registry

Listed in the IANA HTTP Field Name Registry as a permanent entry. Defined in RFC 9111, Section 5.2: HTTP Caching.

In the catalog

Declared by 109 providers across 3,568 published specification files in the API Evangelist catalog, where it appears as a response header — sent by the server.

It is spelled 3 different ways across those contracts — Cache-Control, cache-control, CACHE-CONTROL. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Reached by regulation

No law names this header. It is evidentiary — the deployed control for an obligation that regulation does impose. It is observable at the edge: an unauthenticated request is enough to see whether a provider sends it.

Using it

no-store on anything carrying personal, health or financial data — and no-store, not no-cache, which means “revalidate before use” and still permits storage. For genuinely public reference data, set a real max-age; an API that refuses to be cached at all is an API paying for every repeated call.