hosting
POST /v1/sites/{siteId}/wordpress/staging/publish
Publish a site's staging WordPress over the live site.
身份验证
请将 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 with no vendor hosting package. 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 al… |
响应
| 名称 | 类型 | 必填 | 内容简介 |
|---|---|---|---|
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. ⛔⛔ **This is not a permission a… |
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 tw… |
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,… |
operations | SiteWordPressStagingOperation[] | 是 | The site's recent staging operations, newest first — the client's window onto work that runs **after** the request returns. ⛔⛔ **Creating, publishing, deleting and reinstalling… |
data | SiteWordPressStagingClone[] | 是 | The staging copies that exist. |
此端点可能返回的错误
401 · 403 · 404 · 409 · 422 · 429 · 503