Child Organizations

An organization can have child organizations, one level deep. A key that belongs to the parent can work inside a child with the same v2 endpoints it uses on its own company. Name the child in the X-Company-Id header:

curl https://connect.mindcloud.co/v2/workflows \
  -H "Authorization: Bearer $MINDCLOUD_API_KEY" \
  -H "X-Company-Id: K3vX9qLm2RtA"

The key's access level applies unchanged, so a read-only key can only read in the child.

Who can do this

The rights come from the person who created the key, checked on every request in the parent organization:

The Owner role has both, and you can add them to a custom role. If the creator loses the permission or leaves the parent, all of their keys lose access to every child on the next request.

Create a child

POST /v2/child-companies creates a new organization that is linked to your company from the start. It has no members. To add people, invite them while naming the child:

curl -X POST https://connect.mindcloud.co/v2/members \
  -H "Authorization: Bearer $MINDCLOUD_API_KEY" \
  -H "X-Company-Id: K3vX9qLm2RtA" \
  -H "Content-Type: application/json" \
  -d '{ "invites": [{ "email": "owner@acme-west.com", "roleId": "iOMZCdjnZIdP" }] }'

A parent can seat the first Owner of a child it created. After that, a parent's key can never add, change or remove an Owner of a child. This rule also stops a parent from taking over an organization that chose to become its child.

Link an existing organization

Two organizations that already exist are linked in Cirra, under Organization Settings, then Parent & child. One side sends a request, and a person on the other side who has the right permission accepts it. Both steps require signing in again. API keys cannot send or accept link requests.

What a parent cannot do in a child

These endpoints answer 403 CHILD_SCOPE_FORBIDDEN when a parent's key names a child:

• API key management (/v2/api-keys). A key created inside the child would keep working after the link ends.
• Embedded endpoints, and connection reads, tests, deletes, universal action runs or lookups that use an embedded end user or installation, including by connectionId alone. Delegated connection lists omit these connections.
• GET /v2/companies and the child organization endpoints, which describe the parent's own company.

A parent's key also cannot hand out power that would outlast the link. It cannot create or edit a role that grants api_key:manage, company:delete, role:manage, member:create, member:edit, member:owner_edit, subscription:manage, company:parent:manage or an embedded: permission (403 ROLE_PERMISSIONS_PARENT_DELEGATE_FORBIDDEN). It also cannot give anyone a role that carries one (403 PARENT_DELEGATE_ROLE_FORBIDDEN), so built-in roles such as Developer and Manager are off-limits too. The first Owner of a child created by the parent remains the exception described above.

Ending the link

• The parent can release a child with DELETE /v2/child-companies/:companyId. A child that has no Owner cannot be released; seat an Owner first.
• The child can leave at any time in Cirra, and the parent cannot block it.

Either way, the parent's keys stop working in the child on the next request. The child keeps its data, and it can review and remove the members the parent added.

Check the scope

GET /v2/me reports delegation when a parent's key is acting on a child. company.parent names the parent of the company you are reading.