POST /v1/migrations

Упълномощаване

Изпратете API ключ като носител (bearer token). Тази точка за достъп не указва конкретно разрешение в спецификацията, затова дайте на ключа си най-малкото необходимо и проверете отговора, вместо да правите предположения.

Този ендпойнт не изисква идентификатор на организация. Вашият ключ вече идентифицира организацията, към която принадлежи, и отговорът е ограничен до нея.

Опитайте

Заменете всичко в квадратни скоби със собствени стойности, а ключовия заместващ символ – с ключ от вашето табло за управление.

curl -X POST https://api.zinndigital.com/v1/migrations \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "source": <MigrationSource>, "host": <string>, "username": <string>, "ownership_attested": <boolean>, "site": <object> }'

Влязохте ли в профила си? API конзолата във вашето табло за управление попълва действителното идентификационно число на вашата организация и вашия собствен ключ и изпълнява заявката спрямо реалното API, за да можете да видите действителния отговор. Отворете този крайpoint в API конзолата

Детайли

The "deploy it and start the migration straight away" path, and the only one that works from an account with no sites yet. ⛔⛔ One endpoint rather than "call POST /v1/sites then POST /v1/sites/{id}/migrations", because the two-call version fails badly: a browser closed between them, or a migration refused for a bad password, leaves an orphan site the customer never asked for, holding one of their plan's site slots, with a hostname they must now delete. Each endpoint did exactly what it was asked and the customer is left holding it. So the ordering here is load-bearing: the source is probed first, and the site is created only once the credentials have been proven against the customer's old host and the estate enumerated. The two failures a customer will actually hit both happen while nothing has been created — and so do the attestation and mail refusals (ownership_not_attested, mailbox_passwords_required, source_cannot_migrate_mail), which until 2026-09-13 were asked only after the site existed. Send mailbox_passwords for the addresses POST /v1/migrations/probe lists. ⛔ Not idempotent, and it does not pretend to be — a retry is refused by the hostname uniqueness constraint, which is a clean conflict rather than a second site. Requires both sites.create and hosting.import.manage: it spends a site slot and connects to a third party's production server, and a principal holding one of those powers must not acquire the other by coming through this door.

Тяло на заявката

Отговор

Грешки, които този крайpoint може да върне

401 · 403 · 409 · 422 · 429 · 503