Role-Based Access Control
Synapse uses six roles with granular permissions to control access across the dashboard and API. Roles are assigned per workspace -- a user can have different roles in different workspaces.
Roles
| Role | Description | Typical User |
|---|---|---|
| Owner | Full access including billing, workspace deletion, and ownership transfer. One per workspace. | Founder, account creator |
| Admin | Full CRM access plus user management. No billing access. | Engineering lead, CTO |
| Developer | Technical operations: flows, templates, segments, contacts (read-only), API keys, dev tools. | Backend/frontend engineers |
| Marketing | Campaign operations: flows, templates, segments, contacts (read-only), analytics with export. | Marketing managers, CRM specialists |
| Operations | Customer support: contact lookup, email history, analytics. Read-only on most resources. | CS team, ops managers |
| Viewer | Read-only analytics dashboard. No access to contacts or configuration. | Executives, stakeholders |
Permission Matrix
This table shows what each role can do across every feature area. Use it to determine which role to assign team members based on their responsibilities.
| Feature | Owner | Admin | Developer | Marketing | Operations | Viewer |
|---|---|---|---|---|---|---|
| Dashboard (analytics) | Full | Full | Full | Full | Read | Read |
| Analytics export | Yes | Yes | -- | Yes | -- | -- |
| Flows -- view | Yes | Yes | Yes | Yes | -- | -- |
| Flows -- create / edit / activate | Yes | Yes | Yes | Yes | -- | -- |
| Templates -- view | Yes | Yes | Yes | Yes | -- | -- |
| Templates -- create / edit | Yes | Yes | Yes | Yes | -- | -- |
| Segments -- view | Yes | Yes | Yes | Yes | -- | -- |
| Segments -- create / edit | Yes | Yes | Yes | Yes | -- | -- |
| Contacts -- list / search | Yes | Yes | Yes | Yes | Yes | -- |
| Contacts -- edit | Yes | Yes | -- | -- | -- | -- |
| Email logs -- search / view | Yes | Yes | Yes | Yes | Yes | -- |
| API keys -- view | Yes | Yes | Yes | -- | -- | -- |
| API keys -- manage | Yes | Yes | Yes | -- | -- | -- |
| Team members -- view | Yes | Yes | -- | -- | -- | -- |
| Team members -- manage | Yes | Yes | -- | -- | -- | -- |
| Sender domains -- view | Yes | Yes | Yes | -- | -- | -- |
| Sender domains -- manage | Yes | Yes | -- | -- | -- | -- |
| System settings | Yes | Yes | -- | -- | -- | -- |
| Dev tools | Yes | Yes | Yes | -- | -- | -- |
| Billing / plan management | Yes | -- | -- | -- | -- | -- |
| Payment methods | Yes | -- | -- | -- | -- | -- |
| Invoices | Yes | -- | -- | -- | -- | -- |
| Delete workspace | Yes | -- | -- | -- | -- | -- |
| Transfer ownership | Yes | -- | -- | -- | -- | -- |
Owner Role
The owner is the person who created the workspace. Each workspace has exactly one owner at any time.
Owner-Exclusive Capabilities
- View and manage billing, payment methods, and invoices
- Change the workspace plan (upgrade/downgrade)
- Delete the workspace permanently
- Transfer ownership to another team member
The owner cannot be removed or downgraded. Ownership can only be transferred to another member via the Danger Zone settings.
The single-owner constraint is enforced at the database level. No application-level bug or API call can create a second owner in a workspace.
Owner vs Admin
The owner/admin split follows a common SaaS pattern: the person paying the bill has exclusive control over financial decisions, while admins control product features.
| Concern | Owner | Admin |
|---|---|---|
| All CRM features | Yes | Yes |
| Manage team members | Yes | Yes |
| Manage API keys | Yes | Yes |
| System settings | Yes | Yes |
| Billing | Yes | No |
| Delete workspace | Yes | No |
| Transfer ownership | Yes | No |
API Enforcement
Permissions are enforced server-side on every API request. The dashboard hides UI elements based on the user's role, but this is cosmetic -- the API always re-validates permissions regardless of how the request was made.
If a user's role does not have permission for the requested operation, the API returns:
What This Means for Your Integration
- API keys inherit the scope assigned at creation (data, reporting, management, full) -- they are not tied to a user's role. Scope enforcement is separate from RBAC.
- JWT-authenticated requests (dashboard users calling the API) are subject to RBAC based on the user's role in the specified workspace.
- Build your client to handle 403 responses gracefully. A user's role may change between requests if an admin modifies their permissions.