Skip to main content

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.

MethodPathPermission
GET/v1/team/usersteam:read
POST/v1/team/usersteam:write
PATCH/v1/team/users/{id}team:write
POST/v1/team/users/{id}/resendteam:write
POST/v1/team/users/{id}/deleteteam:write
GET/v1/licenceplan: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:

PowerOn the Team screenWhat it opens
operateOperationsChannels, brands, content sources and the pipeline: the day to day.
approveApprovalsApprove and Reject on posts awaiting approval, and no editing.
adminAdministrationThe 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"] }'
FieldFor
emailTheir address, up to 320 characters. It signs them in, and it has to be unused anywhere on Reelwire.
displayNameOptional, up to 120 characters. They can change it themselves on their profile.
powersAt 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.