surreal cloud invite

surreal cloud invite manages organisation invitations: the ones that have been sent and not yet accepted. Once someone accepts, they become a member and move into team.

surreal cloud invite <COMMAND> [OPTIONS]surreal cloud invites <COMMAND> [OPTIONS]

team invite and invite create are the same command reached two ways - the same arguments, the same validators and the same messages - because sending an invitation is both how a team gains a member and how an invitation comes to exist. Use whichever reads better in the script you are writing.

This group declares the scopes read:cloud and write:cloud-organization, the same pair as org and team. A personal access token cannot use the mutating verbs: see Authentication. There is no update: to change an invitation, withdraw it and send another.

surreal cloud invite list

List an organisation's pending invitations.

surreal cloud invite list [OPTIONS]

This command takes no positional argument. The organisation comes from --org and the precedence chain.

Accepts the list presentation flags and nothing else. Column ids are email, role and status, with code and organization_id under --wide.

surreal cloud invite list

EMAIL                ROLE    STATUS
dee@acme.example     member  pending
eli@acme.example     admin   pending

surreal cloud invite list --wide

The list is not filtered by status, so it shows every status the API reports. An organisation with no invitations is a success: exit 0, and an empty array under --json.

surreal cloud invite create

Invite someone to an organisation.

surreal cloud invite create [OPTIONS] --role <ROLE> <EMAIL>

surreal cloud invite create dee@acme.example --role member

while IFS=, read -r email role; do
    surreal cloud invite create "$email" --role "$role"
done < new-joiners.csv

Refusals, exit 2, before any request. The address validator asks only for an @ with something either side and no internal whitespace; the API is the authority on deliverability:

`dee.acme.example` is not an email address: it has no `@`.

Only an empty --role is refused locally, because the role vocabulary is per organisation:

A role cannot be empty. Run `surreal cloud org roles` to see the ones this organization defines.

A role the API rejects as invalid is annotated with a pointer to org roles.

The command is never retried after the request has been written, because a repeat would send a second email carrying a second working code. On success it prints the invitation, including its code.

surreal cloud invite delete

Withdraw an invitation.

surreal cloud invite delete [OPTIONS] <INVITE>

surreal cloud invite delete dee@acme.example

surreal cloud invite delete 7f3a91c4 --force

The invitation has no id of its own. The API identifies it by its code, which the recipient also redeems, so <INVITE> accepts either. An email address is resolved to its code by listing the invitations first, and the listing also happens when you pass a code, so the confirmation can name the address.

Refusals. The confirmation names the address the invitation was sent to. Declining prints Nothing was withdrawn. and exits 0. In a non-interactive session without --force or --yes, it exits 2 having sent nothing.

Withdrawing an invitation someone has already accepted is not how you remove them - use team remove for that.

Related pages

• •

  team commands - members who have already joined

• •

  org roles - the roles an invitation can grant

• •

  Overview - the rest of the reference

• •

  SurrealDB CLI - for working with the data inside an instance