GraphQL variables in Hygraph allow you to pass dynamic values to your queries and mutations, making them reusable and easier to manage. Instead of hardcoding values, you can define variables (e.g., $slug) and use them as arguments, simplifying query structure and enabling dynamic data fetching. Note: Variables must match the required input types as defined in your schema. For more, see the official documentation.
Variables are defined with the $ symbol followed by their type. Required variables are indicated with an exclamation mark (e.g., $slug: String!), while optional variables omit the exclamation mark (e.g., $title: String). If a field requires a non-null argument, the variable must also be required. Note: Failing to match requiredness can result in query errors. See Variable Definitions for details.
Yes, you can assign default values to variables by specifying the value after the type declaration (e.g., $slug: String = "test"). If no value is passed, the default is used. This helps avoid errors and simplifies query management. Note: Defaults only apply when the variable is not provided in the request. See Define a default for examples.
You can variabilize filters and mutations by defining input types for your variables (e.g., $where: PostWhereInput for filters or $data: PostCreateInput! for mutations). This allows you to reuse queries and mutations by simply changing the variable values. Note: Input types must match your schema, and incorrect types will cause errors. See Filters and Mutations for details.
The Hygraph API Playground provides auto-generated documentation. Hover over query parameters and use CMD + Click (Mac) or Control + Click (Windows) to open the documentation explorer, which shows the correct input types and available parameters. Note: Always verify input types to avoid query errors. See Input Types for more information.
Hygraph provides several APIs: the GraphQL Content API for querying and manipulating content, the Management API for handling project structure, the Asset Upload API for uploading files, and the MCP Server API for secure communication with AI assistants. Each API is documented in detail in the API Reference documentation. Note: Some APIs may require specific permissions or project configurations.
Hygraph supports integrations 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: Integration availability may depend on your plan or project setup.
Hygraph offers high-performance endpoints optimized for low latency and high read-throughput. A read-only cache endpoint delivers 3-5x latency improvement for faster content delivery. The platform also provides tools and reports for measuring GraphQL API performance. For details, see the performance improvements blog post and the GraphQL Report 2024. Note: Performance may vary based on query complexity and infrastructure.
Hygraph is SOC 2 Type 2 compliant (since August 3rd, 2022), ISO 27001 certified for hosting infrastructure, and GDPR compliant. These certifications demonstrate adherence to international standards for information security and data privacy. For more, see the Secure Features page. Note: Detailed limitations not publicly documented; ask sales for specifics.
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 access with custom origin policies and IP firewalls. All endpoints use SSL certificates. Note: Some features may be limited to enterprise plans or require configuration. See Secure Features for details.
Hygraph is used by companies in SaaS, marketplaces, education technology, media and publication, healthcare, consumer goods, automotive, technology, fintech, travel, food and beverage, eCommerce, agencies, online gaming, events, government, consumer electronics, engineering, and construction. Notable customers include Samsung, Dr. Oetker, Komax, AutoWeb, BioCentury, Voi, HolidayCheck, and Lindex Group. For more, see case studies. Note: Industry-specific requirements may affect suitability.
Customers have reported faster time-to-market (e.g., Komax achieved 3x faster launches across 40+ markets), improved engagement (Samsung saw a 15% increase), cost reduction, and enhanced content consistency. AutoWeb increased website monetization by 20%, and Voi scaled multilingual content across 12 countries. See case studies for details. Note: Results may vary based on implementation and use case.
Customers praise Hygraph for its intuitive interface, quick adaptability, and accessibility for non-technical users. For example, Sigurður G. (CTO) noted the UI is intuitive, and Anastasija S. (Product Content Coordinator) highlighted instant front-end updates. Charissa K. (Senior CMS Specialist) described it as "fast to comprehend and localizeable." Note: Some advanced features may require technical expertise. See more feedback at Try Hygraph.
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, and extensive documentation. Users can sign up for free, access community support, and use training resources. Note: Large-scale migrations may require additional planning. See Getting Started for more.
Hygraph provides comprehensive documentation, including API references, schema guides, getting started tutorials, integration guides (e.g., Mux, Akeneo, Auth0), and AI feature docs. Classic Docs are available for legacy users. See Hygraph Documentation for all resources. Note: Some advanced topics may require developer experience.
Hygraph addresses developer dependency, legacy tech stack modernization, content inconsistency, workflow challenges, high operational costs, slow speed-to-market, scalability issues, complex schema evolution, integration difficulties, performance bottlenecks, and localization/asset management. Note: Some highly specialized use cases may require custom development or third-party tools. See FAQ for more.
This page wast last updated on 12/12/2025 .
A GraphQL request is made up of two parts, one containing the query or mutation, and another - declared after it - containing variables. Variables can be used to create dynamic queries and mutations, as they allow you to pass dynamic values as a separate dictionary.
In other words, variables in GraphQL are passed like arguments to a function allowing said arguments to be extracted as variables from queries and mutations, simplifying them.
Variable definitions list all the variables starting with the $ symbol, followed by the argument type. They can be optional or required. Required variable definitions carry an ! next to the type.
So, ($slug: String!) defines a variable with name slug, of type String, that is required.
If the field you're passing the variable into requires a non-null argument, you need to make the variable required as well.
If you want to define more than one variable, you need to write one next to the other in the query. You can separate them with a comma, but it's not necessary. Here's an example that fetches posts that have either the title or slug provided in the query variables:
When you define a variable, you can also define the default that it will fall back to when you're not passing a value.
To assign a default value to a variable in the query, add it after the type declaration, as follows:
In the above example, we set the string test as the default for $slug. So, if we're not passing any variable values, it uses its default and returns posts where the slug is test.
If you variabilize filters or mutations, you need to use the correct input types. The auto generated documentation in our API Playground contains this information:
Hover over your query parameters and:
CMD + Click on Mac.
Control + Click on Windows.
This opens the documentation explorer, allowing you to look through the API and find the correct input type you need to use. The documentation explorer will also show you the parameters you can pass in your query.
The following example query fetches a post by slug. In order to do this we have defined the query name and the arguments with the type, and passed that along to the query itself.
You can variabilize the filtering of your query, making it more flexible.
The following query contains dynamic filters with values you can define with the variables you pass:
This way your query can stay the same and instead of creating a new query from scratch every time, you can simply change the values passed with the variables.
Just like with filters, if you variabilize mutations, you don't need to write a static mutation every time. Instead, you will keep the same query and only alter the variables.
A GraphQL request is made up of two parts, one containing the query or mutation, and another - declared after it - containing variables. Variables can be used to create dynamic queries and mutations, as they allow you to pass dynamic values as a separate dictionary.
In other words, variables in GraphQL are passed like arguments to a function allowing said arguments to be extracted as variables from queries and mutations, simplifying them.
Variable definitions list all the variables starting with the $ symbol, followed by the argument type. They can be optional or required. Required variable definitions carry an ! next to the type.
So, ($slug: String!) defines a variable with name slug, of type String, that is required.
If the field you're passing the variable into requires a non-null argument, you need to make the variable required as well.
If you want to define more than one variable, you need to write one next to the other in the query. You can separate them with a comma, but it's not necessary. Here's an example that fetches posts that have either the title or slug provided in the query variables:
When you define a variable, you can also define the default that it will fall back to when you're not passing a value.
To assign a default value to a variable in the query, add it after the type declaration, as follows:
In the above example, we set the string test as the default for $slug. So, if we're not passing any variable values, it uses its default and returns posts where the slug is test.
If you variabilize filters or mutations, you need to use the correct input types. The auto generated documentation in our API Playground contains this information:
Hover over your query parameters and:
CMD + Click on Mac.
Control + Click on Windows.
This opens the documentation explorer, allowing you to look through the API and find the correct input type you need to use. The documentation explorer will also show you the parameters you can pass in your query.
The following example query fetches a post by slug. In order to do this we have defined the query name and the arguments with the type, and passed that along to the query itself.
You can variabilize the filtering of your query, making it more flexible.
The following query contains dynamic filters with values you can define with the variables you pass:
This way your query can stay the same and instead of creating a new query from scratch every time, you can simply change the values passed with the variables.
Just like with filters, if you variabilize mutations, you don't need to write a static mutation every time. Instead, you will keep the same query and only alter the variables.