Guide
Team Roles and Permissions
Developer Team Accounts now expose fixed default roles backed by a canonical permission registry and platform middleware.
SoundSync
Role matrix
Sensitive financial and credential permissions are separate.
| Role | Allows | Sensitive restrictions |
|---|---|---|
| Owner | All developer-team permissions | Owner-only for owner role assignment, last-owner protection, tax/payout/highest-risk operations |
| Administrator | Broad operations, products, customers, marketing, credentials, team administration | Cannot assign owner unless owner path is used; tax and owner protections remain restricted |
| Product Manager | Assigned products, files, storefront, reviews, product analytics | No billing, payouts, tax, credential rotation, or team administration |
| Customer Support | Assigned-product customers, orders, entitlements, serials, support records | No billing, payouts, tax, marketing, or credentials |
| Marketing | Campaigns, promotions, storefront content, brand/review content where product scope allows | No billing, payouts, tax, credentials, or team administration |
| Analyst | Read-only analytics, orders, product performance, non-sensitive reporting | No mutations, billing setup, payouts, tax, credentials, or team administration |
| Billing | Billing, statements, settlements, payouts, refunds/disputes visibility, tax visibility | No product editing, marketing sends, credentials, or team administration |
| Developer / Engineer | Product integration surfaces, webhooks, API keys, product credentials, delivery/package settings | No payouts, tax, billing management, customer support mutations, or team administration |
Read access is not financial authorization
Viewing refund/dispute reports does not grant refunds.create. With the current fixed roles, refund initiation is owner-only. Partner agreement management and owner live financial consent are separate checks. Use /api/developer/team/roles to inspect the current role permission registry before assigning access.
Who can read, change and send a campaign
Campaign reads require marketing.view. Creating or editing a campaign, previewing it, duplicating it, sending a test, scheduling, sending now, resuming or canceling requires marketing.manage as well. Product Managers with view-only marketing access can inspect permitted campaigns but cannot send or change them. Both /marketing and /email-marketing API mounts enforce these checks.
Selected-product teammates can access only campaigns whose primary product and complete product-ownership audience are within their assignments. Workspace-wide audiences, negative-ownership audiences and mixed assigned/unassigned campaigns are not exposed through a matching primary product. New scoped campaign audiences are limited to assigned-product owners. AI product and scheduled-deal context must be assigned before generation; a client-supplied product list cannot expand scope.
Workspace sender-setting writes, contact imports and previews, contact-consent changes and segment archival require marketing.manage and all-products scope. Existing automation, growth-flow and bulk-suppression restrictions remain. Permissions do not bypass suppression, sending readiness, approval or provider checks.
Product codes and workspace-wide codes
A teammate with marketing.manage can create or edit promo codes for assigned products. Creating a workspace-wide code, or editing one already saved as workspace-wide, requires all-products scope. Merely opening that code under an assigned product does not make it product-specific. A client cannot change its permission boundary by sending global:false or a different product ID.
Payout onboarding belongs to the workspace owner
Creating or resuming a Stripe Connect onboarding link requires the server-resolved workspace owner, billing.view and all-products scope. An Administrator or Billing role does not authorize onboarding on the owner's behalf. This applies in both test and live modes and through the earnings, settlements and payouts URL aliases.
Balance, ledger, settlement-batch and payout-status access retains the existing billing permissions. A payout-status refresh is not an onboarding link or a transfer. Live setup approval and payout-execution controls remain separate requirements.
Dashboard summaries follow sensitive permissions
Workspace-wide dashboard access requires analytics.view and all-products scope. Customer identity, billing charges, settlement balances and partner health require their own corresponding permissions before those sections are queried or returned. Private order and refund activity follows its record permission. Restricted fields are not evidence of zero activity.
Analysts can read the permitted analytics and saved goals, but cannot save goals. Goal changes require settings.manage, which is held by the owner and administrators in the current fixed roles.
Separate billing reports from payment-method management
Billing reports, invoices, statements and their CSV downloads remain available with billing.view and all-products workspace scope. Opening the developer Stripe billing portal additionally requires billing.manage because that portal can change payment methods and billing contact details.
POST /api/developer/billing/portal-session returns 403 developer_team_permission_denied when billing.manage is missing. Existing role definitions stay unchanged: a read-only billing viewer cannot use the editable portal. This is separate from owner-only Stripe Connect payout onboarding, the customer subscription portal and any transfer execution.