hosting
POST /v1/sites/{siteId}/backups/transfer-in
Move an externally hosted site onto Zinn® hosting from a backup we hold.
توثيقِ شناخت
ایک بیرر ٹوکن کے طور پر ایک API کی بھیجیں۔ کی کے پاس hosting.backup.manage اجازت ہونی چاہیے؛ اس کے بغیر کی کو 404 کے بجائے 403 کے ساتھ مسترد کر دیا جاتا ہے۔
یہ اینڈ پوائنٹ کوئی آرگنائزیشن آئی ڈی نہیں لیتا۔ آپ کی کلید پہلے ہی اس آرگنائزیشن کی شناخت کرتی ہے جس سے یہ تعلق رکھتی ہے، اور اس کا جواب اسی کے مطابق محدود ہوتا ہے۔
آزمائیں
کوئی بھی چیز جو زاویہ دار قوسین میں ہو اسے اپنی اقدار سے بدلیں، اور کلیدی پلیس ہولڈر کو اپنے ڈیش بورڈ کی کسی کلید سے بدلیں۔
curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/backups/transfer-in \
-H "Authorization: Bearer zdk_live_…" \
-H "Content-Type: application/json" \
-d '{ "backup_id": <Uuid>, "source_site_id": <Uuid> }'لاگ ان ہیں؟ آپ کے ڈیش بورڈ میں موجود API کنسول آپ کی حقیقی تنظیم کی آئی ڈی اور آپ کی اپنی کلید خود بخود پُر کر دیتا ہے، اور لائیو API پر درخواست چلاتا ہے تاکہ آپ اصل ردعمل دیکھ سکیں۔ اس اینڈ پوائنٹ کو API کنسول میں کھولیں
تفصیلات
⛔ **Destructive.** Restores a backup taken from a site hosted somewhere else onto `siteId`, overwriting that site's live database and files. This is what makes an external-site backup subscription a migration path: because we already hold the archive, moving onto our hosting is a restore rather than a migration. Both sites must belong to the same organisation, `source_site_id` must be a site we do **not** host, `siteId` must be an active site we do, and the backup must be a completed full backup. Anything else is 422. Requires `hosting.backup.manage` on the destination. ⭐ Nothing is sent to the origin host: it is not contacted, nothing there is deleted, and its backup connection keeps running. Disconnecting it is a separate, customer-initiated act, so the original stays a working fallback until the customer is happy with the copy.
پیرامیٹرز
| نام | قسم | لازمی | یہ کیا ہے |
|---|---|---|---|
siteId (path) | Uuid | ہاں | Site ID (UUIDv7). |
Idempotency-Key (header) | string | نہیں | Client-generated key that makes an unsafe request replay-safe: the server stores the first response and returns it verbatim for repeats. |
درخواست کا باڈی
| نام | قسم | لازمی | یہ کیا ہے |
|---|---|---|---|
backup_id | Uuid | ہاں | The backup to land on this site. It must belong to `source_site_id` and must have completed successfully. |
source_site_id | Uuid | ہاں | The externally hosted site the backup was taken from. Named explicitly rather than derived from `backup_id`, so a mistyped backup id cannot silently move a different site onto t… |
جواب
| نام | قسم | لازمی | یہ کیا ہے |
|---|---|---|---|
site_id | Uuid | ہاں | UUIDv7 identifier — sortable by creation time (docs/02 §8). |
backups | SiteBackup[] | ہاں | — |
can_backup | boolean | ہاں | False while a backup is in flight, when this site's hosting platform cannot take one at all, or when the site's on-demand allowance for the last 24 hours is spent. |
in_progress | boolean | ہاں | — |
on_demand_backups | boolean | ہاں | Always true. On-demand backups are included on every plan (owner ruling 2026-08-10); what bounds them is `on_demand_limit` per rolling 24 hours, not the plan. Retained for compa… |
unsupported_reason | string | نہیں | A stable machine identifier saying why this site's hosting platform cannot be backed up at all, or empty when it can. The client renders it as a localised sentence. Distinct fro… |
on_demand_limit | integer | ہاں | On-demand backups allowed per rolling 24 hours, per site. |
on_demand_used | integer | ہاں | On-demand backups taken in the last 24 hours. Failed attempts are not counted — the customer got nothing from them. |
on_demand_remaining | integer | ہاں | How many the customer may still take right now. |
on_demand_next_at | string | ہاں | When the next on-demand slot opens, as the oldest counted backup ages out of the rolling window. Null whenever `on_demand_remaining` is above zero. |
daily_backups | boolean | ہاں | The plan's `daily_backups` entitlement — whether the nightly sweep selects this site. |
retention_days | integer | ہاں | The plan's `backup_retention_days` entitlement, clamped to the platform maximum. |
offsite_enabled | boolean | ہاں | Whether object storage is configured. False means every backup stays on the worker host it was taken on. |
immutable | boolean | ہاں | Whether backup immutability is enforced **and proven recently**. True only when the platform's last reconciliation actually attempted to delete a canary object under the backup… |
immutable_days | integer | ہاں | How many days a written backup cannot be altered or deleted by anyone — us, a compromised site, or a stolen token. 30 by owner ruling (2026-08-12), matching sold retention; `0`… |
immutability_verified_at | string | ہاں | When a delete was last actually attempted against the protected prefix and refused. ⛔ Not when the configuration was last read, and not when the reconciler last ran: a run that… |
immutability_reason | string | ہاں | A stable machine identifier saying why immutability is not currently provable — `never_checked`, `no_rule`, `delete_succeeded`, `credential_missing`, `canary_write_failed`, `ven… |
restore_drill_passed | boolean | ہاں | Whether the platform's weekly restore drill last **passed**, and recently enough to still mean something. The drill restores a real stored backup onto a platform-owned site and… |
restore_drill_at | string | ہاں | When the last drill finished, whatever its outcome. Null when no drill has ever completed. |
restore_drill_reason | string | ہاں | A stable machine identifier saying why restores are not currently proven — `never_drilled`, `no_drill_site`, `no_recent_backup`, `canary_unavailable`, `restore_failed`, `fence_r… |
وہ خرابیان جو یہ اینڈ پوائنٹ واپس کر سکتا ہے
401 · 403 · 404 · 422 · 429 · 503