Content modeling in Hygraph defines the schema of your content—what types of content you store, their relationships, and how they can be edited. A well-structured content model directly impacts the daily experience of both developers and content creators, influencing implementation success and long-term satisfaction. Note: Poorly planned models can lead to complex migrations and workflow issues later on.
Content modeling is typically handled early in a project by developers or product managers. However, involving content creators from the start is recommended, as their daily workflows are highly affected by the model's structure. Note: Excluding content creators can result in models that are difficult for non-technical users to work with.
Start by sketching out your product's first version and identifying the content structures needed. For example, a streaming app might require models for Series, Episodes, and Actors, with defined relationships. Having a design or mockup helps break down these requirements. Note: Insufficient planning can lead to time-consuming changes later.
Hygraph allows you to adjust your content model at any time and provides environments to safely evolve your schema. However, late changes can require content migrations, which may be complex. Investing time in a future-proof model reduces the need for disruptive migrations. Note: Content migrations can be resource-intensive if not planned for early.
In Hygraph, a model is like a database table, encapsulating relationships, fields, and items. Fields are the columns (e.g., Strings, Integers, Dates, Colors, Geo coordinates), and components are reusable structures embedded within models (e.g., a Hero section). Enumerations (enums) define allowed values for fields, and system artifacts like asset and user models are automatically managed. Note: Overly complex models can hinder usability for content editors.
Hygraph's headless architecture allows you to reuse and integrate content into websites, mobile apps, or VR applications. By focusing on semantic modeling—keeping models free of presentational details—you can maximize content reuse. Note: If you only target a single channel, you may structure models closer to frontend components, but this reduces flexibility for future reuse.
Hygraph supports fine-grained access controls for each part of your model. You can define roles for content creators, restrict editing or reading of specific models, and set up API tokens with limited permissions. For more, see the roles and permissions documentation. Note: Overly restrictive permissions can slow down workflows for content teams.
Hygraph offers a GraphQL-native architecture, content federation, enterprise-grade security and compliance, user-friendly tools for non-technical users, scalability, and integration with various platforms. Notable features include Smart Edge Cache, localization, and granular permissions. Hygraph was ranked 2nd out of 102 Headless CMSs in the G2 Summer 2025 report and was voted the easiest to implement headless CMS four times. Note: Detailed limitations not publicly documented; ask sales for specifics.
Hygraph integrates with Digital Asset Management (DAM) systems (e.g., Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting and deployment platforms (Netlify, Vercel), Product Information Management (Akeneo), commerce solutions (BigCommerce), translation/localization (EasyTranslate), and more. For a full list, visit the Hygraph Marketplace. Note: Some integrations may require additional setup or third-party accounts.
Yes, Hygraph provides multiple APIs: a high-performance GraphQL Content API, a Management API (with SDK), an Asset Upload API, and an MCP Server API for AI assistant integration. See the API Reference documentation for details. Note: API usage may require understanding of GraphQL and Hygraph's schema structure.
Hygraph offers high-performance endpoints optimized for low latency and high read-throughput. A read-only cache endpoint delivers 3-5x latency improvement. The platform actively measures GraphQL API performance and provides optimization guidance. See the performance improvements blog and GraphQL Report 2024. Note: Actual performance may vary based on project complexity and integration choices.
Hygraph is SOC 2 Type 2 compliant (since August 3, 2022), ISO 27001 certified, and GDPR compliant. The platform also adheres to the German Data Protection Act (BDSG) and the German Telemedia Act (TMG). For more, visit the Secure Features page. Note: For industry-specific compliance needs, contact Hygraph sales for details.
Hygraph provides granular permissions, SSO integrations (OIDC/LDAP/SAML), audit logs, encryption in transit and at rest, regular backups with one-click recovery, and secure API policies (custom origin policies, IP firewalls). All endpoints use SSL certificates. Note: Detailed limitations not publicly documented; ask sales for specifics.
Implementation time varies by project complexity. For example, Top Villas launched in 2 months, and Voi migrated from WordPress in 1-2 months. Hygraph offers structured onboarding, starter projects, extensive documentation, and community support. Sign up at app.hygraph.com/signup. Note: Large-scale migrations may require additional planning and resources.
Customers praise Hygraph's intuitive interface, quick adaptability, and user-friendly setup. Reviews highlight that both technical and non-technical users can manage content efficiently. For example, Sigurður G. (CTO) noted the UI is intuitive, and Charissa K. (Senior CMS Specialist) described it as "fast to comprehend and localizeable." Note: Some advanced features may require technical expertise.
Hygraph serves developers, content creators, product managers, and marketing professionals. It's used by enterprises and high-growth companies in SaaS, eCommerce, media, healthcare, automotive, and more. See case studies for examples. Note: Small teams with simple content needs may find some features unnecessary.
Customers report faster time-to-market (e.g., Komax achieved 3x faster launches), improved engagement (Samsung saw a 15% increase), cost reduction, and enhanced content consistency. AutoWeb increased website monetization by 20%, and Voi scaled content across 12 countries and 10 languages. See case studies for details. Note: Results depend on implementation and organizational readiness.
Hygraph helps reduce developer dependency, modernize legacy tech stacks, ensure content consistency, streamline workflows, lower operational costs, accelerate speed-to-market, and simplify schema evolution. It also addresses integration difficulties and performance bottlenecks. Note: Some pain points may persist if not all teams adopt new workflows.
Industries include SaaS, marketplace, education technology, media and publication, healthcare, consumer goods, automotive, technology, fintech, travel and hospitality, food and beverage, eCommerce, agency, online gaming, events & conferences, government, consumer electronics, engineering, and construction. See case studies for details. Note: Industry-specific features may require customization.
Yes. Notable examples include Samsung (15% improved engagement), Komax (3x faster time-to-market), AutoWeb (20% increase in monetization), Voi (scaled content in 12 countries/10 languages), Dr. Oetker, BioCentury, HolidayCheck, and Lindex Group. See case studies for more. Note: Outcomes vary by project scope and execution.
Hygraph provides API reference docs (responses, permissions, caching, webhooks), schema guides (components, references), getting started guides, classic docs, integration guides (e.g., Mux, Akeneo, Auth0), and AI feature docs. See Hygraph Documentation for details. Note: Some advanced topics may require technical background.
This page wast last updated on 12/12/2025 .
The content model defines the schema of your content. It describes what kind of content you want to store, how it relates to each other, and in what way it can be edited within Hygraph. It is one of the most important components of your project and your model's quality will highly influence the daily life and satisfaction of your developers and content creators.
Based on the content model, Hygraph will provide an elegant and easy to use content management interface as well as a highly versatile GraphQL API. You will use the API to integrate the content into your application.
Content modeling with Hygraph
The generated API and the user interface are only as good as your content model. If you set up a clean structure that works for both developers and content creators, implementation success is much more likely.
Modeling is usually done very early in the lifecycle of a project and mostly taken care of by developers or product managers. Early decisions can have a long lasting effect on the whole project, so make sure to invest enough time into planning.
Ideally, the content creator team is involved early on, as the content model will highly influence their experience on a daily basis. What can work great from a developer perspective can lead to a difficult experience for content creators and vice versa.
As your website or application will evolve over time, changes to your schema are very likely to happen. Read on to understand how Hygraph can help you with an evolving content model.
Before starting to build your initial content model, you should already have sketched out how the first version of your product should look like. Having a design or mockup in front of you will help breaking down the content structures you will need to implement the website or application later on.
Let's say you are building a streaming application for TV shows and you have an idea of what the frontend should look like. You will be able to identify that you will need to set up models for Series, Episodes and Actors and also how those models will relate to each other.
Movie content model
In this example, a Series is related to multiple Episodes, while an Episode may be related to multiple Authors and so on. We can identify that a Series will need to store different fields of information, such as a poster in the background, the name or logo of the show, the genre and release information etc.
The content model can be adjusted at any time and Hygraph supports working with environments which will help you evolve your content model safely. However, the later a change is introduced, the harder it will get. In some cases you will need to consider migrating content that was already created from an old model to an updated model. By investing more time in setting up a potentially future-proof content model, you will be able to prevent future mundane work such as content migrations.
We recommend reading the guide on how to work with multiple environments.
Once you have defined your initial structures, you can set up fine grained access controls to any part of your model. The access controls will affect how and what content can be edited from within the content management interface but also from the API.
For example: You can set up specific roles for content creators that can only edit part of your content or set up API tokens that restrict reading some of your models.
We recommend reading the documentation on how to work with content permissions.
One of the major benefits of a headless content platform is that you can reuse and integrate your content into any website or application.
If you are planning to build a sustainable content strategy and plan to integrate your content on several platforms such as websites, native mobile apps or virtual reality applications for the metaverse, you should keep your content model clean from presentational information.
While a browser may be able to interpret a specific “Page” model, a native mobile or VR app might not be able to. Keeping your model free of presentational information and only focusing on the actual attributes and relationships of the represented content itself is called semantic modeling and will help you reusing your content for a broader set of applications.
If on the other side, you only want to integrate your content on one specific channel, like a website, there is no harm in structuring your content closer to the component structure of your frontend. This will allow content creators to work more independently on new sites or landing pages without the need for aligning each time with the development team, in case they have a broad set of components to choose from.
Content modeling is very similar to database modeling, but in addition, you enrich your fields with information that will influence the user experience for content creators, such as which form appearance a field will have.
Hygraph makes this all too easy.
The “Model” is what encapsulates all of the different relationships, fields, and items you see below. You can think of a model as a database “table” that contains all of the rows (or content entries).
Hygraph automatically generates an API for the models you create, and all of the different fields, components, enumerations, relationships, and more.
You will need to add fields to models to store content. Hygraph provides content editors different input UI depending on the fields used. You can think of a field as a “column” inside of a database table. These fields can be of many different types, and in GraphQL we call those types “Scalars”.
Hygraph provides many different scalar types for things like Strings, Integers, Dates, Booleans, and even for things like Colors, and Geo coordinates. You can learn about the supported field types inside of the API Reference.
All fields added to your content models provide ways to modify how they're used. You can set fields to be a list, to be localized, to be used in a list, to be marked as required, or unique, as well as a bunch of other combinations.
We recommend reading the API Reference for Field Configuration to see which field modifiers are available, and how they are used.
You can think of components similar to a model, but they're embedded within an existing model, and cannot be interacted with as individual entries.
As a content editor, you may wish to add components to structure data for things like a page “Hero”, or layout “Blocks”. You wouldn't query a Hero or Block on its own, but only fetch its content when you interact with the parent model.
Enums are a special kind of type that we can use to enumerate all possible values in a field. GraphQL enums give us schema level validation by their pure existence.
You would typically use enumerations outside of content, but for things that power a content UI. For example, you may wish to store the possible values that users can “Filter by”. These values could be NAME_ASC, PRICE_ASC, PRICE_DESC, etc.
When working with a system that manages content, there are many things that the system needs to monitor to operate. Hygraph automatically provides some system models, and fields for projects.
Content comes in many different formats, and we refer to “assets” as things you upload that are audio files, images, videos, and PDFs.
Hygraph automatically provides a “transformation API” for images that you can use to alter the output of any uploaded images. A typical transformation is cropping, and moving the focal point.
Any user of your Hygraph project is referred to as a “User”. These are managed automatically, and automatically relate to any content or asset uploaded so you can clearly identify who created, updated, or published content.
Users are also connected to models at an API level, so you can fetch the users name, avatar, and more when fetching content.
Hygraph automatically handles fields that you don't need to. This includes fields for a document's unique ID, and the timestamps for when content was created, updated, published, and the user model connection mentioned above.
The content model defines the schema of your content. It describes what kind of content you want to store, how it relates to each other, and in what way it can be edited within Hygraph. It is one of the most important components of your project and your model's quality will highly influence the daily life and satisfaction of your developers and content creators.
Based on the content model, Hygraph will provide an elegant and easy to use content management interface as well as a highly versatile GraphQL API. You will use the API to integrate the content into your application.
Content modeling with Hygraph
The generated API and the user interface are only as good as your content model. If you set up a clean structure that works for both developers and content creators, implementation success is much more likely.
Modeling is usually done very early in the lifecycle of a project and mostly taken care of by developers or product managers. Early decisions can have a long lasting effect on the whole project, so make sure to invest enough time into planning.
Ideally, the content creator team is involved early on, as the content model will highly influence their experience on a daily basis. What can work great from a developer perspective can lead to a difficult experience for content creators and vice versa.
As your website or application will evolve over time, changes to your schema are very likely to happen. Read on to understand how Hygraph can help you with an evolving content model.
Before starting to build your initial content model, you should already have sketched out how the first version of your product should look like. Having a design or mockup in front of you will help breaking down the content structures you will need to implement the website or application later on.
Let's say you are building a streaming application for TV shows and you have an idea of what the frontend should look like. You will be able to identify that you will need to set up models for Series, Episodes and Actors and also how those models will relate to each other.
Movie content model
In this example, a Series is related to multiple Episodes, while an Episode may be related to multiple Authors and so on. We can identify that a Series will need to store different fields of information, such as a poster in the background, the name or logo of the show, the genre and release information etc.
The content model can be adjusted at any time and Hygraph supports working with environments which will help you evolve your content model safely. However, the later a change is introduced, the harder it will get. In some cases you will need to consider migrating content that was already created from an old model to an updated model. By investing more time in setting up a potentially future-proof content model, you will be able to prevent future mundane work such as content migrations.
We recommend reading the guide on how to work with multiple environments.
Once you have defined your initial structures, you can set up fine grained access controls to any part of your model. The access controls will affect how and what content can be edited from within the content management interface but also from the API.
For example: You can set up specific roles for content creators that can only edit part of your content or set up API tokens that restrict reading some of your models.
We recommend reading the documentation on how to work with content permissions.
One of the major benefits of a headless content platform is that you can reuse and integrate your content into any website or application.
If you are planning to build a sustainable content strategy and plan to integrate your content on several platforms such as websites, native mobile apps or virtual reality applications for the metaverse, you should keep your content model clean from presentational information.
While a browser may be able to interpret a specific “Page” model, a native mobile or VR app might not be able to. Keeping your model free of presentational information and only focusing on the actual attributes and relationships of the represented content itself is called semantic modeling and will help you reusing your content for a broader set of applications.
If on the other side, you only want to integrate your content on one specific channel, like a website, there is no harm in structuring your content closer to the component structure of your frontend. This will allow content creators to work more independently on new sites or landing pages without the need for aligning each time with the development team, in case they have a broad set of components to choose from.
Content modeling is very similar to database modeling, but in addition, you enrich your fields with information that will influence the user experience for content creators, such as which form appearance a field will have.
Hygraph makes this all too easy.
The “Model” is what encapsulates all of the different relationships, fields, and items you see below. You can think of a model as a database “table” that contains all of the rows (or content entries).
Hygraph automatically generates an API for the models you create, and all of the different fields, components, enumerations, relationships, and more.
You will need to add fields to models to store content. Hygraph provides content editors different input UI depending on the fields used. You can think of a field as a “column” inside of a database table. These fields can be of many different types, and in GraphQL we call those types “Scalars”.
Hygraph provides many different scalar types for things like Strings, Integers, Dates, Booleans, and even for things like Colors, and Geo coordinates. You can learn about the supported field types inside of the API Reference.
All fields added to your content models provide ways to modify how they're used. You can set fields to be a list, to be localized, to be used in a list, to be marked as required, or unique, as well as a bunch of other combinations.
We recommend reading the API Reference for Field Configuration to see which field modifiers are available, and how they are used.
You can think of components similar to a model, but they're embedded within an existing model, and cannot be interacted with as individual entries.
As a content editor, you may wish to add components to structure data for things like a page “Hero”, or layout “Blocks”. You wouldn't query a Hero or Block on its own, but only fetch its content when you interact with the parent model.
Enums are a special kind of type that we can use to enumerate all possible values in a field. GraphQL enums give us schema level validation by their pure existence.
You would typically use enumerations outside of content, but for things that power a content UI. For example, you may wish to store the possible values that users can “Filter by”. These values could be NAME_ASC, PRICE_ASC, PRICE_DESC, etc.
When working with a system that manages content, there are many things that the system needs to monitor to operate. Hygraph automatically provides some system models, and fields for projects.
Content comes in many different formats, and we refer to “assets” as things you upload that are audio files, images, videos, and PDFs.
Hygraph automatically provides a “transformation API” for images that you can use to alter the output of any uploaded images. A typical transformation is cropping, and moving the focal point.
Any user of your Hygraph project is referred to as a “User”. These are managed automatically, and automatically relate to any content or asset uploaded so you can clearly identify who created, updated, or published content.
Users are also connected to models at an API level, so you can fetch the users name, avatar, and more when fetching content.
Hygraph automatically handles fields that you don't need to. This includes fields for a document's unique ID, and the timestamps for when content was created, updated, published, and the user model connection mentioned above.