---
title: 'How Access Works'
description: 'How an organization, its members, roles, permissions, environments and API keys fit together, and which endpoints manage each.'
---

Everything in MindCloud belongs to an **organization** (a company). Workflows, connections, Analytics pages and API keys all live in one organization, and every request acts in one. [Organizations](/docs/api/rest/introduction/organizations) explains which organizations a key can reach and how to pick one with `X-Company-Id`.

## Members and roles

People belong to an organization as **members**, and each member has one **role**. A role is a set of **permissions**, such as `workflow:edit` or `member:create`. MindCloud's built-in roles (Owner, Admin, Manager, Developer, Member and Viewer, among others) come with fixed permissions; a custom role holds exactly the permissions you give it.

- [List Members](/docs/api/rest/actions/list-members) and [Update Member](/docs/api/rest/actions/update-member) read and change members and their roles.
- [Create Invitation](/docs/api/rest/actions/create-invitation) invites someone by email with a role; they become a member when they accept.
- [List Roles](/docs/api/rest/actions/list-roles), [Create Role](/docs/api/rest/actions/create-role) and [List Permissions](/docs/api/rest/actions/list-permissions) manage roles and show every permission a role can hold.
- [Get Member Permissions](/docs/api/rest/actions/get-member-permissions) shows what one member can do and why, and [Check Authorization](/docs/api/rest/actions/check-authorization) answers whether they can do one thing before they try.

## API keys

An **API key** belongs to the member who created it and acts as that person. A key holds its own set of permissions, and uses one only while its creator holds it too, so a key is never stronger than the person behind it. [Authentication](/docs/api/rest/introduction/authentication) lists every permission and what it allows.

- [Who Am I?](/docs/api/rest/actions/get-me) answers the organization a call acts in and what the key can do there.
- [Create API Key](/docs/api/rest/actions/create-api-key), [Update API Key](/docs/api/rest/actions/update-api-key) and [Revoke API Key](/docs/api/rest/actions/revoke-api-key) manage keys.
- [List Audit Events](/docs/api/rest/actions/list-audit-events) shows what keys changed, and what they were refused.

## The organization itself

- [Get Company](/docs/api/rest/actions/get-company) and [Update Company](/docs/api/rest/actions/update-company) read and change the organization's profile.
- **Environments**, such as Production and Sandbox, let one workflow run against different connections: [List Environments](/docs/api/rest/actions/list-environments).
- An organization can manage others as its **child organizations**: [Child Organizations](/docs/api/rest/introduction/child-organizations) explains how, and one key can then act in each child.

## Product-specific access

Each product adds its own layer on top of roles:

- **Cirra** decides, per role, which apps, models and actions Cirra may use, and who may use each shared connection and how far (its share list of Everyone, roles and teams): [Get Role Capabilities](/docs/api/rest/actions/get-role-capabilities) and [Get Connection Shares](/docs/api/rest/actions/get-connection-shares). Teams group members across roles: [List Teams](/docs/api/rest/actions/list-teams).
- **Cirra Analytics** adds page sharing and seats on top of roles: [Analytics](/docs/api/rest/introduction/analytics).