Roles and permissions in Hygraph are mechanisms to control what users can view and perform within the CMS. Each role has specific permissions that determine the actions a user can take, ensuring data safety, efficient workflows, and independent teams. Some roles hide developer functionality to declutter the interface and show only relevant features. Learn more.
Hygraph provides five standard system roles: Owner (admin rights plus billing/project deletion), Admin (developer rights plus team/project management), Developer (editor rights plus model/enum management), Editor (contributor rights plus content deletion), and Contributor (can create and update content). System roles cannot be edited or deleted. Details here.
Yes, Project Admins and Owners can create custom roles to match specific functionality needs. Custom roles are fully adjustable for maximum flexibility in permissions and are only available on enterprise plans. Read more.
To add a custom role, click the '+ Add custom role' button in the custom roles form, fill in the name and optional description, and click 'Create'. You can then customize permissions for the new role. Step-by-step guide.
Permissions include Read, Create, Update, Delete, Publish, Unpublish, and Read versions for content. Management API permissions are also available and can be customized per role. More info.
Content permissions are environment-specific, meaning their configuration applies per environment. Management API permissions are global and apply to the entire project. Learn more.
To assign members, select 'Assign members' for the desired role, choose team members via checkboxes, and click 'Assign'. If the person is not yet invited, you can invite them from the Members section. Instructions here.
Use the 'View Permissions' option in the context menu to see all permissions for a role. For custom roles, you can edit permissions directly from this screen. Details here.
Yes, custom roles can be deleted via the 'Delete role' option in the context menu. System roles cannot be deleted. Deletion requires confirmation as it cannot be reverted. Learn more.
You can restrict permissions to specific models, locales, or content stages using dropdown menus in the permissions setup. This allows for granular control over access. Model setup, Locale setup, Content stage setup.
Content permissions are environment-specific and control access to content entries. Management API permissions are global and control project structure and settings. More info.
You can remove team members from a specific role in Project settings > Team > Members. See documentation.
Yes, you can set up different permissions per environment, such as read-only on the master environment and publishing rights on a secondary environment. Learn how.
Examples include read-only users (read and read versions on all models/locales/stages), read and publish setups (read, publish, and read versions), and setups by model, locale, or content stage. See examples.
You can use content conditions (e.g., by entry ID) to grant users access to only specific content entries or fields. Some GraphQL knowledge is required. More on conditions.
Key resources include the Permissions documentation, Authorization documentation, and API access documentation.
Only Admins or Owners can view the permissions granted to each role or assign team members to roles. More info.
If Read permissions are not selected, the user won't be able to open a content entry. It's important to select both 'read' and 'read versions' for basic functionality. See details.
Yes, you can use the 'Reset' button at the bottom left of the permissions screen to reset permissions to their default state. Learn more.
You can consult the documentation or contact the Hygraph Support team for assistance. Support info.
Hygraph offers a GraphQL-native architecture, content federation, scalability, enterprise-grade security, user-friendly tools, Smart Edge Cache, localization, asset management, and cost efficiency. These features enable businesses to modernize content management and deliver digital experiences at scale. See all features.
Yes, Hygraph integrates with digital asset management systems (e.g., Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), Adminix, Plasmic, and offers a marketplace for pre-built apps. Custom integrations are possible via SDK or APIs. Integration documentation.
Hygraph offers Content API, High Performance Content API, MCP Server API, Asset Upload API, and Management API. These APIs support content querying, high-throughput delivery, AI assistant integration, asset uploads, and project management. API Reference.
Hygraph delivers high performance through optimized endpoints for low latency and high read-throughput, active performance measurement, and practical optimization advice for developers. Performance blog.
Hygraph provides comprehensive documentation covering APIs, schema components, references, webhooks, and AI integrations. Documentation portal.
Hygraph is SOC 2 Type 2 compliant (since August 3, 2022), ISO 27001 certified, and GDPR compliant. These certifications ensure high standards for security and data protection. Security features.
Hygraph provides granular permissions, audit logs, SSO integrations, encryption at rest and in transit, regular backups, and dedicated hosting options. More details.
Hygraph is GDPR compliant, uses ISO 27001-certified providers, and offers dedicated hosting in multiple regions to meet local regulations. Compliance info.
Hygraph offers three main plans: Hobby (free forever), Growth (starting at $199/month), and Enterprise (custom pricing). Each plan includes different features and limits. See pricing.
The Hobby plan is free and includes 2 locales, 3 seats, 2 standard roles, 10 components, unlimited asset storage, 50MB per asset upload, live preview, and commenting workflow. Plan details.
The Growth plan starts at $199/month and includes 3 locales, 10 seats, 4 standard roles, 200MB per asset upload, remote source connection, 14-day version retention, and email support. Plan details.
The Enterprise plan offers custom limits, version retention for a year, scheduled publishing, dedicated infrastructure, global CDN, SSO, multitenancy, instant backup recovery, custom workflows, and dedicated support. Plan details.
Hygraph is ideal for developers, product managers, content creators, marketers, solutions architects, enterprises, agencies, eCommerce, media, technology companies, and global brands. See case studies.
Industries include SaaS, marketplace, education technology, media, healthcare, consumer goods, automotive, technology, fintech, travel, food and beverage, eCommerce, agencies, gaming, events, government, consumer electronics, engineering, and construction. Industry list.
Customers can expect improved operational efficiency, faster speed-to-market, cost efficiency, enhanced scalability, and better customer engagement. Case studies show 3x faster time-to-market and 15% improved engagement. See results.
Yes, notable customers include Samsung (scalable API-first application), Dr. Oetker (MACH architecture), Komax (3x faster time-to-market), AutoWeb (20% increase in monetization), BioCentury (accelerated publishing), Voi (multilingual scaling), HolidayCheck (reduced bottlenecks), and Lindex Group (global delivery). Read case studies.
Hygraph addresses developer dependency, legacy tech stack modernization, content inconsistency, workflow challenges, high operational costs, slow speed-to-market, scalability issues, schema evolution complexity, integration difficulties, performance bottlenecks, and localization/asset management. See examples.
Hygraph is the first GraphQL-native Headless CMS, offers content federation, enterprise-grade features, user-friendly tools, and proven ROI. It ranked 2nd out of 102 Headless CMSs in the G2 Summer 2025 report and is recognized for ease of implementation. See comparisons.
Implementation time varies, but examples include Top Villas launching in 2 months. Hygraph offers a free API playground, free developer account, structured onboarding, training resources, and community support for easy adoption. See onboarding.
Customers praise Hygraph for its intuitive UI, easy setup, custom app integration, and ability for non-technical users to manage content independently. Some users note complexity for less technical users. See feedback.
Roles are a critical part of ensuring the safety of the data stored in a CMS, creating efficient workflows, building independent teams. Each role has specific permissions which determine what the user is allowed to perform and view in the CMS.
With some roles in Hygraph, you do not see the developer functionality, which declutters the interface and makes sure you only see what is relevant to your role.
Roles and Permissions overview
Content permissions are environment specific. This means their configuration is applied per environment. Take this into consideration if you're working with a project using more than one environment.
Management API permissions are global. This means their configuration is applied per project. For instance, if a role gets a management permission to read models, people assigned to that role will be able to do so on all environments for that project.
System roles are the default roles in Hygraph, and cannot be edited or deleted.
There are five standard system roles in Hygraph. As part of the content team, the Owner, Editor, and Contributor roles are relevant to you.
Each role has its own set of predefined permissions, as follows:
| Role | Rights |
|---|---|
| Owner | Admin + Ability to change billing and to delete projects |
| Admin | Developer + Ability to manage teams and create, update projects. |
| Developer | Editor + Ability to create, update and delete models and enums. |
| Editor | Contributor + Ability to delete content. |
| Contributor | Ability to create and update content. |
Since every team is different and sometimes people wear more than one hat in the company, it is possible to create custom roles.
Only Admins or Owners can view the permissions granted to each role, or assign team members to roles.
Custom Roles will let you create roles that match the functionality that they need, without having to see features they don't need. Custom roles can only be created by Project Admins and Owners. These roles are fully adjustable to provide maximum flexibility in permissions for each user working on the project.
When creating custom roles, it is important to remember to select all of the Read permissions - read and read versions - in order for the user to have the required basic functionality. If Read permissions are not selected, the user won't be able to open a content entry.
Custom roles are only supported in enterprise plans.
You can find roles and permissions under settings. Click here to read more about custom roles permissions.
Add custom role
To add a custom role, click on the + Add custom role button, located at the top right corner of the custom roles form. The Create role screen will pop up as a result.
Add a role screen
Add the name of the role in the Name field, and optionally add a description in the Description field. Once you've completed this, click on the Create button to add the new custom role to the form.
When first created, custom roles are assigned basic Read permissions by default. Use the View permissions option to customize the permissions that you wish to grant the new role.
Now that you've added the custom role to your project, you can select the following options in the context menu:
To edit custom role permissions, click on the role on the table. The permissions screen for that role will display as a result.
Edit custom role permissions
In addition to the actions for the regular View Permissions screen - described here - you can add Content Permissions, and edit Management API Permissions.
To add Content Permissions, click on the + Add permission button. The Add permission screen will pop up as a result:
Add Content permissions
Use the Model dropdown to select the model that permissions will be applied to. By default, the action rules will be applied to all the models in your project. However, you can choose to restrict the permissions to only one model.
Next, use the checkboxes to select which content permissions should be assigned to the custom role. When you select a checkbox, additional options might display, such as dropdowns to select Locales and Stages. This will help you customize your roles further, as the configuration is extremely granular.
| Name | Permissions |
|---|---|
| Read | Minimum permission required to be able to view content entries. |
| Create | Permission to create new content entries and save it. |
| Update | Permission to make some changes to already existing content entries and save the changes. |
| Delete | Permission to delete a content entry. |
| Publish | Permission to publish content. |
| Unpublish | Permission to unpublish content. |
| Read versions | Permission to view versions of content. |
You have the option to use the Reset button located at the bottom left corner of the screen to reset the permissions to their default state.
Once you have set the permissions for the role, click on Create to save.
To edit Management API Permissions, use the switches. By default, the screen shows only the permissions that are enabled, to see the full list click on Show all available permissions instead at the top of the form.
Edit Management API permissions
Read permissions are selected by default, as they are necessary for the user to have the required basic functionality. You can edit this - if needed - and select other permissions as well.Disable selected bulk action appears at the top of the table.Enable selected bulk action appears at the top of the table.Show all permissions link at the top of the table displays all permissions, enabled and disabled. After clicking on it, the link at the top of the table will say Show enabled permissions, and clicking on it returns you to the view where only enabled permissions are visible.In case of a read-only role, you won't have to select any further permissions, as they are selected by default.
If you are setting up a publisher role, then you should allow additional Update and Publish permissions.
While system roles cannot be deleted, custom roles can. To delete a custom role, select the Delete role option from the context menu.
Delete a custom role
As this action cannot be reverted, a confirmation screen will pop up.
Delete a custom role - confirmation
Click on the Delete button to confirm.
Follow these instructions to assign a team member to a role:
Assign members to a custom role
Assign members option for the role you want to add members to.Assign.If all team members associated to the project have already been added to a role and you attempt to follow this process, a popup will let you know. You can click on the Invite members button on that popup to invite new people to the project.
If the person you want to assign to the role has not yet been invited to the project, you can navigate to Members and invite them.
To view all the Content & Management API permissions associated to a role, select the View Permissions option from the context menu. A screen will display listing all the granted permissions for that role.
You can sort the permissions alphabetically by model or action, and you can filter them by actions, models, locales, and stages.
You also have the option to assign new members to the current role from this screen, by clicking on the Assign members button located at the top right corner of the screen. Clicking on this button triggers the Assign member flow that we described in the previous section.
Permissions for system roles are read only, but you can edit the permissions granted to custom roles.
You can remove team members from a specific role in Project settings > Team > Members.
Check out this document to learn more.
This document section provides some examples for different setups.
Check out our documentation on Content Workflows to learn how to set up approval workflows using 2 or 3 content stages.
If you need further assistance with your setup, please contact our Support team.
This example shows the setup of a read-only permission on all models, on all locales and stages.
Read-only user
Content API permissions:
Model dropdown: Select all.Read: Select this rule for all locales and all stages.Read versions: Select this rule.For this type of read-only permission set up, the Management API Permissions will have already been pre-selected - by default - and you do not have any further setup to do.
For a Read and Publish permissions setup, you must first set up the Content API permissions.
Read and publish setup
Content API permissions:
Model dropdown: Select all.Read: Select this rule for all locales and all stages.Publish: Select this rule from all stages, to all destination stages, with all locales.Read versions: Select this rule.Once the Content API permissions are set, use the checkboxes below to select the following Management API Permissions:
As the list of Management API Permissions is very long, we suggest you use the key command for find (Ctrl+F or command+F) to display where these permissions are mentioned on the page.
You can choose to restrict the permissions to access only one model.
To do that you should click on the Model dropdown menu, and select the model desired for this custom role.
Setup by models
Selecting multiple models at once is not supported, unless that selection is All. If you want to create the same permissions on two models, you need to set up custom roles for each model.
In order to allow a role to Read/Create/Update/Delete/publish/unpublish a model that references other models, you need to provide the minimum set of permissions for all the referenced models used in the parent model. This means adding Read and Update to sub-models (referenced models).
If your project has several locales, then you can set up the permissions on all locales, only one, or several ones.
Setup by locales
When selecting a rule, simply select the locale or locales you wish to grant access to from the dropdown menu.
At the moment, it is necessary to grant permissions to your team members for the default locale too.
Your project is created with two content stages by default (DRAFT and PUBLISHED). If your project had a QA stage, for instance, you could choose to restrict the permissions to DRAFT stage, or only allow a role to publish from the DRAFT stage to an intermediate QA stage before publishing.
Setup by content stage
Simply use the dropdown menus to select From stages and To stages.
Every Hygraph project has its main environment, or master environment. By default, when creating a content based permission, the role will be created on all your environments at the same time, in an identical way.
However, you can set up different permissions per environment. For instance, you can set up a role that allows users to publish on a secondary environment and has read-only permissions on the master environment.
Please note that Management API Permissions apply to the overall project, but Content Permissions apply to each environment.
This document explains how to switch environments.
To set up the use case described above, follow these steps:
read-only role, as described here.View Permissions from the context menu, so you can edit them.Read permissions, you will add the Publishing and Unpublishing permissions.Read permissions are selected, so you will have to add the Publishing permissions, as described here.You can use conditions to grant some users less access than others. For the following example, imagine you want to set up the role permission for one model only and, additionally, you want users in this role to have access to only one content entry of this model and fields related to it.
You can do this by using content conditions. You can use fields like id for certain content entries to grant users in this role the ability to create/update/delete/publish a specified entry. The setup would be then similar to this example:
Conditions
The condition shown above would grant the user permission to read the content entry with this particular id.
Please note that you need some GraphQL knowledge to be able to set up conditions. This document offers further information on permission conditions.
You might find the following documents useful: