Workspace roles: Admin, Editor, Contributor and Viewer
Every member of a workspace has one role. The role decides what they can do in the dashboard and what any API key, MCP session or integration they set up can do. There are four roles.
The four roles
Admin runs the workspace. Admins connect and disconnect social accounts, pick Facebook pages and Pinterest boards, invite and remove members, manage webhooks and every API key, and can do everything an Editor can.
Editor does the publishing work. Editors create, edit, schedule, publish, retry and delete posts, including posts other members created. They manage webhooks and the post signature, upload media, use the AI tools and read analytics. Editors cannot connect or disconnect social accounts; that is Admin only.
Contributor prepares content without the power to send it. Contributors create and edit their own drafts, upload media, use the AI tools, read posts and analytics, and can create their own API keys. They cannot schedule, publish, retry or bulk schedule, cannot delete anything except their own drafts, and cannot touch other members' posts, the connected accounts or webhooks. An Editor or Admin publishes what a Contributor drafts.
Viewer reads. Viewers see posts, connected accounts, analytics, members and webhooks, and cannot create or change anything.
Which role to give
- A client or stakeholder who wants to watch the calendar: Viewer.
- A writer, designer or agency contact who drafts posts but must never publish under your name: Contributor.
- A social media manager or virtual assistant who runs the accounts day to day: Editor.
- The person who owns the accounts and the billing: Admin. Keep the number of Admins small.
Change a member's role
- Open the Team page.
- Find the member and pick the new role.
- The change applies to their next request, in the dashboard and through every API key they created.
Only an organization owner can make someone an organization admin, or change or remove an existing organization admin.
API keys carry a role
A key is created under a role, chosen on the API Tokens page. A member cannot create a key with a role above their own, and a key never has more than its creator has right now: move the creator from Editor to Contributor and every key they created can only draft from that moment on; remove them from the workspace and their keys stop working. Call GET /api/v1/me with a key to read its role and its exact permission list. The Authentication page has the full permission table and the error a key gets when it tries something outside its role.
How this is enforced
A Contributor seat and a Contributor key are enforced on the server, not in the interface. Every request, whether it comes from the dashboard, the REST API, the MCP server or an integration such as Zapier or n8n, passes through the same permission check in the post service before anything is written: the check reads the caller's role in the workspace at that moment, works out the permission the request needs from its facts (draft, scheduled or publish now; own post or a teammate's), and refuses with a 403 when it is missing. A key is created under a role, never above the member creating it, and its permissions are recalculated on every call as the overlap of the key's role and the creator's current role, so demoting the creator shrinks the key at once and removing them kills it. An auditor can point at three things: GET /api/v1/me, which returns the role and the exact permission list a key has right now; the 403 body, which names the missing permission, the role that lacked it and the kind of token that tried; and the post audit trail, where every create, schedule, publish, retry and delete attempt is recorded with who did it, through which key, under which role, from which status to which, and whether it was allowed or refused. The trail is written by the post service; it is not exposed in the dashboard or the API yet.