Advanced
Workspaces
Manage workspace membership with owner/admin/member roles and understand the limits of shared publishing and billing.
Updated · Guide version 1.1
Read as MarkdownWorkspaces provide a team roster with owner, admin and member roles. Membership does not establish a shared ownership model for every listing, API key, subscription or payout.
Create a workspace and add a member
- •Open Workspaces and enter a name.
- •Create the workspace; the creator becomes its owner.
- •Open its roster and add an existing account using its user ID.
- •Select an allowed role and review the saved roster.
POST /workspaces accepts:
{"name":"Example developer team"}
POST /workspaces/{id}/members accepts user_id and a role of member or admin. It does not accept an email invitation with a publisher role. List workspaces with GET /workspaces and inspect members with GET /workspaces/{id}/members.
Permissions
| Role | Membership management |
|---|---|
| Owner | Add members/admins and grant or revoke admin |
| Admin | Add ordinary members and manage allowed roster changes |
| Member | View the workspace roster |
Only the owner can grant or revoke admin status. The owner's role cannot be changed through this interface and the owner cannot be removed. Removal uses DELETE /workspaces/{id}/members/{user_id}; role changes use PUT on that path.
Limitations and troubleshooting
Publisher, Analyst and Billing are not supported role values. There is no documented workspace-wide API-key inheritance, shared payout account or exported audit log in this interface. Marketplace listing ownership remains enforced by the account-level checks.
If adding someone fails, confirm their existing user ID and your role. An admin cannot create another owner or grant admin status. Do not bypass ownership by changing display names or borrowing another person's session. A roster containing another account's email is private team information; do not expose it to search or analytics.
Next
See Accounts & Authentication, API Keys and Getting Started.