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

Tabbatar da Asali

Aiko da maɓallin API a matsayin bearer token. Wannan ma'anar ba ta bayyana takamaiman izini ba a cikin ƙayyadaddun bayanai, don haka ba wa maɓallin ku mafi ƙarancin abin da yake buƙata kuma ku bincika amsar maimakon yin zato.

Wannan wurin ƙarewa ba ya buƙatar ID na ƙungiya. Maɓallin ku ya riga ya gano ƙungiyar da yake ciki, kuma an iyakance amsa a kanta.

Gwada

May gurbin komai da ke cikin kusurwa da ƙimar ka, kuma may gurbin maballi da maballi daga allon sarrafa ka.

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

An shiga? Na'urar sarrafa API da ke cikin sashin kulawarka tana cika ainihin lambar ƙungiyarka da maɓallinka naka, sannan tana gudanar da buƙatar a kan ainihin API don haka zaka iya ganin amsar gaske. Buɗe wannan tashar a cikin na'urar kula da API

Bayani

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.

Sigogi

Jikin buƙata

Kuskuren da wannan matsaya za ta iya maido wa

401 · 403 · 404 · 422 · 429 · 503