> [Agent navigation index](/llms.txt)

# Cache invalidation

Invalidate cached data after changes and preserve the boundaries between browser, server, Contentful, and edge caches.

## Invalidate after changes

Mutations do not invalidate automatically:

```ts
await updateProductClient
  .execute(updateProductApiContract, { body: input, params: { productId } })
  .unwrap();
await dataCache.invalidate(getProductApiContract);

```

Contract invalidation covers every URL, origin, and private partition for that method/path in the namespace. Use tags for narrower application groups:

```ts
const summer = dataCache.public({ ttl: "5m", tags: ["catalog:summer"] });
await dataCache.invalidate("catalog:summer");

```

Awaiting invalidation confirms storage invalidation, not observer refresh completion. Active local `useApi` observers refresh in the background and retain old data while fetching. Observers exist only in the same `createDataCache` coordinator; there is no cross-tab or cross-replica notification.

Invalidation is eventual, and in-flight work may repopulate shared storage. Within one `createDataCache` coordinator, a local generation prevents new callers from joining pre-invalidation work and prevents that work from publishing to local observers. There is no such promise across coordinators or replicas. The stale fallback recheck is likewise best-effort and eventual.

## Boundaries to preserve

- Browser, server, Contentful delivery, and edge caches are separate scopes.
- A Contentful webhook invalidates registered server delivery clients only.
- Invalidation is not CDN propagation, authorization, or a browser purge.
- There is no polling, focus/reconnect refetch, cross-tab broadcast, distributed load lease, or detached stale-while-revalidate.
- Identities are hashed, but bodies are not encrypted by Brix. Use store encryption and access controls.

See [API routes](/docs/api-routes), [Contentful](/docs/contentful), and [server setup](/docs/server) for each integration.