Projects & organizations

The hierarchy that holds your resources, roles, and API keys

Every Rightbrain resource lives in a hierarchy:

An Organization owns billing and membership and is the root of ownership. A Project contains the actual resources — Tasks, Agents, Skills, Collections, Connections, and Triggers. All access control is anchored at the Project.

When this matters

Every API path carries both IDs, and every permission check resolves against a Project. So before you build anything you need to know: which organization, which project. Use projects to separate teams, clients, or environments — one project per client is a common pattern.

Roles and permissions

Authorization is relationship-based. Membership grants roles, and roles grant permissions on resources.

At the organization level, members are broadly owner, editor, or viewer (plus domain- and email-allowlist invite rules).

At the project level, roles are fine-grained. Beyond owner/editor/viewer, a project defines targeted roles such as:

  • task_creator / task_runner — create Tasks vs. run them.
  • data_creator / data_editor / data_viewer — manage knowledge and documents.
  • creator roles per resource type — create_skill, create_collection, create_task_agent, create_project_integration, and the MCP-server creator roles.
  • run permissions — run_task and run_task_agent.

IAM-enabled resources also expose their own members endpoints (.../{id}/iam/...) so you can grant access on a single Task, agent, Skill, Collection, or connection rather than the whole project.

API keys

An API key is a machine credential scoped to a (project, user) pair. It carries the permissions of the user it was minted for, in that project. Keys are stored encrypted, and revoking a key immediately invalidates its token.

All Rightbrain authentication uses Authorization: Bearer <token> — an API key is one kind of bearer token. See Authentication for the full auth model (user sessions, OAuth2 client-credentials and authorization-code, task access tokens, and public tasks).

Where org_id and project_id come from

Resource endpoints are shaped:

/api/v1/org/{org_id}/project/{project_id}/<resource>

The org_id and project_id come from the URL path, not from your token — the same key can address any project you have permission for by changing the path. Both IDs are returned by the org and project list endpoints (and shown in the dashboard).

Minimal example

List the projects in an organization, then list the Tasks in one.

$curl https://app.rightbrain.ai/api/v1/org/{org_id}/project \
> -H "Authorization: Bearer $RB_TOKEN"