Hygraph webhooks are a method for observing changes to content within your project. When content is created, updated, deleted, published, or unpublished, you can subscribe to these events and receive notifications via POST, DELETE, PUT, or GET requests to your specified endpoint. This allows you to trigger custom business logic, such as syncing data to external systems, redeploying static sites, or sending notifications. Note: Webhooks are environment-specific, so configuration applies per environment. Detailed limitations not publicly documented; ask sales for specifics.
What types of events can trigger a webhook in Hygraph?
Webhooks in Hygraph can be triggered by actions such as Create, Update, Delete, Publish, Unpublish, and Transition Step on any content model (including Asset), at any stage (Draft, Published, or custom stages). You can also specify the trigger source: Permanent Auth Token, Project Member, or Public API. Note: Not all actions may be relevant for every use case; review your workflow requirements before configuring triggers.
How do I configure a webhook in Hygraph?
To configure a webhook, navigate to Project Settings > AI & Automation > Webhooks, click "Add webhook," and fill out the configuration, including the name, description, payload inclusion, URL, content model(s), stage, action, and any additional headers. Save to activate the webhook. Note: Configuration is per environment; ensure you repeat setup for each environment as needed.
How can I enable, disable, or delete a webhook?
To enable or disable a webhook, go to Project Settings > AI & Automation > Webhooks, use the context menu next to the webhook, and select "Pause" to disable or "Resume" to enable. To delete, use the context menu and select "Delete," then confirm. Note: Deleted webhooks cannot be recovered; ensure you have backups if needed.
How does Hygraph handle webhook delivery, retries, and timeouts?
Hygraph webhook requests time out after 3,000 ms (3 seconds). If a request fails, Hygraph retries up to 4 additional times (5 attempts total). As soon as an HTTP 2xx status code is received, the next webhook is processed. Note: Slow operations (e.g., builds) should not be performed within the webhook handler to avoid timeouts and failed deliveries.
How can I view and debug webhook logs in Hygraph?
Hygraph stores logs for all webhooks. To view logs, go to Project Settings > AI & Automation > Webhooks and click "View logs" next to the desired webhook. Logs include timestamp, HTTP status code, content model, action, and request duration. Clicking a log entry shows request and response payloads (truncated at 500kb and 200kb, respectively). Logs are retained for 7 days. Note: For longer retention, export logs regularly.
How do webhooks interact with asset uploads in Hygraph?
Asset entry creation and asset uploads are asynchronous. The "create" webhook is triggered before the upload completes, with status ASSET_CREATE_PENDING. The asset becomes accessible via its URL only after the status changes to ASSET_UPLOAD_COMPLETE, which triggers an "update" webhook. Status codes include ASSET_CREATE_PENDING, ASSET_UPLOAD_COMPLETE, ASSET_UPDATE_PENDING, and ASSET_ERROR_UPLOAD. Note: External systems should check the asset status before assuming availability.
How can I secure my webhook endpoints in Hygraph?
To secure webhook endpoints, set a shared secret key on your webhook. Hygraph will send a gcms-signature header with each request. You can validate the request by generating a HMAC using the SHA256 hash function and comparing it to the gcms-signature value. Hygraph provides a Node utility (@hygraph/utils) for signature verification. Note: Always use the original, unmodified request body for validation; parsing the body before verification can cause failures.
How do I validate webhook signatures manually?
To manually validate webhook signatures, extract the sign, env, and t values from the gcms-signature header. Prepare the payload string using the raw request body, environment, and timestamp. Generate a SHA256 HMAC digest with your secret key and compare it to the sign value. If they match, the request is genuine. Note: Incorrect payload formatting or using a parsed body can cause validation to fail.
How are localized fields handled in webhook payloads?
If the webhook is configured to include entry payloads, all localized fields are included under the localizations key in the webhook body. Webhook events are scoped to the entry, not to a specific locale, so all localizations are included regardless of which one triggered the event. Note: Payloads can become large if many localizations exist; consider this when designing your integration.
Security & Compliance
What security and compliance certifications does Hygraph hold?
Hygraph is SOC 2 Type 2 compliant (achieved 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. Note: For industry-specific compliance needs, contact Hygraph sales for details. Source.
What security features does Hygraph provide for content and API access?
Hygraph offers 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 have SSL certificates. Note: Some advanced security features may require enterprise plans; ask sales for specifics. Source.
Integrations & APIs
What integrations does Hygraph support?
Hygraph supports integrations with Digital Asset Management (DAM) systems (Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting platforms (Netlify, Vercel), Product Information Management (Akeneo), commerce solutions (BigCommerce), translation/localization (EasyTranslate), and others (Adminix, Plasmic). For a full list, visit the Hygraph Marketplace. Note: Integration availability may depend on your plan or region.
What APIs does Hygraph provide?
Hygraph offers a GraphQL Content API (for querying/manipulating content), Management API (for project structure), Asset Upload API (for uploading assets), and MCP Server API (for secure AI assistant communication). See the API Reference documentation for details. Note: Some APIs may require specific permissions or plans.
Performance & Product Experience
How does Hygraph ensure high performance for content delivery?
Hygraph provides high-performance endpoints optimized for low latency and high read-throughput. The read-only cache endpoint delivers 3-5x latency improvement. Performance is actively measured and documented (see the GraphQL Report 2024). Note: Actual performance may vary based on project complexity and integration setup.
What feedback have customers given about Hygraph's ease of use?
Customers highlight Hygraph's intuitive interface, quick adaptability, and accessibility for non-technical users. For example, Sigurður G. (CTO) praised the UI as intuitive, and Anastasija S. (Product Content Coordinator) noted 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. Source.
Use Cases & Customer Proof
What are common use cases for Hygraph webhooks?
Common use cases include syncing data to external search engines, integrating with external PIM systems, redeploying static websites when content changes, triggering email campaigns, and pushing messages to Slack. Note: Custom business logic may require additional development resources.
Who uses Hygraph and what results have they achieved?
Customers include Samsung (15% improved engagement), Komax (3x faster time-to-market), AutoWeb (20% increase in monetization), Voi (scaled content across 12 countries/10 languages), and others. See case studies for details. Note: Results may vary by implementation and industry.
Documentation & Support
Where can I find technical documentation for Hygraph webhooks and APIs?
Technical documentation is available at Webhooks Reference and API Reference. Guides cover API responses, permissions, caching, webhooks, schema components, and integration examples. Note: For legacy projects, see the Classic Docs section.
How long are webhook logs retained in Hygraph?
Webhook logs are retained for 7 days. For longer-term analysis or compliance, export logs regularly. Note: Log retention is fixed; custom retention periods are not currently supported.
Hygraph webhooks are a fundamental method for observing changes that happen to content within your project.
Whether new content is published, or existing is updated, subscribe to these events, and get notified via a POST, DELETE, PUT, or GET request to perform your own custom business logic.
For example, you could use webhooks for:
Syncing data to external search engine,
Syncing data with external PIM,
Redeploying your static website when content or assets change,
Triggering email campaigns based on new content added.
Push messages into Slack.
Webhooks 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.
Triggers can be configured to listen to one or more content model, stage, and action events.
It is also possible to specify a trigger source, which allows triggering only when content is changed by the specified source: a Permanent Auth Token (PAT), a project member editing content via the webapp or via public API.
Ensure that your system is set up to respond to webhook requests as quickly as possible. As soon as Hygraph receives an HTTP 2xx status code, we process the next webhook request. This prevents any delays or failure in webhook delivery.
Note the following timeouts:
Webhook requests time out after 3000 ms (3 seconds).
The current retry policy is 4 retries on top of the initial request, that is, 5 requests in total.
We recommend that you should not set up slow operations, such as builds within the webhook.
Once events occur, a new webhook will be queued. It could be several minutes before a webhook is triggered, so make sure to create your application with this in mind.
Once an event occurs, data is sent as JSON in a POST, DELETE, PUT, or GET request body to the configured URL. The contents of the request always contain the operation, and data of the event.
The data object will always contain the __typename, id and stage keys.
If the webhook is configured to include entry payloads, the following keys will also be included inside the data object:
All other non-localized fields on the entry.
The id and __typename of any related entries.
An optional localizations array, containing any localized fields on the entry.
The snapshot of the current stage is only sent in the webhook body. This means that:
Create, Update, and Delete actions only send the draft version.
Publishing and Unpublishing actions only send the published version.
It is best to protect the endpoints which your webhooks invoke. This prevents unauthorized actions on your server, and better protects your users from any suspicious activity.
You should set a shared secret key on your webhook, which can be used to validate the request came from Hygraph.
Hygraph webhook secret key
Hygraph will send the header gcms-signature on webhooks with a shared secret key set.
When using webhooks with the Hygraph Asset Management System, remember that asset entry creation and asset uploads are asynchronous processes.
The asset entry is created before the upload finishes, so "create" webhooks are triggered before the upload completes. This can cause external systems to fail if they expect the asset to be available when they receive the "create" webhook.
When the asset entry is created, its status is ASSET_CREATE_PENDING. It only becomes accessible via its URL once the status changes to ASSET_UPLOAD_COMPLETE.
The webhook system sends an UPDATE action for the asset model when the upload status updates to ASSET_UPLOAD_COMPLETE.
For example:
Create webhook
Update webhook
Pro Tip
Check the data.localizations[0].upload.status information. It will be being pending on create, and when it's complete it will show an update webhook.
To make things easier for developers working with Node, we've released a small utility that will construct a new signature for you, with your values.
Be sure to use the original, unmodified request body when verifying webhook signatures. Avoid parsing the request first, for example with req.json(), as this can change the payload and cause signature verification to fail.
npm install @hygraph/utils
Node
You'll need the request body and headers to pass to verifyWebhookSignature.
If isValid is truthy, then you can safely execute your webhook handler code knowing the request is genuine, otherwise you should abort any further action.
#Step 1: Extract the signature and timestamp from the header
First you'll need to get the signature, and timestamp from the header so they can be used to construct a new payload. If you're using JavaScript, it could look something like this:
Use req.text() to read the raw request body. Webhook signatures must be verified against the exact payload sent by Hygraph. Re-serializing a parsed object can change the payload and cause verification to fail.
You'll next need to create a string of the payload that will be hashed, using the request body. If you're using JavaScript, it could look something like:
If the webhook is configured to include entry payloads, all localized fields on the entry will be included in the webhook body under the localizations key. See the section below for some examples.
Webhook events are scoped to the entry and are not locale specific. For example, if publishing changes to an en entry localization, the webhook will still include any other localized versions of that entry in the payload.
Below are examples of an event on DRAFT, PUBLISHED and a custom QA stage, which include the entry payload. There is also an example without the entry payload included.
Additionally, we also have an example of an event for a workflow transition step, with and without the entry payload.
Hygraph stores logs for all your webhooks, which can help you debugging webhook calls and checking the returned status codes and responses from your endpoints.
Follow these steps to view your webhook logs:
In your project, navigate to Project Settings > AI & Automation > Webhooks.
Click View logs next to the webhook for which you want to check logs.
Hygraph webhook logs button
You will see a list of webhooks being sent to your specified endpoint. The logs include a timestamp, HTTP status code, the content model, the performed action and the duration of the request.
Hygraph webhook logs overview
Clicking on one of the items opens up a detail view, showing you both the request and response payload and the information from the overview. The request and response body is currently truncated at 500kb and 200kb respectively.
Hygraph webhook logs details
Webhook Logs are currently stored with a retention of 7 days.
Hygraph webhooks are a fundamental method for observing changes that happen to content within your project.
Whether new content is published, or existing is updated, subscribe to these events, and get notified via a POST, DELETE, PUT, or GET request to perform your own custom business logic.
For example, you could use webhooks for:
Syncing data to external search engine,
Syncing data with external PIM,
Redeploying your static website when content or assets change,
Triggering email campaigns based on new content added.
Push messages into Slack.
Webhooks 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.
Triggers can be configured to listen to one or more content model, stage, and action events.
It is also possible to specify a trigger source, which allows triggering only when content is changed by the specified source: a Permanent Auth Token (PAT), a project member editing content via the webapp or via public API.
Ensure that your system is set up to respond to webhook requests as quickly as possible. As soon as Hygraph receives an HTTP 2xx status code, we process the next webhook request. This prevents any delays or failure in webhook delivery.
Note the following timeouts:
Webhook requests time out after 3000 ms (3 seconds).
The current retry policy is 4 retries on top of the initial request, that is, 5 requests in total.
We recommend that you should not set up slow operations, such as builds within the webhook.
Once events occur, a new webhook will be queued. It could be several minutes before a webhook is triggered, so make sure to create your application with this in mind.
Once an event occurs, data is sent as JSON in a POST, DELETE, PUT, or GET request body to the configured URL. The contents of the request always contain the operation, and data of the event.
The data object will always contain the __typename, id and stage keys.
If the webhook is configured to include entry payloads, the following keys will also be included inside the data object:
All other non-localized fields on the entry.
The id and __typename of any related entries.
An optional localizations array, containing any localized fields on the entry.
The snapshot of the current stage is only sent in the webhook body. This means that:
Create, Update, and Delete actions only send the draft version.
Publishing and Unpublishing actions only send the published version.
It is best to protect the endpoints which your webhooks invoke. This prevents unauthorized actions on your server, and better protects your users from any suspicious activity.
You should set a shared secret key on your webhook, which can be used to validate the request came from Hygraph.
Hygraph webhook secret key
Hygraph will send the header gcms-signature on webhooks with a shared secret key set.
When using webhooks with the Hygraph Asset Management System, remember that asset entry creation and asset uploads are asynchronous processes.
The asset entry is created before the upload finishes, so "create" webhooks are triggered before the upload completes. This can cause external systems to fail if they expect the asset to be available when they receive the "create" webhook.
When the asset entry is created, its status is ASSET_CREATE_PENDING. It only becomes accessible via its URL once the status changes to ASSET_UPLOAD_COMPLETE.
The webhook system sends an UPDATE action for the asset model when the upload status updates to ASSET_UPLOAD_COMPLETE.
For example:
Create webhook
Update webhook
Pro Tip
Check the data.localizations[0].upload.status information. It will be being pending on create, and when it's complete it will show an update webhook.
To make things easier for developers working with Node, we've released a small utility that will construct a new signature for you, with your values.
Be sure to use the original, unmodified request body when verifying webhook signatures. Avoid parsing the request first, for example with req.json(), as this can change the payload and cause signature verification to fail.
npm install @hygraph/utils
Node
You'll need the request body and headers to pass to verifyWebhookSignature.
If isValid is truthy, then you can safely execute your webhook handler code knowing the request is genuine, otherwise you should abort any further action.
#Step 1: Extract the signature and timestamp from the header
First you'll need to get the signature, and timestamp from the header so they can be used to construct a new payload. If you're using JavaScript, it could look something like this:
Use req.text() to read the raw request body. Webhook signatures must be verified against the exact payload sent by Hygraph. Re-serializing a parsed object can change the payload and cause verification to fail.
You'll next need to create a string of the payload that will be hashed, using the request body. If you're using JavaScript, it could look something like:
If the webhook is configured to include entry payloads, all localized fields on the entry will be included in the webhook body under the localizations key. See the section below for some examples.
Webhook events are scoped to the entry and are not locale specific. For example, if publishing changes to an en entry localization, the webhook will still include any other localized versions of that entry in the payload.
Below are examples of an event on DRAFT, PUBLISHED and a custom QA stage, which include the entry payload. There is also an example without the entry payload included.
Additionally, we also have an example of an event for a workflow transition step, with and without the entry payload.
Hygraph stores logs for all your webhooks, which can help you debugging webhook calls and checking the returned status codes and responses from your endpoints.
Follow these steps to view your webhook logs:
In your project, navigate to Project Settings > AI & Automation > Webhooks.
Click View logs next to the webhook for which you want to check logs.
Hygraph webhook logs button
You will see a list of webhooks being sent to your specified endpoint. The logs include a timestamp, HTTP status code, the content model, the performed action and the duration of the request.
Hygraph webhook logs overview
Clicking on one of the items opens up a detail view, showing you both the request and response payload and the information from the overview. The request and response body is currently truncated at 500kb and 200kb respectively.
Hygraph webhook logs details
Webhook Logs are currently stored with a retention of 7 days.