Skip to main content

Node: Webhook Out

The Webhook Out node makes an HTTP call to an external URL during the workflow execution. With it, you can integrate Hashdata with any system that has a REST API — without needing a dedicated native connector. Whenever an instance passes through this node, Hashdata sends a request to the configured address and waits for the response before proceeding to the next step.

This node is the universal bridge between your processes in Hashdata and the outside world: CRMs, ERPs, support systems, e-commerce platforms, internal automations, and any other service that accepts HTTP requests.

When to Use​

The Webhook Out node is suitable in the following situations:

  • Integrate with systems without a native connector: when the service you need to trigger does not have a ready-made integration in Hashdata (like Slack, Google Sheets, or Teams), the webhook allows direct communication via API.
  • Trigger automations in CRM or ERP: upon receiving a form response, you can automatically create a contact in your CRM, open a ticket in the ERP, or update a record in any system with a REST API.
  • Send data in real time: instead of periodic exports, the webhook ensures data reaches the destination system at the exact moment the instance passes through this node.
  • Synchronize systems: keep two systems synchronized by triggering third-party API calls as the flow advances.
  • Notify external platforms: inform monitoring systems, BI platforms, or communication tools about events that occurred within the workflow.

Configuration​

To configure the node, click on it in the workflow editor canvas. The side panel will display the options below.

FieldRequiredDescription
URLYesFull address of the API that will receive the request. Must start with https://. Plain HTTP URLs are not accepted for security reasons.
HTTP MethodYesHTTP verb of the request: GET, POST, PUT, PATCH, or DELETE. Choose according to the destination API documentation.
Content typeOnly for POST and PATCHDefines the format of the request body. Options: JSON (application/json) or URL-encoded form (application/x-www-form-urlencoded). Check the destination API documentation to know which format it expects.
HeadersNoKey-value pairs sent in the request header. Use for authentication (e.g., Authorization: Bearer YOUR_TOKEN) or for API-specific instructions (e.g., Content-Type, Accept, x-api-key).
URL parametersNoQuery string parameters automatically added to the end of the URL. For example, adding the key status with value active will result in ?status=active in the final URL.
Body structureYesSimple (customizable fields): in this option the user can choose which information they want to send to the external system.
Full Response: in this option the system will send all available information from a form, that is, the user does not need to choose one by one.
Only HTTPS is accepted

Hashdata rejects URLs that use plain HTTP. Make sure the destination API has a valid SSL certificate and that the URL starts with https://. This restriction exists to protect sensitive data that travels between Hashdata and external systems.

Node Outputs​

The Webhook Out node has two outputs on the canvas, and you must connect each one to the appropriate handling:

  • Success: triggered when the API responds with an HTTP code in the 2xx range (200, 201, 204, etc.). Indicates that the call was made and accepted by the destination system. The flow continues normally through this output.
  • Error: triggered when the API responds with an HTTP code outside the 2xx range (e.g., 400, 401, 403, 404, 500) or when a network failure occurs (timeout, unreachable host, DNS error). Use this output to handle failures — for example, sending an email notification or triggering an alternative flow.

Connecting both outputs is considered best practice. If the Error output is left disconnected, instances that fail at this node may get stuck or end without adequate handling.

Authentication​

Most APIs require some form of authentication to accept external requests. The Webhook Out node supports the most common mechanisms through Headers:

Bearer Token (OAuth 2.0 / JWT)​

Add a header with the key Authorization and the value Bearer YOUR_TOKEN_HERE. Replace YOUR_TOKEN_HERE with the access token provided by the destination API.

API Key in Header​

Many APIs use an API key transmitted in a specific header. Check the API documentation to find the correct header name — common examples are x-api-key, api-key, or X-Auth-Token. Add the corresponding key-value pair in the node's headers section.

API Key in URL​

Some APIs accept the API key as a URL parameter. In this case, use the URL Parameters section to add the key-value pair, keeping the key out of the main URL field for easier maintenance.

Never include tokens directly in the URL

Avoid embedding credentials, tokens, or API keys directly in the URL field (like https://api.example.com?token=MY_KEY). URLs can be recorded in access logs and inadvertently exposed. Always use the Headers or POST Body field for sensitive information, and prefer headers for authentication.

Security​

When configuring the Webhook Out node, follow these best practices to ensure the security of your integrations:

  1. Use only HTTPS: ensure the destination API supports secure connections. Hashdata blocks calls to HTTP URLs.
  2. Keep tokens in headers: credentials and API keys should always be in the Headers field, never in the URL or in the request body in plain text.
  3. Revoke unused tokens: if a workflow is deactivated or the integration is no longer needed, revoke the access token in the destination system.
  4. Prefer limited-scope tokens: when generating credentials for the webhook, grant only the permissions strictly necessary for the operation the node performs.
  5. Monitor the Error output: monitor instances that pass through the Error output to detect calls with expired credentials or unavailable APIs.

Timeout and Failure Handling​

10-second timeout

Hashdata waits at most 10 seconds for the response from the destination API. If the API takes longer than that to respond, the call is terminated and the instance follows through the Error output. Slow, overloaded, or geographically distant APIs may cause frequent timeouts. In that case, check the performance of the destination API or consider using an asynchronous queue in the receiving system.

To handle failures robustly in your workflow:

  1. Connect the Error output to a Send Email node to notify responsible parties about the failure.
  2. Use a Set Status node to record that the instance is awaiting manual intervention.
  3. Consider adding an Approval node on the error output, allowing an administrator to decide how to proceed.

Usage Examples​

  • Create lead in CRM: when receiving a form response of interest, trigger a POST to the CRM API with the respondent's data and record the created lead ID via full-response mode.
  • Open ticket in support system: when an approval is completed with a negative result, send the details to the support system API for automatic ticket opening.
  • Notify logistics system: when receiving an order via form, trigger the logistics system API to start product picking.
  • Sync with ERP: after a budget approval, send the approved data to the ERP API and use the generated document number in the next workflow nodes.