Access

Manage your organization and its members

Create an organization, invite people into it, give them access to a product, change a role and remove a member.

An organization is the account that owns your products and the people who work on them. Membership is stored: a person is a member because there is a membership record for them, with a role and a status — so every question about who is on your team has one place to look.

Owners and admins manage membership. Changing a member’s role is owner-only.

Where each action lives:

Surface	Membership actions
Product App	The invite screens exist; they are documented in the next docs cycle.
CLI	None. The CLI covers products, not membership.
MCP	Every action on this page. Tool names are linked per section.
REST	Every action on this page, under `/governance/api/v1/organizations/…`. Browse the endpoints.

Invite a person

Call the invite. organization_member_invite — POST /governance/api/v1/organizations/:organizationId/invitations — takes organizationId, the person’s email, an organization role (owner, admin or member), and an optional productShares array.
Read the outcome. A registered email is added directly: the person becomes a member in one operation, no email is sent, no token is created, and the outcome is reported as added. An unregistered email gets a pending invitation with a 7-day token and an email; the outcome is reported as invited and the invitation as pending.
The person accepts. They open the invitation link and organization_member_accept-invite — POST /governance/api/v1/organizations/invitations/accept — takes the token from that link and flips the membership status from invited to active.
Access lands. A member receives the explicit product grants that came with the invitation. An owner or admin receives access to every product in the organization.

Each entry in productShares names a productId and exactly one of three ways to describe the access:

Field	What it means
`role`	A preset product role.
`roleId`	One of the organization’s reusable role definitions.
`permissions`	An explicit object with `allow` and `deny` pattern lists.

An entry may also carry expiresAt to time-bound the access.

Note. When an invitation names a role definition, the definition’s permissions are resolved at the moment the invitation is created and stored with it. Editing or deleting that definition later does not change access that was already granted, and does not break a pending invitation.

List and revoke invitations

organization_member_list-invitations — GET /governance/api/v1/organizations/:organizationId/invitations — lists the invitations of an organization.
organization_member_revoke-invitation — DELETE /governance/api/v1/organizations/:organizationId/invitations/:invitationId — revokes a pending invitation.

An organization member sees no product by default. Access is granted one product at a time.

organization_member_share-product — POST /governance/api/v1/organizations/:organizationId/members/:userId/products — takes organizationId, userId and productId, plus the same three mutually exclusive ways to describe the access as an invitation, and an optional expiresAt.
organization_member_unshare-product — DELETE /governance/api/v1/organizations/:organizationId/members/:userId/products/:productId — removes the explicit grant. It does not touch access that comes from being an owner or an admin.

Owners and admins do not need shares — they already reach every product in the organization.

List members and what they can reach

organization_member_list — GET /governance/api/v1/organizations/:organizationId/members — returns the stored members with their roles and their product grants.
organization_member_list-product-access — GET /governance/api/v1/organizations/:organizationId/members/:userId/products — returns the products that member can reach, each entry carrying the role, the grant source and the expiry.

Each grant also reports its effective permissions as allow and deny lists, plus the role definition it came from, or nothing when the permissions were set ad hoc.

Note. This is a management view: grants whose expiresAt has already passed are still listed, with their expiresAt shown, so you can see why access ended.

Change a role

organization_member_set-role — PATCH /governance/api/v1/organizations/:organizationId/members/:userId/role — takes organizationId, userId and a role of admin or member. It is owner-only. Ownership is not changed here, and no other call changes it either — see what only the owner can do.

Promoting someone to admin gives them access to every product in the organization. Demoting someone to member removes exactly that role-derived access; any product shared with them explicitly stays shared.

Remove a member

organization_member_remove — DELETE /governance/api/v1/organizations/:organizationId/members/:userId — deletes the membership record and the member’s product grants in that organization.

Create an organization

There are two ways an organization comes into existence.

Route	What happens
With your first product	There is no separate “create an organization” step during onboarding. The screen that creates your first product asks for an organization name; one operation creates the organization, makes you its owner, creates the product, and selects both. Every product you create afterwards goes into the same organization.
Explicitly	`organization_create` — `POST /governance/api/v1/organizations` — takes a `name` of 1–100 characters, creates an organization owned by you, and makes it the active organization for your session.

A person who accepts an invitation joins the inviting organization and gets no organization of their own. If they later create their own product, that creation triggers the first route above.

Note. An organization has a name but no slug. It never appears in a URL — the organization pages operate on the organization you currently have selected.

Work with several organizations

You can belong to more than one organization.

organization_list — GET /governance/api/v1/organizations — returns the organizations you belong to, whether you own them or joined them.
organization_select — POST /governance/api/v1/organizations/select — sets the active organization for the session and returns the active product resolved inside it.

Selecting a product also reconciles the active organization to that product’s organization, so the two selections always agree.

What only the owner can do

The owner is the single person recorded as the organization’s owner. Only the owner can:

rename the organization;
change the organization security policy: whether members must use two-factor authentication, and whether the “remember this device” 30-day skip is allowed. Across several organizations the settings compose strictly — the requirement is on if any organization requires it, and the trusted-device skip is available only if every organization allows it;
read the billing summary — the payer details, the product limit, the product count, and one entry per product. The organization is the payer: it carries a billing email, a payer user, and an optional product limit, and usage metered per product is rolled up to the organization;
delete the organization. Deleting archives the organization and cascades to every product in it. Restoring afterwards is not a self-service action.

Handing the organization over is not on that list. owner can be given when a person is invited, so an organization can have more than one owner from the moment it is set up, but there is no call that transfers ownership afterwards: organization_member_set-role accepts only admin and member. If a product is ultimately going to belong to someone else, have them create the organization and join it yourself as a member.

Owners and admins share the day-to-day management work: inviting and removing members, changing member roles, sharing products with members, and creating products.

Lifecycle

An organization with no products is allowed and is never removed automatically.
An organization can be archived or blocked. These are two independent, reversible states, and both cascade to every product in the organization.
A product stays in the organization it was created in. Nothing available to you moves one to another organization, whether or not you own both.
Permanently erasing an organization’s data is not available.

Next steps

Look up what a role grants: the four product roles, the permission key shape and how one call is decided.
Understand why a member cannot see a product: access is a concrete membership, never a rule evaluated at request time.
Set your organization’s two-factor policy: what the requirement and the trusted-device switch do to each member.
Browse the membership endpoints: every path, method and parameter behind the tools on this page.

Was this page helpful?