hosting

POST /v1/sites/{siteId}/backups/transfer-in

Move an externally hosted site onto Zinn® hosting from a backup we hold.

همه نقاط پایانی hosting

احراز هویت

یک کلید API را به عنوان یک توکن حامل ارسال کنید. این کلید باید دارای مجوز hosting.backup.manage باشد؛ کلیدی که فاقد آن باشد با خطای 403 رد می‌شود، نه 404.

این نقطه پایانی هیچ شناسه سازمانی را دریافت نمی‌کند. کلید شما در حال حاضر سازمان مربوطه را مشخص می‌کند و پاسخ در همان محدوده ارائه می‌شود.

امتحان کنید

هر چیزی را که داخل براکت‌های زاویه‌دار قرار دارد با مقادیر خودتان جایگزین کنید، و نگهدارنده کلید را با کلیدی از داشبورد خود جایگزین نمایید.

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_idUuidبلهThe backup to land on this site. It must belong to `source_site_id` and must have completed successfully.
source_site_idUuidبله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_idUuidبلهUUIDv7 identifier — sortable by creation time (docs/02 §8).
backupsSiteBackup[]بله
can_backupbooleanبله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_progressbooleanبله
on_demand_backupsbooleanبله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_reasonstringخیر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_limitintegerبلهOn-demand backups allowed per rolling 24 hours, per site.
on_demand_usedintegerبلهOn-demand backups taken in the last 24 hours. Failed attempts are not counted — the customer got nothing from them.
on_demand_remainingintegerبلهHow many the customer may still take right now.
on_demand_next_atstringبله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_backupsbooleanبلهThe plan's `daily_backups` entitlement — whether the nightly sweep selects this site.
retention_daysintegerبلهThe plan's `backup_retention_days` entitlement, clamped to the platform maximum.
offsite_enabledbooleanبلهWhether object storage is configured. False means every backup stays on the worker host it was taken on.
immutablebooleanبله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_daysintegerبله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_atstringبله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_reasonstringبله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_passedbooleanبله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_atstringبلهWhen the last drill finished, whatever its outcome. Null when no drill has ever completed.
restore_drill_reasonstringبله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