hosting

POST `/v1/sites/{siteId}/wordpress/staging/publish`

Publish a site's staging WordPress over the live site.

所有 hosting 端点

所有开发者文档 →

身份验证

请将 API 密钥作为 bearer 令牌发送。该密钥必须具有 sites.view 权限；缺少该权限的密钥将被拒绝并返回 403 状态码，而非 404。

此端点不需要组织 ID。您的密钥已用于识别其所属的组织，且响应范围也仅限于该组织。

免费试用

将尖括号中的内容替换为您自己的值，并将键占位符替换为您仪表板中的一个键。

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

已登录？您仪表板中的 API 控制台会自动填入您真实的组织 ID 和您自己的密钥，并针对实时 API 运行请求，以便您查看实际的响应。在 API 控制台中打开此端点

详细信息

⛔ The most destructive operation on the managed hosting line: the live site's files and database are replaced by the staging clone's. Its own path, so no request aimed at any other staging operation can reach it. ⛔⛤ The one optional field, mode, selects SCOPE and never DIRECTION. This path exists separately from createSiteWordPressStaging precisely so that no field can flip which way the copy runs — on managed shared hosting both directions are driven from a single value, and one passthrough endpoint would let a request reading as "refresh my staging copy" publish a stale clone over a live shop. Every value of mode copies staging onto live; it says only how much travels. A field that could change the direction must never be added here. ⛔ A scope the site's platform cannot honour is refused 422. Read publish_modes on SiteWordPressStaging first and offer only what it lists: the Zinn® autoscaling platform performs files, db and both, and managed shared hosting performs both only, because its staging operation takes no scope at all. That is a property of the platform, not of the customer's plan — a larger package does not add a database-only publish. Refused 422 when the site has no staging clone — the platform does not check, and would happily publish an empty staging environment over a live shop. The client is required to take a typed confirmation naming the site. 202 because the publish continues at the vendor after the acknowledgement. 404 for a site whose platform has no WordPress to manage. Requires sites.view and sites.panel_access.

参数

名称	类型	必填	内容简介
`siteId (path)`	`Uuid`	是	Site ID (UUIDv7).

请求正文

名称	类型	必填	内容简介
`mode`	`string<files, db, both>`	否	`files` copies the document root and leaves the live database alone; `db` copies the database and search-replaces the staging URL back to the live one, leaving the live files…

响应

名称	类型	必填	内容简介
`permitted`	`boolean`	是	Whether this site may use WordPress staging at all — on the resold range the package type's own flag, and on our own fleet the plan's `staging` entitlement.
`publish_modes`	`string<files, db, both>[]`	是	Which publish scopes this site's platform can actually perform, for `publishSiteWordPressStaging`. A client offers exactly these and no more. ⛔⛔…
`publishable`	`boolean`	是	Whether the plan also carries publish to live, which is a separate permission from creating a staging copy. ⛔ Not folded into `permitted`, because the catalogue sells the two…
`reinstallable`	`boolean`	是	Whether the plan carries reinstalling the platform software over the staging copy. A fifth question for the same reason as `publishable`: the catalogue sells it separately, so…
`idle_removal_days`	`integer`	是	After how many days with no change a staging copy is removed automatically, or `null` when nothing ever removes it. ⛔⛔…
`idle_notice_days`	`integer`	是	How many days' warning the customer is emailed before that removal, or `null` when `idle_removal_days` is `null`.
`operations`	`SiteWordPressStagingOperation[]`	是	The site's recent staging operations, newest first — the client's window onto work that runs after the request returns. ⛔⛔…
`data`	`SiteWordPressStagingClone[]`	是	The staging copies that exist.

此端点可能返回的错误

401 · 403 · 404 · 409 · 422 · 429 · 503

POST /v1/sites/{siteId}/wordpress/staging/publish