GET/api/v1/accept-invite

Accept or decline an invitation

Responds to a workspace invitation addressed to the signed-in user, accepting it with the invited role or declining it.

AccessRequires a signed-in caller

The invitation is identified by the workspace it is for, not by the InviteUID that GET /api/v1/get-invites-pending returns, so pass the Workspace.uid from that list as workspace_uid. Send accept=true to accept and take up the invited role, or accept=false to decline. Either way the invitation stops being outstanding, and the response reports only whether the call succeeded.

This GET changes state

Accepting or declining is a state change made with a GET request. Call it only in direct response to a member's choice, and keep it away from anything that issues GET requests on its own: link prefetching, automatic retries on timeout, or crawlers. It is not a read, so it is not safe to repeat.

Query parameters

workspace_uidnumberrequired

The workspace the invitation is for, as returned in Workspace.uid by get-invites-pending.

acceptbooleanrequired

Whether to take up the invitation. true accepts it, false declines it.

bash

curl "$SQRL_API/api/v1/accept-invite?workspace_uid=342&accept=true" \
  -H "authorization: Bearer $SQRL_TOKEN"

const params = new URLSearchParams({
  workspace_uid: "342",
  accept: "true",
});
const res = await fetch(
  `${process.env.SQRL_API}/api/v1/accept-invite?${params}`,
  { headers: { authorization: `Bearer ${process.env.SQRL_TOKEN}` } },
);
const { Success } = await res.json();

rust

let res = client
    .get(format!("{}/api/v1/accept-invite", api_base))
    .query(&[("workspace_uid", "342"), ("accept", "true")])
    .bearer_auth(&token)
    .send()
    .await?;

Response200 OK

{
"Success": true
}

#What happens next

After an accepted invitation the workspace is one of the member's memberships. Read the updated account with GET /api/v1/get-user-info rather than signing out and back in, and the workspace appears with its role in OrganisationsInfo. Before the member can approve anything, they still need a signing profile and a key registered through POST /api/v1/register-key.

Was this page helpful?