# HOST151: Cache shared replay

## What this means[​](#what-this-means "What this meansへの直接リンク")

A cache in front of the store is replaying one person's API responses to everyone.

A caching layer is serving stored REST API responses without checking who is asking: the app sent two differently-authenticated probes and received the first probe's answer both times. On a live store this means one cashier could see another's data, so connecting is blocked until the cache excludes the store's API. This is a hosting-layer problem — WordPress itself always answers per-user.

## What to do[​](#what-to-do "What to doへの直接リンク")

Export diagnostics and contact support. Retry after making the change above; retrying without it will fail the same way.

## Your data[​](#your-data "Your dataへの直接リンク")

Data on this device may be at risk — do not clear local data. If this persists, export diagnostics and contact WCPOS support.

## Troubleshoot[​](#troubleshoot "Troubleshootへの直接リンク")

1. Exclude the store's REST API paths (/wp-json/ and /?rest\_route=) from page caching — on LiteSpeed disable REST caching or add a no-cache rule; on WP Engine extend the WooCommerce exclusion to /wp-json/wcpos; on Sucuri set the caching level to honor Cache-Control.
2. The store's API already sends Cache-Control: no-store and Vary: Authorization — the cache layer is ignoring them; point the host at those headers.
3. After changing cache settings, purge the cache before reconnecting.

## Where to look[​](#where-to-look "Where to lookへの直接リンク")

When WCPOS can save this error, it is recorded on the device that raised it. Open **Store health → Logs** (the heart-pulse icon at the bottom of the navigation drawer), find the entry marked with this code and expand it: the expanded row shows the plain-language reason and the context captured at the moment of failure. For a store request, that context may include the server’s own error code (`serverCode`), the HTTP `status` or the `endpoint`; the fields shown depend on where the failure occurred. When reporting a problem, use **Copy debug info** at the top of the Logs screen (**Share debug info** on phones and tablets) rather than screenshots: it bundles the app version, connection state and the most recent errors. Logs are kept for at most 30 days, so collect them while the problem is fresh. Also copy any browser-console error that appeared before the POS was able to write its own log entry.

## Details[​](#details "Detailsへの直接リンク")

* **Code:** `HOST151` (`CACHE_SHARED_REPLAY`)
* **Severity:** error
* **Introduced in:** WCPOS 1.10.0