hosting
PUT /v1/sites/{siteId}/wordpress/users/{wpUserId}/role
Change a WordPress account's role.
認証
ベアラー トークンとして API キーを送信します。キーには sites.view 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。
このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。
試してみる
アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。
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> }'ログインしていますか?ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く
詳細
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`.
パラメータ
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
siteId (path) | Uuid | はい | Site ID (UUIDv7). |
wpUserId (path) | string | はい | The account's WordPress id, as `listSiteWordPressUsers` reports it. |
リクエスト本文
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
role | string | はい | The role the account should hold, from `listSiteWordPressRoles`. |
返信
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
id | string | はい | The account's WordPress id, carried as a string because it is the vendor's identifier rather than ours. |
login | string | はい | The name the account signs in with. |
display_name | string | はい | The name shown on the site's posts and comments. |
email | string | はい | 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 | はい | The account's roles, in the vendor's own spelling. |
registered_at | string | はい | 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 | はい | 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… |
このエンドポイントが返すエラー
401 · 403 · 404 · 409 · 422 · 429 · 503