Roles & Permissions

This page is about your team: the developers, admins, and others who manage your Livqeno project in the dashboard or CLI. Each person in your project is a member with one role. The role decides what they can do.

It is not about your app's users. Their access comes from the tokens your backend makes (see Permissions).

A typical small team:

• The founder or tech lead is the OWNER.
• One or two senior engineers are ADMIN, so they can add teammates.
• Everyone who writes code is a DEVELOPER.
• Support staff who only look at errors and usage are VIEWER.

What each role can do

Worth knowing:

• Developers can manage API keys. They need keys to build. If they had to ask an admin each time, people would start sharing keys, which is worse. Developers still can't add members, change project settings, or delete anything.
• Billing sees usage only. No conversations, connections, or keys.
• keys:read shows key details only: name, environment, last used. Nobody can read a key's secret, not even the owner. It was never stored.

404 or 403?

• Non-members get 404, the same as for a project that doesn't exist. This hides which project ids are real.
• Members get 403, because they already know the project exists. The message tells them their role and the missing capability, so they know to ask for access:

{
  "code": "RAVEN_PERMISSION_DENIED",
  "message": "Your role in this project (viewer) does not allow keys:manage",
  "requestId": "req_9f2c41ab77e0c3d5b1a4e8f2"
}

Managing members

The dashboard's Members screen does all of this for you. If you want to script it, these are the endpoints behind it. They take your developer login (as the dashboard and CLI use), not a project API key:

GET    /v1/projects/{id}/members
POST   /v1/projects/{id}/members      { "email": "…", "role": "DEVELOPER" }
PATCH  /v1/projects/{id}/members/{userId}   { "role": "ADMIN" }
DELETE /v1/projects/{id}/members/{userId}

The list includes each member's capabilities:

{
  "userId": "…",
  "email": "dev@example.com",
  "role": "DEVELOPER",
  "capabilities": ["project:read", "members:read", "keys:read", "keys:manage", "…"]
}

If you build your own internal admin tool on top of these endpoints, use capabilities to hide buttons a user isn't allowed to use. Don't keep your own copy of the table above.

Two rules that keep projects safe

1. Only an owner can add or remove an owner. Otherwise an admin could make themselves owner and remove the real owner.
2. A project always has at least one owner. Removing or demoting the last owner is refused with a 400. A project with no owner could never be managed again.

{
  "code": "RAVEN_VALIDATION_FAILED",
  "message": "This is the project's only owner. Promote someone else to owner first."
}

Existing projects

Whoever created a project is its owner. Nothing changed for a project with one person on it.

Where roles don't apply

Roles only control the dashboard, the CLI, and the /v1/projects/... endpoints. These all use a developer login.

• API keys have no role. A key isn't a person. It belongs to a project and an environment. See Environments.
• Chat has its own roles inside a conversation (MEMBER, MODERATOR, ADMIN). Those are for your app's users, not for people managing your Livqeno project. See Chat Overview.

Next steps

• Add your teammates from the dashboard's Members screen.
• Audit logs: see what each member has changed.
• Security: how the different credentials are kept apart.