Team
One account, many people. Each member has their own API key (so their agent or MCP client shows who they are), a role, and an optional monthly credit cap. Everything anyone makes — brand kits, stored characters, styles, uploads, finished videos, posts — belongs to the account and is shared with the team, with the member who made it recorded on it.
Roles
| role | can |
|---|---|
admin |
Everything: invite and remove members, mint and revoke keys, approve posts, change account settings, plus all of creator. |
creator |
Make things — analyze, edit, record, generate, explainers, brand kits, characters — and draft posts. |
reviewer |
Read everything, approve or reject posts, file reports. Cannot create or spend. |
Account-level keys from before teams existed keep working: an admin key acts as admin, an agent
key as creator.
Invite someone — POST /v1/members (admin)
{ "name": "Urav", "email": "urav@example.com", "role": "creator", "monthlyCreditCap": 500 }
Returns the member, their API key once, and a claimUrl. Send the person the claim link: it shows
them the key one time and expires in 72 hours, so the key never passes through chat. They put it in
their own MCP client (SECOND_STUDIO_API_KEY) and are up — GET /v1/me shows their name, role and spend.
Keys made by an admin are active immediately.
First member: an account that has no members yet may create its first one from any account-level key — it becomes the account's admin. That is how a new customer bootstraps their team on day one.
Member fields: role, email, monthlyCreditCap, monthlyUsdCap, perJobUsdCap, allowedSocialAccounts
(accountIds this person may post to), webhookUrl (POSTed a job.finished event when their jobs end).
GET /v1/members— everyone, with role, live keys, cap andspentThisMonth.POST /v1/members/{id}— changerole,name,email,monthlyCreditCap(nullremoves it). Changing the role re-scopes the member's keys at once.DELETE /v1/members/{id}— their keys stop working; what they made stays.POST /v1/members/{id}/keys— another key for the same person (e.g. a second agent).GET /v1/keys·DELETE /v1/keys/{id}— every live key on the account and whose it is.
Spend control
Three caps, all checked before a job starts, from its estimate, with a 402 member_cap that
says which cap, what's spent and what the job would cost:
monthlyCreditCap— credits per month.monthlyUsdCap— estimated provider dollars per month. This is the one that matters on accounts that run on their own provider keys, where a job costs 1–4 credits of platform fee but real money at the provider (about $0.45 for a character sheet, about $34 for a 30 s 1080p video).perJobUsdCap— no single job over this estimate.
GET /v1/members shows spentThisMonth: { credits, usd } per person; refunds for failed and
canceled jobs net out for the same person.
Who may change what
Everything is visible to every member. Changing or deleting a brand kit, skill, character or voice is for admins and the member who created it. Removing a member keeps what they made.
Shared library — GET /v1/library
One call that lists what the team can reuse by id: brand kits, stored characters (with sheet
URLs), analyzed styles, finished videos and uploads — each with createdBy. Agents should look
here before creating something that may already exist: Urav's character sheet, the brand kit,
last week's launch style.
Attribution
memberId (who made it) is on jobs, assets, brand kits, characters, posts and reports; posts also
carry decidedBy and decidedAt for the approval. GET /v1/reports shows who filed each one.
Your own provider keys
Approved accounts connect their own Higgsfield and ElevenLabs keys themselves: POST /v1/providers/higgsfield
{ keyId, secret }, POST /v1/providers/elevenlabs { apiKey } (admin, over TLS; verified with the
provider, stored encrypted, never returned; DELETE to disconnect; GET /v1/providers shows what is
connected). With your own key, jobs cost the platform fee in credits and the provider bills you.
Ask us to enable it on your account.
Through MCP
library, list_members, invite_member, update_member, remove_member, create_member_key,
list_keys, revoke_key, list_providers, connect_provider, disconnect_provider. Reviewer keys see every tool but can only run the read-only ones plus
approve_post, reject_post and report_issue.
Agents: this page is also available as Markdown; the whole reference is in llms-full.txt.