The membership object and the allowed CRUD operations on the related resource endpoint

Admins can invite one or more users to join an organization by creating a new membership associated with the user's email address.

New members can also be assigned a a role by associating it with the membership. The new member(s) will receive the invitation by email and will be prompted to create an account if they don’t already have one or to sign in to the Dashboard if they do. Memberships are created in a pending status, which becomes active as soon as the member accepts the invitation. If that doesn't happen, the invitation can be resent by calling a dedicated endpoint. If the invited users already exist (i.e. they already have an account), the related memberships will be directly created as active.

Members that haven't an admin role cannot create membership and are allowed to delete only their own. Admins can delete other users' memberships. Membership creation can also be limited due to your subscription plan type.

Some basic member information (e.g. the user's email, first and last name) is directly available when fetching the related membership. The members who are owners of the associated organization will have the owner flag set to true.

The owner attribute is read-only. To transfer the ownership to another member of the organization you need to call a dedicated endpoint. Owners cannot delete their own membership without transferring it first.

Resending an invitation

To resend an invitation to the user email associated with a (still) pending membership, send a POST request to the /api/memberships/:id/resend endpoint, where :id is the ID of the membership in question, with an empty body payload.


The following request resends an invitation for the membership identified by the "xYZkjABcde" ID:

curl -g -X POST \
  '' \
  -H 'Accept: application/vnd.api+json' \
  -H 'Authorization: Bearer {{your_access_token}}' \
  -H 'Content-Type: application/vnd.api+json' \
  -d ''

Last updated