Manage the Website Response Cache

TMXIO places an NGINX response cache in front of every hosted dynamic Website runtime. WordPress and generic PHP use FastCGI caching; Node.js uses proxy caching. Static HTML is already served directly by NGINX and therefore has no separate response-cache screen.

The response cache stores public, cache-eligible responses. Authenticated requests, private or no-store responses, unsafe methods, and application bypass signals are sent to the Website origin.

Open the cache screen

1. Open a hosted Website.
2. Select the Website Environment you want to manage.
3. Open Cache in the Website navigation.

WordPress and generic PHP environments show cache outcomes, policy, rules, diagnostics, and invalidation history. Node.js environments show the durable cache invalidation controls. The selected Environment is always the boundary; changing or clearing one Environment does not affect another.

Clear cached responses

In Clear response cache, choose the narrowest selector that covers the change:

• Entire Website removes every response object for the selected Environment.
• Exact URL removes every cached variant of one canonical URL while leaving neighbouring URLs intact.
• Path prefix removes the selected path and every cached path beneath it.

Submit the request and keep the returned operation in view until it reports Succeeded. A queued operation confirms acceptance, not physical removal. Failed operations remain visible for diagnosis and do not report success.

After a successful invalidation, the next cache-eligible request reaches the Website origin and repopulates the object. Clearing the response cache does not flush Redis object data or purge unrelated Website Environments.

Purge from a PHP or Node.js application

An owner or administrator can create a cache invalidation credential for a dynamic Website Environment. Store the credential as an application secret and send it as a bearer token to the environment-scoped invalidation endpoint:

curl -fsS -X POST \
  "$TMXIO_API_URL/api/v1/sites/$SITE_SLUG/environments/$ENVIRONMENT_ID/cache_invalidations" \
  -H "Authorization: Bearer $TMXIO_CACHE_INVALIDATION_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"scope":"path","path":"/catalog/item-42/","idempotency_key":"catalog-item-42-v7"}'

Use scope=site for the entire Environment or scope=prefix with a canonical path for a subtree. Use a stable, unique idempotency_key when retrying the same application event so a network retry replays the existing operation instead of starting another purge.

Rotate the credential if it is exposed. Application credentials are scoped to one Environment and cannot invalidate another Environment’s cache.

Verify the result

Request the changed public URL without authentication. The first eligible request after invalidation should reach the origin; a later request may be served from cache. Confirm the new content is present and the operation history shows Succeeded.

If the response remains stale, check whether Cloudflare or an application-level cache also stores the page. These layers are separate from the TMXIO response cache and require their own invalidation.