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 first, and a checkbox grid second. Five rungs, fifteen named capabilities, one rule about who may act on whom — and, when a rung does not fit someone exactly, a per-person switch for each capability. 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, the four storage permissions (browse, upload, delete, settings), 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.

When a rung does not fit: tick one permission

A ladder is the right default and the wrong final answer. The editor who should publish but never spend a credit, the contractor who needs API keys for a month but must never see billing, the finance person who should top up the wallet and nothing else — none of them is a rung.

So every capability is also a checkbox. Open a member's access on the Members tab and the role is the starting point: every box is pre-filled from it, and you tick or untick any single one on top. A Viewer with Generate ticked can spend credits; a Developer with API keys unticked cannot create one. The roster shows a small custom tag next to anyone whose access differs from their role, and hovering it lists exactly what was added or removed.

Three rules keep this from becoming a mess:

1. You can only grant what you hold. A Developer can tick Webhooks for a Creator because Developers have webhooks; they cannot tick Billing & plans for anyone, because they do not have it themselves. Unticking is always allowed on anyone below you.
2. Boxes never change rank. A Creator with Manage people ticked can invite and edit people below Creator — and only below Creator. The ladder still decides who outranks whom.
3. Transfer and delete have no box. They belong to the owner, full stop.

You can do all of this before the person arrives, too. The invite form has the same grid folded under the role picker: invite someone as a Viewer with Generate ticked, and that is exactly what they hold from their very first sign-in — no window where a newcomer has more or less than you intended.

A role change keeps the boxes that still mean something: promote a customised Viewer to Creator and the Generate tick, now implied by the role, simply disappears; a Billing tick they had stays. And an API key follows the same rules as everything else — tick or untick a box and the key picks it up within thirty seconds, exactly like a role change.

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.