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

Xaqiijinta aqoonsiga

U dir fure API ahaan calaamad muujisa (bearer token). Barta dhammaadka ee kani ma caysino luqad ahaan oggolaansho gaar ah oo ku dhex jirta qeexidda, markaa sii furahaaga inta ugu yar ee uu u baahan yahay oo fiiri jawaabta halka aad wax ka qaadan lahayd.

Boggan ma qaato aqoonsiga ururka. Furahaagu wuxuu horay u aqoonsanayaa ururka uu ka tirsan yahay, jawaabtuna waxay ku kooban tahay halkaas.

Isku day

Ku beddel wax kasta oo ku dhex jira qeebaha xaglaha ah qiimayaashaada, sidoo kalena haystaaha furaha ku beddel fure ka dhex muuqda dashboordigaaga.

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

Ma sign-garaysay? Qalabka API ee ku jira dashboard-kaagu wuxuu buuxiyaa aqoonsigaaga ururka ee dhabta ah iyo furahaaga gaarka ah, wuxuuna ku shaqeysiiyaa codsiga API-ga nool si aad u aragto jawaabta dhabta ah. Kani ka fur barta kontoroolka ee API

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. `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.

Cabiraha

Codsiga jidhkiisa

Cilladaha ay bartaani soo celin karto

401 · 403 · 404 · 422 · 429 · 503