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

Նույնականացում

Ուղարկեք API բանալին որպես bearer թոքեն։ Այս վերջնակետը բնութագրում չի նշում որոշակի թույլտվության մասին, ուստի տվեք ձեր բանալուն նվազագույն անհրաժեշտը և ենթադրություններ անելու փոխարեն ստուգեք պատասխանը:

Այս վերջնակետը կազմակերպության ID չի ընդունում: Ձեր բանալին արդեն իսկ նույնականացնում է այն կազմակերպությունը, որին պատկանում է, և պատասխանը սահմանափակված է դրանով:

Փորձել

Փոխարինեք անկյունային փակագծերում գտնվող ցանկացած բան ձեր սեփական արժեքներով, և բանալու տեղապահը՝ ձեր վահանակի բանալիով:

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

Մուտք գործե՞լ եք: Ձեր վահանակի API վահանակը լրացնում է ձեր իրական կազմակերպության ID-ն և ձեր սեփական բանալին և գործարկում է հարցումը ուղիղ API-ի դեմ, որպեսզի կարողանաք տեսնել փաստացի պատասխանը: Բացեք այս վերջնակետը API վահանակում

Մանրամասներ

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. `404` for a site with no vendor hosting package, or one that is not the caller's; `422` when the package type does not permit a purge.

Պարամետրեր

Հարցման մարմին

Այս վերջնակետի կողմից վերադարձվող սխալները

401 · 403 · 404 · 422 · 429 · 503