hosting

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

Change a WordPress account's role.

توثيقِ شناخت

ایک بیرر ٹوکن کے طور پر ایک API کی بھیجیں۔ کی کے پاس sites.view اجازت ہونی چاہیے؛ اس کے بغیر کی کو 404 کے بجائے 403 کے ساتھ مسترد کر دیا جاتا ہے۔

یہ اینڈ پوائنٹ کوئی آرگنائزیشن آئی ڈی نہیں لیتا۔ آپ کی کلید پہلے ہی اس آرگنائزیشن کی شناخت کرتی ہے جس سے یہ تعلق رکھتی ہے، اور اس کا جواب اسی کے مطابق محدود ہوتا ہے۔

آزمائیں

کوئی بھی چیز جو زاویہ دار قوسین میں ہو اسے اپنی اقدار سے بدلیں، اور کلیدی پلیس ہولڈر کو اپنے ڈیش بورڈ کی کسی کلید سے بدلیں۔

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 کنسول آپ کی حقیقی تنظیم کی آئی ڈی اور آپ کی اپنی کلید خود بخود پُر کر دیتا ہے، اور لائیو 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

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