Team and plan
The people in the workspace, what each of them may do, and which plan the workspace is on. The same things the Team and Plan screens show, for a workspace set up or checked by machine.
| Method | Path | Permission |
|---|---|---|
GET | /v1/team/users | team:read |
POST | /v1/team/users | team:write |
PATCH | /v1/team/users/{id} | team:write |
POST | /v1/team/users/{id}/resend | team:write |
POST | /v1/team/users/{id}/delete | team:write |
GET | /v1/licence | plan:read |
The Team permission is offered only on a plan with a team (Small business and Enterprise). Renaming the workspace, leaving it, and changing the plan belong to a signed-in person, and no key can reach them.
A key holding team:write is a way into the workspace, not only a way to read it: it can invite a
colleague with the Administration power, who manages API keys. See
Authentication. Give it only to a key whose job is setting
workspaces up.
The people
curl http://localhost:4000/v1/team/users \
-H "Authorization: Bearer rw_your_key_here"
{
"workspace": { "name": "Northwind Markets" },
"users": [
{
"id": "01M38Z6Y78B0DG1817DA49VCMJ",
"email": "sam.carter@northwind.example",
"displayName": "Sam Carter",
"role": "OWNER",
"powers": [],
"lastLoginAt": "2026-09-24T20:26:39.741Z",
"createdAt": "2026-09-24T05:46:29.539Z"
},
{
"id": "01M390CPHEWQ9GWKYWBPTM5YTC",
"email": "priya.nair@northwind.example",
"displayName": "Priya Nair",
"role": "MEMBER",
"powers": ["operate"],
"lastLoginAt": null,
"createdAt": "2026-09-24T06:07:06.889Z"
}
],
"seats": { "used": 3, "max": 10, "included": 10, "additional": 0, "granted": 0 }
}
role is OWNER for the person the workspace belongs to, who holds every power (so their powers
list is empty), and MEMBER for everybody else. powers is what a colleague may do:
| Power | On the Team screen | What it opens |
|---|---|---|
operate | Operations | Channels, brands, content sources and the pipeline: the day to day. |
approve | Approvals | Approve and Reject on posts awaiting approval, and no editing. |
admin | Administration | The Team, API keys and Webhook screens: the people, and the credentials that reach the outside. |
seats counts colleagues, never the owner: used of max, where max is what the plan includes,
plus seats bought as an extra (additional) and seats Reelwire granted (granted). lastLoginAt is
null for somebody who has not signed in yet.
Inviting a colleague
curl -X POST http://localhost:4000/v1/team/users \
-H "Authorization: Bearer rw_your_key_here" \
-H "Content-Type: application/json" \
-d '{ "email": "lea.martin@northwind.example", "displayName": "Lea Martin", "powers": ["operate"] }'
| Field | For |
|---|---|
email | Their address, up to 320 characters. It signs them in, and it has to be unused anywhere on Reelwire. |
displayName | Optional, up to 120 characters. They can change it themselves on their profile. |
powers | At least one of operate, approve and admin: with none they would sign in to an empty dashboard, so that is a 400. |
It answers 201 with the new colleague (user, as the list shows them), password, a starting
password made for them, and minutes, which is null because the setup link does not expire. The
account is ready at once: a letter goes to the address with a link to choose their own password,
which is how they are meant to get in. The starting password is in this answer and nowhere else: it
is kept only as a hash, so it cannot be read again.
A 409 says why it could not be done: the plan has no team (upgrade it), every seat is taken (remove somebody, or buy seats on the Plan screen), or the address cannot be used here, which is all it says about an address that belongs to somebody else.
Changing, resending and removing
PATCH /v1/team/users/{id} takes powers (the whole set they end with, at least one: powers are
replaced, not merged) and displayName (an empty string takes the name away), and answers with the
changed user. Nobody can change the owner's powers or their own; either is a 409.
POST /v1/team/users/{id}/resend sends a fresh setup link to somebody who lost theirs, and answers
{ "sent": true, "email": "...", "minutes": null }. Not to the owner, who resets their own password,
and not twice within a minute to the same person: both are a 409.
POST /v1/team/users/{id}/delete removes somebody at once: they are signed out everywhere and their
account is deleted. What they did stays in the audit trail and on the posts they approved. The owner
cannot be removed, and nobody can remove themselves.
The plan
curl http://localhost:4000/v1/licence \
-H "Authorization: Bearer rw_your_key_here"
{
"licence": {
"plan": "ENTERPRISE",
"state": "ACTIVE",
"term": "MONTHLY",
"capabilities": ["customApi", "team", "analytics", "abTests", "syndicate", "priorityRendering"],
"watermark": false,
"colleagues": 3,
"pending": null,
"costs": {
"renewsAt": "2026-10-24T05:46:29.135Z",
"lines": [
{ "key": "plan", "label": "Reelwire Enterprise subscription (1200 videos a month, 10 seats, 100 syndication partners, 1500 MB storage)", "cents": 49900 }
],
"totalCents": 49900,
"currency": "EUR"
}
},
"plans": [
{ "id": "FREE", "name": "Free", "priceCents": 0, "renders": 25, "seats": 0, "storageMb": 50, "watermark": true, "capabilities": ["customApi"] }
]
}
Shortened here: the answer carries more of costs and all four plans. capabilities is what this
workspace's plan switches on, and the same list decides what the dashboard offers and what every
route allows: customApi (your own custom feeds), team, analytics, abTests, syndicate and
priorityRendering. pending is a change already chosen that starts at the next renewal, such as a
move to a smaller plan. plans lists every plan with its price and allowances, cheapest first.
Changing the plan, buying extras and the invoices are the owner's, on the Plan screen: they change what the workspace pays, and no key can reach them.