Select theme:
Standard Webhooks allow Enquete to automatically send survey-related information to another application when a selected event occurs.
For example, when a respondent submits or completes a survey, Enquete can send the event data directly to your customer relationship management system, reporting platform, internal database, support application, marketing platform, or another external service.
This helps your organisation automate workflows and move survey data between systems without repeatedly exporting responses or transferring information manually.
This guide explains how to create, configure, test, monitor, and manage Standard Webhooks from the Enquete interface.
Important:
Standard Webhooks are intended for organisations with access to a developer or technical team. Your receiving application must provide a publicly accessible HTTPS endpoint that can receive HTTP POST requests.
For the complete technical reference, including supported payloads, webhook headers, signature verification, event schemas, and implementation details, see the official Enquete Webhook Documentation.
A Standard Webhook is an automated connection between Enquete and an external application.
When an event occurs in a selected survey, Enquete sends an HTTP POST request to the endpoint URL configured in the webhook subscription.
Depending on your organisation's workflow, a webhook can be used to:
Each Standard Webhook is connected to a specific survey and event type. This gives you control over which activities trigger a delivery and where the information is sent.
Before setting up a Standard Webhook, make sure your technical team has prepared:
The receiving endpoint should respond quickly after acceptypically be passed to a queue or background processingting a request. Long-running operations should normally be passed to a queue or background-processing system after the endpoint returns a successful response.
Developers should consult the official Webhook Documentation before implementing the receiving endpoint.
From your Enquete dashboard, select Integrations at the top menu
Open Standard Webhooks from the available integration options.
The Standard Webhooks overview displays all webhook subscriptions available in your account.
From this page, you can:
On the Standard Webhooks overview, click Add Webhook.
A configuration form will open.
Enter the HTTPS endpoint where Enquete should send webhook deliveries.
For example:
https://example.com/api/enquete/webhookThe endpoint must be publicly accessible and able to accept HTTP POST requests.
Localhost addresses, private development URLs, and pages that require an interactive login cannot receive webhook deliveries from Enquete.
Enter a description that clearly explains the purpose of the webhook.
For example:
Send completed customer satisfaction responses to our CRMA clear description makes it easier to identify the webhook later, especially when your organisation manages several subscriptions.
Select the survey whose events should trigger the webhook.
A Standard Webhook subscription is connected to one survey. If you need to send events from several surveys, create a separate webhook subscription for each survey.
Select the event that should trigger the webhook delivery.
Events available in the Standard Webhook interface may include:
The available events may depend on the current Enquete configuration and the features enabled for your account.
Choose whether the webhook should be active immediately.
When a webhook is active, Enquete sends deliveries whenever the selected event occurs.
When it is inactive, the configuration remains available, but live event deliveries are paused.
You can keep a webhook inactive while your technical team finishes preparing or testing the receiving endpoint.
Click Save to create the webhook subscription.
The new webhook will appear on the Standard Webhooks overview and can be tested immediately.
Every Standard Webhook has a secret. The receiving application uses this secret to verify that an incoming request genuinely came from Enquete.
The webhook secret should be treated like a password or private API credential.
Locate the webhook on the overview and click the eye icon.
The secret will be shown temporarily.
Click the clipboard icon to copy the secret.
For security, the secret automatically becomes hidden again after approximately ten seconds.
Pass the secret to the developer responsible for the receiving endpoint and store it in a secure server-side location, such as:
Do not store the secret in frontend JavaScript, public repositories, screenshots, shared documents, or support messages accessible to unauthorised users.
You should test every webhook before using it in a live workflow.
A test delivery confirms that the endpoint can be reached and that the receiving server returns an appropriate response.
Find the webhook subscription on the Standard Webhooks overview.
Click the lightning icon on the webhook row.
Enquete will send a test request to the configured endpoint.
An inline notification will display the HTTP status returned by the endpoint.
A successful delivery normally returns a status code in the 200 to 299 range, such as:
If the test fails, open the delivery logs to inspect the response status, response body, error information, and request duration.
You can update an existing webhook when its endpoint, survey, event type, description, or activation status changes.
Locate the webhook and select the Edit action.
You can update settings such as:
Save the webhook after making your changes.
The updated configuration will be used for future deliveries.
Always send another test delivery after changing the endpoint URL, survey, or event type.
The delivery logs show the requests Enquete has sent to your endpoint and the responses returned by the receiving server.
Use these logs to monitor the health of your integration and investigate failed deliveries.
Locate the webhook subscription and click the View logs icon next to the delete button.
You can filter deliveries by:
Expand a delivery entry to review the available diagnostic information.
The delivery record may include:
Delivery logs are particularly useful after:
Each webhook request contains headers that help the receiving application identify, verify, and track the delivery.
| Header | Description |
|---|---|
| X-Enquete-Signature | Contains the signature used to verify that the request came from Enquete. |
| X-Enquete-Event | Identifies the event type that triggered the delivery. |
| X-Enquete-Delivery | Contains a unique delivery identifier used for tracking and duplicate prevention. |
Your technical team should use the signature header to authenticate incoming requests and the delivery header to prevent the same event from being processed more than once.
For the exact signature format, payload schema, and implementation examples, refer to the official Webhook Documentation.
A webhook delivery may be attempted more than once if the first request fails, times out, or does not return a successful response.
This means the receiving application must be able to recognise and safely ignore a delivery that has already been processed.
Every request includes a unique value in the X-Enquete-Delivery header.
Your technical team should use this value as an idempotency key.
A typical duplicate-prevention process is:
Processed delivery IDs should be retained for a period appropriate to your organisation's integration and retry policy.
Deactivate a webhook when you want to stop deliveries temporarily without deleting its configuration.
You may deactivate a webhook while:
When the webhook is activated again, future matching events can be delivered.
Events that occur while the webhook is inactive may not automatically be delivered later.
Delete a webhook when the subscription is no longer required.
Locate the webhook and click the Delete action.
Confirm that you want to permanently remove the webhook subscription.
After deletion, Enquete will no longer send new deliveries for that webhook.
Historical delivery records may remain available in backend records for auditing, troubleshooting, or operational purposes.
Important: If you only want to pause the webhook temporarily, deactivate it instead of deleting it.
Check the following:
Long-running tasks should be queued for background processing instead of being completed before the server returns its response.
Ask your technical team to confirm that:
Signature verification is a technical implementation task. Consult the official Webhook Documentation for the current verification instructions.
Check the following:
A 401 or 403 response normally means the receiving server rejected the request because of an authentication or authorisation rule.
Check whether:
A 404 response usually means the endpoint URL does not match an available route on the receiving server.
Check the complete URL and confirm that the route exists and accepts HTTP POST requests.
A 500 response indicates that an error occurred inside the receiving application.
Your technical team should review the receiving application's server logs together with the delivery payload and delivery identifier shown in Enquete.
Webhook requests may be retried after failures or timeouts.
Your technical team should use the X-Enquete-Delivery value to identify deliveries that have already been processed.
Before using a Standard Webhook in a live workflow, confirm that you have completed the following:
After the webhook goes live, regularly review failed deliveries and endpoint performance to make sure the integration continues to work correctly.
For payload fields, event schemas, signature-verification examples, and other developer-specific instructions, always refer to the official Enquete Webhook Documentation.