hosting

POST /v1/sites/{siteId}/cache/purge

Clear a site's server-side cache.

All hosting endpoints

All developer docs →

Authentication

Send an API key as a bearer token. The key must carry the sites.cache.purge permission; a key without it is refused with 403, not 404.

This endpoint takes no organisation id. Your key already identifies the organisation it belongs to, and the response is scoped to it.

Try it

Replace anything in angle brackets with your own values, and the key placeholder with a key from your dashboard.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/cache/purge \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{  }'

Signed in? The API console in your dashboard fills in your real organisation id and your own key, and runs the request against the live API so you can see the actual response. Open this endpoint in the API console

Details

Drops what the hosting platform has cached for the site — everything, or one path. 202 and no body rather than 200: the platform acknowledges the purge and the edge drops the object afterwards, so claiming "done" would be a promise about a moment we never observed. The client re-reads the cache resource, whose cacheability report is stale the instant a purge lands. ⛔ Gated on sites.cache.purge, which this platform already minted for exactly this, and deliberately not on sites.panel_access: clearing a cache destroys nothing, "my change isn't showing" is the most common thing a customer or a support agent needs to do, and softer is correct here. sites.view is required alongside it, as everywhere on this surface. On our own fleet it clears, in order, the site's object cache (Redis, by the site's key prefix), its LiteSpeed page cache and its CDN zone. ⭐ Both server caches are cleared WITHOUT loading WordPress, so the purge works on a site whose plugins crash — the site a customer is most likely to be rescuing. The page cache is purged at the server by this site's own LiteSpeed Cache tag (never the whole server's cache); the plugin's own purge also runs when the site loads. A purge that cleared nothing (the page cache exists and neither path reached it) is a 422, never a 202. 404 for a site that is not on our own fleet, or one that is not the caller's; 422 when the purge could not be completed.

Parameters

NameTypeRequiredWhat it is
siteId (path)UuidYesSite ID (UUIDv7).

Request body

NameTypeRequiredWhat it is
pathstringNoOne path to drop, relative to the site root. Omit it, or send "", to clear the whole cache.

Errors this endpoint can return

401 · 403 · 404 · 422 · 429 · 503