Chelabase
ManagementMembers

Send an invite again

POST
/v1/invites/{invite_id}/resend

A new code is mailed (the old one stops working; an account with a password and a verified email gets the notice again instead), or with delivery: "link" (only for an invitee with no password and an unverified email whom no other tenant holds; others get 409 link_not_allowed) the response carries the new link as invite_url (once, Cache-Control: no-store, never stored or logged); either way the link's token changes and the invite lives another 72 hours. An expired invite can be resent. At most 5 sends per person per hour, the first invite included (429 rate_limited). The body may be left out (then email).

Authorization

bearer
AuthorizationBearer <token>

In: header

Path Parameters

invite_id*string

Invite id

Formatuuid

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

The body of resendInvite; the whole body may be left out (then email).

delivery?Delivery

How the invitee gets the new link. Default email.

Value in

  • "email"
  • "link"

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/v1/invites/497f6eca-6276-4993-bfeb-53cbbbba6f08/resend" \  -H "Content-Type: application/json" \  -d '{}'
{  "expires_at": "2019-08-24T14:15:22Z",  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "invite_url": "string"}

Revoke an invite DELETE

The member becomes `removed` and its grants go; then the invitee's account is deleted when it never set a password; an account with a password, or one that is still a member of another tenant, is left as it is. Revoking an invite whose member is still removed retries that step.

List the tenant's members GET

Invited, pending, active and suspended members, by email: names and emails, for grant pickers. An invited member carries its open invite; a pending one (signed up, waiting for approval) can be approved or declined. Each member carries `access`: the highest platform role over the projects the caller can see and the member's role on each of those projects (`other`: access only on projects the caller can't see; `none`: no project grant). No Postgres roles or overrides.