POST /v1/sites/{siteId}/collaborators

Ìfàṣẹ́pọ̀

Fi bọ́kì kọ́kọ́ (bearer token) ránṣẹ́ gẹ́gẹ́ bí àmì ìdánimọ̀ API. Ibùdó yìí kò sọ àṣẹ pàtó kan nínú àlàyé rẹ̀, nítorí náà fún kọ́kọ́ rẹ̀ ní ohun tó kéré jù lọ tí ó nílò kí o sì ṣàyẹ̀wò ìdáhùn náà dípò kí o kàn rò ó.

Ojú abánisọ̀rọ̀ yìí kò gba id ajọ kankan. Kọ́kọ́rọ́ rẹ ti mọ ajọ ti o jẹ ti e, a o si fèsì nipa rẹ̀.

Gbiyanju rẹ

Rọ́pọ̀ èyíkéyìí nínú àwọn àmì ìtọ́ka < > pẹ̀lú iye tirẹ̀, àti àmì ìdánimọ̀ bọ́tìnnì náà pẹ̀lú bọ́tìnnì kan láti inú dásibọ̀ọ̀dù rẹ.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/collaborators \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "email": <string>, "role": <SiteCollaboratorRole>, "reason": <string> }'

Ṣé o ti wọlé? Iwọ̀n api ní nú ìgbékalẹ̀ rẹ kún id àjọ gidi rẹ ati bọtini tirẹ, o si nṣiṣẹ ibeere na lòdì si api gidi ki o le rii esi gidi na. Ṣí ojú abáná yìí sílẹ̀ nínú kọnsólù API

Àwọn kúlẹ̀kúlẹ̀

Grants one person access to this one site at one role, optionally until a date, and gives them the narrow `site_collaborator` organisation membership if they have none. The narrowing is enforced by Postgres row-level security on the site table itself, not by a filter in a query, so it applies to every endpoint on this API rather than to the ones somebody remembered. ⭐ **The person need not have an account yet.** An address nobody has signed in as is invited in the same call: an ordinary organisation invitation is sent at the `site_collaborator` role, and the grant is returned with `status: pending` and a null `user_id`. The moment they accept — which proves control of that inbox through the identity provider, so no id is ever guessed — the grant activates for that person. A pending grant narrows nobody: nothing is reachable until the accept. If the address already holds a pending invitation to the *whole* organisation the call is refused with `SITE_COLLABORATOR_ALREADY_INVITED` rather than quietly downgrading that invitation to one site. **What a collaborator may then do is the per-site role, on that site only.** A request whose path names a granted site is evaluated with the role's keys (`viewer` reads; `editor` adds `hosting.deploy.manage`, `sites.cache.purge`, `hosting.performance.manage`, `sites.wp_login`, `sites.panel_access`, `sites.restart`, `hosting.php.manage`; `manager` adds `hosting.backup.manage`, `hosting.ssl.manage`, `hosting.cdn.manage`, `hosting.applications.manage`, `hosting.import.manage`). A request naming any other site answers `404`, and a request naming no site — the collection endpoints and every organisation-level surface such as members, API keys and billing — carries only `sites.view`, so it is refused with `403`. Revoking a grant takes effect on the next request, whatever token the person is holding. Every refusal carries its OWN `error.code`, because the status says what happened and only the code says what to do about it. `409` is about the world: `SITE_COLLABORATOR_ALREADY_GRANTED` (this person already has a live or pending grant here), `SITE_COLLABORATOR_ALREADY_A_MEMBER` (they are already an unrestricted member, so a grant would imply a restriction we are not applying — a lie in an access table) and `SITE_COLLABORATOR_ALREADY_INVITED` (above). `422` is about the request: `SITE_COLLABORATOR_EXPIRY_IN_THE_PAST` and `SITE_COLLABORATOR_REASON_REQUIRED`. ⛔ Key on the code, never on `error.message`. The message is a sentence written for a person and it is translated; the code is the contract.

Àwọn ìpìlẹ̀

Akoonu ibeere naa

Idahun

Awọn aṣiṣe ti ibudo ipari yii le da pada

401 · 403 · 404 · 409 · 422 · 429