hosting

PUT `/v1/sites/{siteId}/wordpress/users/{wpUserId}/role`

Change a WordPress account's role.

Xác thực

Gửi khóa API dưới dạng mã thông báo bearer. Khóa này phải có quyền sites.view; khóa không có quyền này sẽ bị từ chối với mã lỗi 403, không phải 404.

Endpoint này không nhận ID tổ chức. Khóa của bạn đã xác định tổ chức mà nó thuộc về và phản hồi được giới hạn trong phạm vi đó.

Dùng thử

Thay thế bất kỳ nội dung nào trong ngoعل (angle brackets) bằng giá trị của riêng bạn và trình giữ chỗ key bằng một key từ trang tổng quan của bạn.

curl -X PUT https://api.zinndigital.com/v1/sites/{siteId}/wordpress/users/{wpUserId}/role \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "role": <string> }'

Đã đăng nhập? Bảng điều khiển API trong trang quản lý của bạn sẽ tự điền ID tổ chức thực tế và khóa của riêng bạn, sau đó chạy yêu cầu đối với API trực tiếp để bạn có thể xem phản hồi thực tế. Mở điểm cuối này trong bảng điều khiển API

Chi tiết

Replaces the account's roles with exactly the one in the body — the other half of "add and remove administrators", and the half that lets a customer fix a mistake without deleting somebody's account and their authorship along with it. ⛔ **Replaces, never adds.** WordPress lets one account hold several roles at once, so granting the new role without removing the old one would leave a "demoted" administrator holding both — an account that reads as an editor on every screen and can still do everything. That outcome is indistinguishable from a successful demotion, which is why the distinction is stated here rather than left to the implementation. Its own path rather than a field on the user resource, for the same reason the password reset has one: a role change and a delete must not be two shapes of one request. **Promoting to `administrator` and demoting *from* one both** require the package's administrator-management capability, not merely `wp_users`. The promotion is obvious; the demotion matters just as much, because removing the last administrator's role locks every human out of the site as thoroughly as deleting them would. `422` for a role the install does not define, or a platform with no role field. `404` for a site with no vendor hosting package, and for an id that is not on it. Requires `sites.view` and `sites.panel_access`.

Tham số

Tên	Loại	Bắt buộc	Nội dung này là gì
`siteId (path)`	`Uuid`	Có	Site ID (UUIDv7).
`wpUserId (path)`	`string`	Có	The account's WordPress id, as `listSiteWordPressUsers` reports it.

Nội dung yêu cầu

Tên	Loại	Bắt buộc	Nội dung này là gì
`role`	`string`	Có	The role the account should hold, from `listSiteWordPressRoles`.

Phản hồi

Tên	Loại	Bắt buộc	Nội dung này là gì
`id`	`string`	Có	The account's WordPress id, carried as a string because it is the vendor's identifier rather than ours.
`login`	`string`	Có	The name the account signs in with.
`display_name`	`string`	Có	The name shown on the site's posts and comments.
`email`	`string`	Có	The account's email address. Personal data about the customer's own users, which is why the whole listing is gated on `sites.panel_access`.
`roles`	`string`	Có	The account's roles, in the vendor's own spelling.
`registered_at`	`string`	Có	When WordPress recorded the account, in the vendor's own format. Not typed as a date-time: the platform does not guarantee one, and coercing it would invent precision.
`is_administrator`	`boolean`	Có	Whether the account is an administrator. ⛔ Set from which vendor endpoint the row came from, not guessed from the role string — the two lists sit behind two different capabi…

Các lỗi điểm cuối này có thể trả về

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

PUT /v1/sites/{siteId}/wordpress/users/{wpUserId}/role