> ## Documentation Index
> Fetch the complete documentation index at: https://docs.avraapi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & permissions

> Use granular Workspace roles together with project-level delegation to provide least-privilege access.

Workspace access is intentionally layered. A role decides what a member can do inside the Workspace; a connected project’s delegation decides whether that Workspace may perform the same category of work for that specific project.

<Steps>
  <Step title="Check owner authority">
    Is the user the Workspace owner? If yes, the action is allowed immediately. If no, proceed.
  </Step>

  <Step title="Check Workspace role">
    Does the member's Workspace role grant the required permission? If no, the action is denied. If yes, proceed.
  </Step>

  <Step title="Check project delegation">
    For connected-project actions: did the technical owner delegate that category to the Workspace? If no, the action is denied. If yes, proceed.
  </Step>

  <Step title="Action allowed">
    The team member is successfully authorized to perform the action.
  </Step>
</Steps>

## Permission groups

| Group | View permission | Management permissions |
| - | - | - |
| Billing | `workspace.billing.view` | `workspace.billing.manage` |
| UPG | `workspace.upg.view` | `workspace.upg.purchase`, `workspace.upg.attach`, `workspace.upg.configure` |
| Projects | `workspace.projects.view` | `workspace.projects.manage`, `workspace.projects.providers`, `workspace.projects.credentials` |
| Settings & team | `workspace.settings.view`, `workspace.members.view` | `workspace.settings.manage`, `workspace.members.manage`, `workspace.roles.manage` |

## Default and custom roles

Workspaces may use default roles and owner-defined custom roles. A custom role should contain only the permissions needed for the job—such as a Finance Manager with billing access or a Developer with provider configuration access.

<Tip>
  When assigning a management permission, also grant the matching view permission. A user who cannot view the relevant state cannot safely manage it.
</Tip>

## Invitations

An email invitation does not add a user immediately. The invited AvraAPI account reviews the Workspace name, assigned role, and requested permissions, then accepts or rejects the invitation. Membership and role assignment happen only after acceptance.

## Owner authority

The actual Workspace owner retains Workspace authority even if a temporary role assignment is missing or being repaired. Ownership is not merely a role label that can be changed by another member.

<Warning>
  Frontend visibility is only a convenience. Every permission is enforced again by AvraAPI on the server. Do not rely on a hidden button as an authorization control.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.