What is filtering in Hygraph and how does it work?
Filtering in Hygraph allows you to retrieve specific content entries from your models by applying conditions to fields. Filters are automatically created for each type you add to your content models and can be applied to single or multiple entries, including nested object fields. You can explore all available filters using the API Playground. (Source: Filtering Overview)
How do I use filters in Hygraph queries?
To use filters, pass the where argument to your GraphQL query, followed by the desired filter types for your model's fields. For example, to filter posts by author or status, you would use where: { author: "John", status: "PUBLISHED" }. The API Playground provides an interactive way to see which filters are available for your schema. (Source: Using filters)
What field types can be filtered in Hygraph?
You can filter by a wide range of field types, including ID, String, Integer, Float, Boolean, Date, DateTime, References, Components, Enumerations, Taxonomies, and Assets. Each field type supports specific filter operations, such as _in, _not, _contains, _lt, _gt, and more. For a full list, see the Filter types documentation.
Are there any limitations to filtering in Hygraph?
Yes, Hygraph does not currently support filtering for Rich Text fields (even inside components), JSON fields (except with specific JSON filters), multi-value fields, colors, or coordinates. (Source: Using filters)
How can I filter JSON fields in Hygraph?
You can filter JSON fields using value_recursive for exact value matches or json_path_exists for advanced queries using PostgreSQL JSON path syntax. This allows you to filter by value, string, null, or range within your JSON data. See JSON filtering documentation for examples and syntax.
Can I combine multiple filters in a single query?
Yes, you can combine multiple filters using logical operators such as AND, OR, and NOT. This enables you to build complex queries that match multiple conditions. Filters can also be nested for advanced use cases. (Source: Conditional filters)
How do I filter by locales or content stages?
You can filter content entries by locales to retrieve localized content, and by stage to specify which document variation (e.g., DRAFT, PUBLISHED, QA) you want to query. The stage argument determines which version of the document is returned. For more, see Filter by locales and Filter by stage argument.
Features & Capabilities
What are the key features of Hygraph?
Hygraph offers a GraphQL-native architecture, content federation, scalability, and a wide range of integrations. It supports advanced filtering, localization, content staging, and JSON field filtering. Hygraph also provides robust security, compliance, and an intuitive user interface for both technical and non-technical users. (Source: Hygraph Features)
What integrations does Hygraph support?
Hygraph integrates with platforms such as Netlify, Vercel, BigCommerce, commercetools, Shopify, Lokalise, Crowdin, EasyTranslate, Smartling, Aprimo, AWS S3, Bynder, Cloudinary, Mux, Scaleflex Filerobot, Ninetailed, AltText.ai, Adminix, and Plasmic. For a full list, visit the Hygraph Integrations page.
Does Hygraph provide an API for content management?
Yes, Hygraph provides a powerful GraphQL API for fetching and managing content efficiently. You can learn more at the Hygraph API Reference.
What documentation and resources are available for developers?
Hygraph offers comprehensive technical documentation, including guides on filtering, querying, schema design, and API usage. The documentation is regularly updated based on user feedback and includes API references, onboarding guides, and video tutorials. Access the docs at Hygraph Documentation.
Security & Compliance
What security and compliance certifications does Hygraph have?
Hygraph is SOC 2 Type 2 compliant, ISO 27001 certified, and GDPR compliant. These certifications ensure enterprise-grade security and data protection for users. For more details, visit the Hygraph Security Features page.
What security features does Hygraph offer?
Hygraph provides SSO integrations, audit logs, encryption at rest and in transit, and sandbox environments to protect sensitive data and meet regulatory standards. (Source: Hygraph Security Features)
Pricing & Plans
What is Hygraph's pricing model?
Hygraph offers a free forever Hobby plan, a Growth plan starting at $199/month, and custom Enterprise plans. For detailed pricing and feature breakdowns, visit the Hygraph Pricing page. (Source: Pricing)
Use Cases & Customer Success
Who can benefit from using Hygraph?
Hygraph is ideal for developers, IT decision-makers, content creators, project/program managers, agencies, solution partners, and technology partners. It is especially valuable for modern software companies, enterprises modernizing their tech stack, and brands scaling across geographies or re-platforming from traditional solutions. (Source: ICPVersion2_Hailey.pdf)
What industries use Hygraph?
Hygraph is used across industries such as food and beverage, consumer electronics, automotive, healthcare, travel and hospitality, media and publishing, eCommerce, SaaS, marketplace, education technology, and wellness and fitness. (Source: Case Studies)
Can you share some customer success stories with Hygraph?
Yes. Komax achieved a 3X faster time to market, Autoweb saw a 20% increase in website monetization, Samsung improved customer engagement with a scalable platform, and Dr. Oetker enhanced their digital experience using MACH architecture. More stories are available on the Hygraph product page. (Source: Customer Stories)
Support & Getting Started
How easy is it to get started with Hygraph?
Hygraph is designed for quick onboarding, even for non-technical users. You can sign up for a free account and use documentation, video tutorials, and onboarding guides to get started. For example, Top Villas launched a new project in just 2 months. (Source: Hygraph Documentation, Top Villas Case Study)
What support is available after purchasing Hygraph?
Hygraph offers 24/7 support via chat, email, and phone. Enterprise customers receive dedicated onboarding and expert guidance. All users have access to documentation, video tutorials, and a community Slack channel. (Source: Hygraph Contact Page)
Performance & Business Impact
How does Hygraph optimize content delivery performance?
Hygraph is optimized for rapid content delivery, which improves user experience, engagement, and search engine rankings. Fast content distribution reduces bounce rates and increases conversions. (Source: Performance Checklist)
Customer Feedback & Ease of Use
What do customers say about Hygraph's ease of use?
Customers praise Hygraph for its intuitive and logical interface, noting that it is 'super easy to set up and use' and accessible for both technical and non-technical users. (Source: Customer Feedback)
Product Differentiation & Competition
How does Hygraph differentiate itself from other CMS platforms?
Hygraph stands out with its GraphQL-native architecture, content federation, scalability, and ease of use. It addresses operational, financial, and technical pain points by empowering non-technical users, modernizing tech stacks, supporting global teams, and reducing costs. (Source: Product Page)
Hygraph automatically creates filters for types you add to your content models. These filters can be applied to a single, or multiple entries, and nested object fields.
The best place to explore all available filters is by using the API Playground.
To filter content entries, simply pass the where argument to the query, followed by any of the filter types for the fields on your model.
Pro Tip
All models come with their own custom GraphQL input type. Depending on the field type you want to filter by, there will be different fields you can filter by. String fields will behavior differently to Boolean fields for example.
Array fields only have contains_all, contains_none, contains_some filters available.
Check out the API Playground to see what types the where filter accepts for the fields in your schema.
For example, a Post model will have the where input types PostWhereInput and PostWhereUniqueInput on the posts, and postsConnection query types. These types contain filters specific to that content type.
Hygraph does not currently support filtering for Rich Text - even if inside components -, JSON, multi-value fields, colors, or coordinates.
All relations (except Unions) can be filtered using filters on the fields of the model you are referencing. You can filter where every, some, and none at all match the conditions provided.
Matches
Behavior
[fieldName]_every
Every reference matches
[fieldName]_some
Some references match
[fieldName]_none
No references match
For example, you could fetch every post by the provided author name.
All basic component fields that allow multiple values can be filtered using:
Matches
Behaviour
[fieldName]_every
Every reference matches
[fieldName]_some
Some references match
[fieldName]_none
No references match
_every
_some
_none
#Basic component field doesn't allow multiple values
If the basic component field does not allow multiple values, the _every, _some, and _none filters are unavailable, but you can query for a match as well as for empty components.
When querying content entries, you can also filter by stage. The stage argument decides what document variation gets returned and searched through. Therefore, if the document does not exist in the stage variation, it gets filtered out.
Stages work a bit differently in the API than in the UI. In the UI, we use the most intuitive and editor-friendly way of treating filters. So, for instance, if you see a green PUBLISHED pill next to an entry, then this entry is only in the PUBLISHED stage. However, in the backend, our stages are organized slightly differently. The main difference is that each content entry always exists in DRAFT, and other stages are added or removed. For example, an entry that has a green PUBLISHED pill in the UI is actually in both DRAFT and PUBLISHED stages on the API side, and both versions of the entry are identical. If you update the DRAFT version but don't publish it, the entry will continue to exist in both stages, but will be marked as blue PUBLISHED in the UI.
Stages can be filtered using:
Matches
Behavior
documentInStages_every
All existing stage variations must match the sub-filter
documentInStages_some
At least one of the existing stage variations must match the sub-filter
documentInStages_none
None of the existing stage variations are allowed to match the sub-filter
To summarize, like we mentioned before, a document will always exist in the DRAFT stage, and they may or may not exist in other published stages such as PUBLISHED or for example QA - which is a custom content stage that can be published to.
If you, as a user, want to find documents that exist in the PUBLISHED stage, you can run the following query:
stage:DRAFT
where:{
documentInStages_some:{
stage:PUBLISHED
}
}
The above documentInStages_some allows the user to find documents which exist in a different stage. Let's consider the following 3 documents, which exist in the following stages:
ID
STAGES
cldocument1
[DRAFT, PUBLISHED]
cldocument2
[DRAFT]
cldocument4
[DRAFT, PUBLISHED, QA]
The above query will return documents that also exist in the PUBLISHED stage, which are cldocument1 and cldocument4.
However you may have noticed that cldocument4 also has been published to the QA stage - If you have access to custom stages.
Imagine you want to query documents which exist only in one published stage PUBLISHED, but not any other publishable stages. In this case the result you want is cldocument1. For this we can use documentInStages_every.
Keeping in mind that a document entry can exist in multiple stages, the difference between documentInStages_some and documentInStages_every is that documentInStages_some checks if an entry exists in a particular stage, whereas by using documentInStages_every we request an entry that exists in only and exactly that stage. So if we use documentInStages_every with PUBLISHED the query will return results only if the document exists in PUBLISHED and no other stage.
You might read this and try a query such as the following:
where:{
documentInStages_every:{
stage:PUBLISHED
}
}
While you are on the right track, this will unfortunately return no results. The reason is that, as we mentioned earlier, every document always exists in DRAFT, so no document will ever only exist in PUBLISHED.
If you try changing the above PUBLISHED to DRAFT, however, you will get cldocument2 as a result, as this document only exists in the DRAFT stage.
As a workaround for this problem, we can use the OR meta filter, by using the following query:
where:{
documentInStages_every:{
OR:[
{
stage:DRAFT
},
{
stage:PUBLISHED
}
]
}
}
Since the internal query is that the stage must exist either in DRAFT or PUBLISHED, the query evaluates to true for both document cldocument1 and cldocument2. It skips cldocument4, which is what we want, but we still get cldocument2 which exists only in DRAFT.
We can use the same pattern of using meta filters to filter out the DRAFT entry. Let's start by writing this query:
where:{
NOT:[
{
documentInStages_every:{
stage:DRAFT
}
}
]
}
As you can see, this query returns any document that does not exist only in DRAFT, Which in this case would be cldocument1 and cldocument4. If we were to do an intersection of the results of the above two queries, we would get cldocument1, which is the document that we want.
In order to do this, we combine the above two queries to create the following:
where:{
AND:[
{
documentInStages_every:{
OR:[
{
stage:DRAFT
},
{
stage:PUBLISHED
}
]
}
},
{
NOT:[
{
documentInStages_every:{
stage:DRAFT
}
}
]
}
]
}
As you can see above, by using the AND meta filter we get the intersection between the two queries above, which returns the cldocument1 document.
compareWithParent
compareWithParent allows the comparison of a document with its parent entry using any comparison operators available within it.
At the moment compareWithParent is available only inside a documentInStages_* filter, and only allows the use of one attribute which is outdated_to. This attribute can be found inside the compareWithParent filter. The attribute is used to specify if we wish to check whether the child document is outdated compared to the parent document. For example:
variousDocuments(
stage:DRAFT
where:{
documentInStages_some:{
stage:PUBLISHED
compareWithParent:{
outdated_to:true
}
}
}
)
In the above example, we enable the filter by setting outdated_to to true - if it were set to false, it would be the same as having the filter omitted entirely. The true and false values are simply indicators of whether to process the filter in the query.
In the above query, we check if the child PUBLISHED version is outdated compared to the DRAFT parent version. At the moment, we check if a document is outdated by comparing the updatedAt attributes of both the DRAFT and PUBLISHED versions. If the DRAFT has a greater updatedAt, that means the document has been modified since it was last published, and is therefore considered outdated.
You can filter the data in your JSON fields by using json_path_exists syntax from PostgreSQL.
To be able to query this content, you need to know the JSON structure to navigate through it.
If you're not familiar with the structure, you can query for all content - without passing a filter, or with just a pagination filter depending on number of entries - and look into it. A great way to go about this kind of exploration is using the API Playground, where you can type “json” then use ctrl + space or command + space to display all the filters you can use and select one.
Please note that if the content data is in a JSON field that allows multiple values, the query will return the complete list.
Please note that in the query examples below, we escape the quotes with a backslash, like this \”. This is because the query is already inside double quotes, so any additional quotes require this format.
Query by quantity
You can use "$[*].** ? (@ > N)” to filter all values all for integers above a certain number. Just replace N with the number of your choice.