GET /v1/sites/deleted

تصدیق‌هویت

یو API کی د بیئرر ټوکن (bearer token) په توګه ولیکئ. کی باید د sites.view اجازه ولري؛ له دې اجازې پرته کی د 404 پرځای د 403 په واسطه رد کیږي.

دا پای نقطه د سازمان هېڅ آی ډي نه اخلي. ستاسو کیلي مخکې تر مخکې هغه سازمان په ګوته کوي چې پورې اړه لري، او ځواب ورته محدود دی.

هڅه وکړئ

د انګلیسي په زاوي پنسونو کې هرڅه د خپلو ارزښتونو سره بدل کړئ، او د کلي ځای لرونکی ستاسو د ډشبورډ د کلي سره.

curl -X GET https://api.zinndigital.com/v1/sites/deleted \
  -H "Authorization: Bearer zdk_live_…"

ننوتي یاست؟ ستاسو په ډشبورډ کې د API کنسول ستاسو د اصلي سازمان ID او ستاسو خپله کیلي ډکوي، او غوښتنه د ژوندی API په وړاندې پرمخ وړي ترڅو تاسو وکولی شئ اصلي ځواب وګورئ. دا پای ټکی (endpoint) د API په کنسول کې پرانیزئ

تفصیلات

Every site deleted from the principal's orgs, newest first, with **an unambiguous date for when its backup is purged and the site becomes permanently unrecoverable** (`purge_due_at`). ⛔ **`purge_due_at` is computed by the engine from the live retention policy and must never be recomputed by a client.** It comes from the same function the purge sweep selects on, so the date shown and the date acted on cannot drift. A client adding `deleted_at + 30` would be a second hardcoded number, and it would be wrong the moment an operator edits the policy (D-W15-10b). ⛔ **`restorable` is a measurement, not a status.** It reflects a real check that the backup object exists in storage, so it is `false` — with `reason_code: no_backup` — for a site whose backup row claims success over bytes that were never written. A restore button over a backup that does not exist is worse than no button. Requires `sites.view` only: knowing which of your own sites were deleted, and by when they become unrecoverable, is not a privileged fact.

پارامترونه

ځواب

تېروتنې چې دا پای ټکی یې بیرته راګرځولی شي

401 · 403 · 429