POST /v1/sites/{siteId}/collaborators

Autentizace

Odešlete klíč API jako bearer token. Tento koncový bod ve specifikaci uvádí specifické oprávnění, takže svému klíči udělte to nejmenší možné a místo předpokladů zkontrolujte odpověď.

Tento koncový bod nevyžaduje žádné ID organizace. Váš klíč již identifikuje organizaci, ke které patří, a odpověď je na ni omezena.

Vyzvednout

Nahraďte cokoli v závorkách vlastními hodnotami a zástupný symbol klíče klíčem z vašeho řídicího panelu.

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> }'

Přihlášeni? Konzole API ve vašem dashboardu automaticky doplní vaše skutečné ID organizace i váš vlastní klíč a odešle požadavek na živé API, abyste viděli reálnou odpověď. Otevřete tento koncový bod v konzoli API

Podrobnosti

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.

Parametry

Tělo požadavku

Odpověď

Chyby, které může tento koncový bod vrátit

401 · 403 · 404 · 409 · 422 · 429