# Can I cache Croct content API responses to cut request volume?

Asked by dom_shaw on 2025-10-02. Tags: performance, api, caching.

The marketplace I work on has hot category pages that get hammered, and I am looking at
putting a cache in front of the content fetches for them, same as we do for
every other upstream. But the responses are personalized per visitor, so I am
not sure what is actually safe to cache without serving someone content that
was resolved for a different audience.

Is there a sanctioned caching story here? What is safely cacheable and what
absolutely is not

## 2 answers

### Answer from Ewa Lis (2025-10-02)

The dividing line is whether the response depends on the visitor.

Personalized responses are per-user by definition, that is the whole point of
the resolution. Putting a shared cache in front of them defeats it: the first
visitor's resolved content gets replayed to everyone behind them, and your
experiences and experiments silently stop doing anything for the cached
share of traffic. So the rule is simple, keep shared caching for content that
is identical for everyone and let personalized slots resolve per request.
The per-request path is cheap enough that this is not the hardship it sounds
like.

For the content that genuinely does not depend on the visitor, the content
service exposes a static-content endpoint. That is the sanctioned cacheable
path: same payload for every requester, so a shared cache in front of it is
correct by construction. Splitting your fetches along that line, static
endpoint behind cache for the shared parts, per-request resolution for the
personalized slots, gets you most of the request-volume win without breaking
anything.

### Answer from Theo Marchand (2025-10-03)

One tool that helps you audit the boundary: the response metadata tells you
what you actually got. `contentSource` comes back as `"slot"`, `"experience"`,
or `"experiment"` along with the matching experience, experiment, and variant
IDs. If you log that per route, you can see empirically which routes only
ever return plain slot content (candidates for the static path) and which
ones return experience or experiment resolutions (must stay per-request).
Much safer than deciding from the CMS side what you believe is personalized.