Workspace roles and permissions — the five-rung access ladder

A workspace starts as one person and one wallet, and permissions are a non-problem. Then a freelance editor joins for a campaign, a backend service needs a key, and someone in finance wants to see what all of this costs. At that point "everyone is an admin" stops being a shortcut and starts being a liability — because on eroq every member spends from the same shared credit balance.

So the roles are a ladder, not a checkbox grid. Five rungs, eleven named capabilities, one rule about who may act on whom. Here is the whole model, and the one behavior that surprises people the first time — what happens to an API key when you demote the person who created it.

The five rungs

Each rung holds every capability of the rung below it, plus its own. That is the entire mental model; the rest is detail.

Owner. Everything, including the two capabilities nobody else has — transferring the workspace to someone else, and deleting it outright. The owner is the account that created the workspace.

Admin. Runs the place. People, billing, workspace settings, API keys, webhooks, generation, publishing, library and usage. Everything except transfer and delete.

Developer. Builds on the API. Creates and revokes API keys, manages webhook endpoints, generates at full rate, publishes, reads the library and the usage log. No billing, no invitations, no settings. This is the rung for the engineer who integrates the API and should never be able to change the plan.

Creator. Works in the studio. Generates, publishes to the community shelf, reads the library and usage. No keys, no webhooks, no settings, no billing. By default a Creator also gets half of the workspace's per-minute rate-limit allowance — enough to work in the video tool all day, not enough to starve a production pipeline running on the same plan.

Viewer. Reads the creation library and the usage log. Cannot spend a credit. This is the rung for a client, a stakeholder, or the person who only ever needs to check what was made and what it cost.

The capabilities themselves are named, not implied — generate, publish, view library, view usage, API keys, webhooks, workspace settings, manage people, billing and plans, transfer ownership, delete the workspace. The matrix on the Members tab at /dashboard/workspace is rendered from the same data the server enforces, so what you see there is what actually happens on a request.

Why the owner is not a role you can assign

Owner is not stored on the membership row. It is a property of the workspace itself — the account that created it — and it is promoted to the top rung when the workspace is read.

That sounds like an implementation detail. It has three consequences you can rely on:

1. There is always exactly one owner. Not "usually one". The schema cannot represent two.
2. You cannot accidentally mint one. An admin handing out roles never sees Owner in the picker, because it is not an assignable role.
3. Transferring the workspace is a deliberate act, distinct from promoting someone. Handing over a company account is not the same gesture as giving a colleague billing access, and the model refuses to blur them.

The practical version — if you are setting up a workspace for a company, create it from an account the company controls, not from a personal login you will want to delete in eighteen months.

You can only manage people ranked below you

The second rule: you may act on a member only if your rank is strictly higher than theirs, and you may never grant a role at or above your own.

Read that twice, because both halves matter:

• Two admins can never demote, remove, or lock out each other. Equal ranks do not touch. If an admin has to go, the owner does it.
• A Developer cannot promote themselves to Admin, or anyone else to Admin, because Admin is not below Developer.
• The invite form's role picker shows only the rungs you are allowed to hand out. An admin sees Admin, Developer, Creator, Viewer. A developer sees nothing to invite with, because invitations are a people capability.

A flat admin tier is where a workspace gets hijacked by whoever is fastest with the mouse during a disagreement. A ladder makes that impossible instead of unlikely.

An API key inherits the role of its holder

This is the part worth internalizing. A key is not a separate identity with its own permissions. It carries the rank of the member who holds it, evaluated on every call.

Demote a Developer to Viewer and their keys stop generating — immediately, without you touching the keys:

curl -X POST https://eroq.ai/v1/videos/generations \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "eroq-motion-one",
    "prompt": "A courier crosses a wet avenue under a broken streetlight, headlights smearing behind her. Tracking shot, 35mm film, neon noir palette, tense tempo.",
    "seconds": 5,
    "aspect": "9:16"
  }'

{
  "error": {
    "message": "This workspace role cannot spend credits. Ask an admin for Creator access or above.",
    "type": "permission_error",
    "code": "role_forbidden"
  }
}

Note what did not happen: nothing was charged, and the key still reads. A demoted member's keys can still list creations and read usage, because those are Viewer capabilities. Only the capabilities you took away stop working.

For offboarding, this is the whole procedure. One role change removes generation across every key that person ever created, without an audit of which keys exist or which service is using them. Change the role first, then revoke keys at your leisure. Role changes take effect on new requests within seconds.

The check also lives in one place on the server — the moment credits are about to move — so a new generation endpoint cannot forget it.

Two dials on top of the role

Roles decide what. Two per-member dials decide how much, and an admin sets both on the Members tab:

A share of the per-minute rate limits, as a percentage. The role's own share is the ceiling — Creator starts at half — and a per-member override can only narrow it further, never widen it above what the role allows.

A monthly credit ceiling. A hard cap on what that member can spend from the shared wallet in a calendar month, reset on the 1st. Refunds net out against it, so a render that failed and refunded itself does not quietly eat someone's allowance. Hitting the ceiling returns a clear refusal naming the number, not a mysterious billing error.

Neither dial is required — leave both empty and a member simply gets what their role grants. Sizing them is its own subject, and the reasoning behind flat credits is in credit pricing for AI APIs.

A sane default mapping

• Backend service or integration → Developer, with one key per pipeline.
• Freelance editor or contractor → Creator, with a monthly ceiling sized to the engagement.
• Producer or account manager who approves spend → Admin.
• Client, stakeholder, auditor → Viewer.
• The account that legally owns the work → Owner, and nobody else.

One more constraint worth planning around before you invite anyone — how many seats your plan holds. Free workspaces hold one, every individual plan holds exactly two, and real teams live on the business tier. The seat grid is on /pricing and answered again on /faq.

FAQ

Can two admins remove each other on eroq?

No. A member can only act on someone ranked strictly below them, so equal ranks are untouchable to each other. Removing or demoting an admin is the owner's job.

What happens to API keys when I demote a teammate?

They keep working for whatever the new role still allows and stop doing the rest. A demotion to Viewer leaves keys able to read the library and usage, while any generation call answers 403 role_forbidden without charging a credit.

Is Owner a role I can give to someone else?

Not as a role. Owner is the account that created the workspace, so it never appears in the role picker — moving it is a transfer of the workspace itself, which is a separate, owner-only action.

Set the ladder up before the second person joins — open the Members tab at /dashboard/workspace.