Trigger Webhook Node
Updated
The Trigger Webhook node is used to send an HTTP request from an Integration Flow to an external application, API, or service endpoint. It allows the flow to push data to third-party systems, trigger external processes, update records, invoke APIs, or exchange information with other platforms, making it one of the primary ways a workflow can reach outward and act on systems outside of Sprinklr.
How It Works
When the workflow reaches this node, it constructs an HTTP request using the configured Callback URL, HTTP Method, and Request Body, then sends it to the target endpoint, optionally authenticating with the target system and routing the request through a proxy server if configured.
Once a response is received, specific values can be extracted from it and stored as variables, making the response data available for use in subsequent nodes. Any errors encountered during execution are captured through the Exception Variable.
Supported Fields
Field | Description |
Name | Enter a unique and descriptive name for the webhook node. |
Callback URL | Specify the endpoint to which the HTTP request is sent when the node is executed. |
HTTP Method | Select the HTTP operation to perform. Supported values include GET and POST. |
Body | Define the request payload that is sent to the target endpoint. The payload consists of name-value pairs, where values can be static or dynamically populated from workflow variables. |
Authentication Type | Select the authentication mechanism used to authenticate the request with the target system. |
Via Proxy | Enable this option to route the webhook request through a proxy server instead of connecting directly to the target endpoint. |
Proxy Host | Specify the hostname or IP address of the proxy server through which the request should be routed. |
Proxy Port | Specify the port number on which the proxy server is listening. |
Enter Webhook Output Value | Specify the response value or path that should be extracted from the webhook response. |
Enter Name for Output Parameter | Specify the variable name used to store the extracted response value within the Integration Flow. |
Exception Variable | Specify a variable to capture and store any errors encountered during webhook execution. |
Choosing an Authentication Type
Since target systems vary widely in how they expect requests to be authenticated, choosing the right type matters:
Use Public URL only for endpoints that are genuinely open and don't require credentials.
Use Pre-Shared Key or Basic Auth for simpler, credential-based integrations where the target system supports them.
Use OAuth 2.0 for systems that require token-based authentication and support token renewal, offering stronger security than Basic Auth.
Use Salesforce specifically when integrating with Salesforce, since it handles the underlying OAuth flow using pre-configured Salesforce credentials.
Best Practices
Configure an Exception Variable: Define an Exception Variable to capture and handle webhook execution errors. This enables the workflow to distinguish failed requests from successful executions and route them appropriately.
Select the Appropriate HTTP Method: Use the HTTP method that matches the requirements of the target endpoint. For example, use GET for retrieval operations and POST when sending data or triggering actions.
Keep the Request Payload Focused: Include only the required name-value pairs in the request body to ensure the webhook sends relevant data to the target system.
Choose an Appropriate Authentication Type: Select the strongest authentication type the target system supports, preferring OAuth 2.0 or Salesforce authentication over Public URL wherever security matters.
Use a Proxy Only When Necessary: Enable Via Proxy only when required by network or security requirements. Routing requests through a proxy introduces an additional network step before the request reaches the target endpoint.