Caching
How the API serves repeat reads, and what that means for freshness.
Read endpoints are cached for a short time, so the same request made twice in quick succession is served from cache instead of being recomputed. This keeps storefronts fast under load. The tradeoff is freshness: a change to your catalog can take up to 60 seconds to appear in the API.
Freshness
Responses are cached for up to 60 seconds. After you change your data, for example publishing a product or updating a price, allow up to a minute for that change to show up in GET responses. There is no way to force an earlier refresh from the API, so do not build flows that depend on a write being instantly readable.
Response headers
| Header | Description |
|---|---|
Cache-Control | private, max-age=60. Your client may reuse the response for up to 60 seconds without making a new request. private means only the client that made the request caches it. The response is scoped to your key and is never stored in a shared or CDN cache. |
X-Cache | HIT if the response was served from cache, MISS if it was freshly computed. Informational, for debugging only. Do not depend on it. |
The cache distinguishes requests by your Authorization key, your Accept-Language, and your X-Currency, so a request with a different key, language, or currency is always a separate cached response. The Vary header advertises this, so a standard HTTP client that caches on your behalf keeps each combination separate. Query parameters are part of the URL and are always distinguished automatically.
Best practices
- Expect up to 60 seconds of lag between a write and it appearing in a read.
- Let your HTTP client honor
Cache-Control. A browser does this automatically, so repeat views reuse the cached response with no extra request. - These headers are exposed for cross-origin reads, so storefront JavaScript can read them directly from the
fetchresponse.
See Rate Limits for the related per-IP request budget.