Operations

Caching & conditional requests

GET responses are cached for speed; writes invalidate the affected resource. ETags let you make efficient conditional requests.

What is cached

Only GET requests are cached. Writes are never cached.
Sensitive endpoints are never cached - authentication, orders, users, and checkout always return fresh data.
After a write, the affected resource's cache is invalidated, so the next read reflects your change.

ETags & conditional GET

Cacheable responses include an ETag. Send it back with If-None-Match to get a 304 Not Modified (and no body) when nothing changed:

curl -s "https://api.readycms.io/products/?namespace=<tenant>" \
  -H "Authorization: Bearer <app_id>:<app_secret>" \
  -H "If-None-Match: \"<etag-from-previous-response>\""

Tip

Store the ETag from each response and replay it with If-None-Match. A 304 saves bandwidth and is faster than re-downloading unchanged data.

Bypassing the cache

You may see a ?nocache=1 parameter. It is honored only in non-production/debug contexts and is stripped in production - do not rely on it to force-fresh reads in live traffic. Instead, rely on write-invalidation: after your write completes, the next read is fresh.

Note

If a read looks stale right after a write, capture the request_id of both calls before reporting it - that lets us trace the exact invalidation path.