Prismic uses a repository-level role system where each user is invited to a specific repository with a defined role. Permissions are scoped to the repository, not to individual documents or content types (though Custom Types can have publishing workflow restrictions on higher plans). The permission model is straightforward compared to self-hosted CMSes -- there are no ACLs, no group hierarchies, and no field-level restrictions in the core product.
Permission model
Prismic's access control has two layers:
- Repository roles -- each collaborator is assigned a role that determines what they can do across the entire repository. Roles are fixed in their permission set (you cannot customize what "Writer" means).
- Custom Roles (Enterprise plan) -- Enterprise customers can define custom roles with granular permissions per Custom Type and locale, controlling who can create, edit, publish, or delete specific content types.
- API tokens -- separate from user roles, API tokens control programmatic read access to content. Tokens are repository-scoped with visibility settings (public or private).
All content in a Prismic repository is accessible to all collaborators -- the role determines what actions they can perform, not what content they can see.
Built-in roles
| Role | Permissions | Plan availability |
|---|---|---|
| Owner | Full control: manage billing, delete repository, manage users, all content operations | All plans |
| Administrator | Manage users, configure Custom Types, publish content, manage releases | All plans |
| Release Manager | Create and manage Releases (scheduled publishing), publish content | Medium+ plans |
| Writer | Create and edit documents, submit for review. Cannot publish directly. | All plans |
| Publisher | Everything a Writer can do, plus publish and unpublish documents | All plans |
| Translation Manager | Manage translations and locale content | Enterprise |
| Custom Roles | Configurable per Custom Type and action | Enterprise only |
Key distinction: Writers create content but cannot publish. Publishers can publish. This enforces an editorial review workflow on teams where Writers submit and Publishers approve.
Admin UI paths
| Task | Location |
|---|---|
| Manage collaborators | Settings > Users & Permissions (repository dashboard) |
| Invite users | Settings > Users & Permissions > Invite |
| Change user role | Settings > Users & Permissions > [User] > Edit role |
| Manage API tokens | Settings > API & Security |
| Create Custom Types | Custom Types editor (left sidebar) |
| Configure locales | Settings > Translations & Locales |
| Define Custom Roles | Settings > Users & Permissions > Custom Roles (Enterprise) |
| Repository transfer | Settings > General > Transfer repository |
API access management
Content Delivery API (CDN):
- Read-only REST API at
https://[repo].cdn.prismic.io/api/v2 - Access controlled by repository access setting: Public (no token needed), Private (requires permanent access token), or Closed (requires session-based auth)
- Permanent access tokens created at Settings > API & Security > Generate Token
- Tokens are repository-scoped, read-only, and do not expire
- Each token can be named for identification (e.g., "Production Frontend", "Analytics Service")
Migration API (write access):
- Write API for bulk content import/export
- Requires a write-enabled token (separate from CDN tokens)
- Scoped to create and update documents
- Available on Premium and Enterprise plans
Prismic Client Libraries:
@prismicio/client(JavaScript),prismic-php, etc.- Pass the access token during client initialization
- All queries return only published content by default; previews require additional configuration
Webhook integrations:
- Configured at Settings > Webhooks
- Triggers on document publish/unpublish events
- Sends POST with document metadata to your endpoint
- No secret signing in basic plans; verify via IP allowlist or custom header
Analytics-specific permissions
Prismic is a headless CMS, so analytics implementation happens in your frontend application. Prismic's role in analytics is limited to content-level concerns:
- Tracking field management -- if you store analytics metadata (UTM parameters, campaign tags, tracking IDs) as fields in your Custom Types, any Writer or Publisher can edit them. Use Prismic Slices to create reusable analytics configuration blocks.
- A/B testing with Releases -- Release Managers can create Releases for content experiments. Your frontend queries different releases for A/B test variants. Limit Release Manager access to control who can create test variants.
- Integration Fields -- Prismic Integration Fields can pull data from analytics platforms (e.g., popular posts from GA). The integration is configured by Administrators and the data is read-only for editors.
- Prismic Tracker (deprecated) -- older Prismic plans included a basic content analytics tracker. This has been removed in favor of external analytics.
- Content API for analytics pipelines -- use a dedicated API token for your analytics data pipeline to query published content metadata. Create a named token like "Analytics Pipeline" for audit clarity.
Since Prismic has no built-in analytics dashboard, "analytics permissions" means controlling who can modify content fields that affect tracking and who holds API tokens used by analytics services.
Sub-pages
- Roles and Permissions -- built-in role capabilities, Custom Roles on Enterprise, and publishing workflow configuration
- Adding and Removing Users -- inviting collaborators, managing API tokens, and offboarding from repositories