Webhooks enable you to create custom integrations and let Bloomreach Engagement communicate with different services via APIs (HTTP request). Webhooks provide a way to send automated messages via scenarios to a third party or, the other way around, retrieve data from a third party. Using standard scenario flow you can, for example, set up a webhook to be always triggered after a certain event occurred. Webhooks can be used for various use cases, such as triggering an action in a third-party platform, sending leads to call centers, or retrieving third-party data to enrich your campaigns or single customer view, and many others.
We also provide several predefined webhook templates for interacting with multiple platforms like Facebook, Whatsapp, Zapier, Slack, and others.
- Go to
Webhook setup consists of two main parts:
Endpoint select the appropriate HTTP method (GET, POST, PUT, PATCH, or DELETE) and enter the endpoint URL.
Payload using the code editor enter the desired API payload. On the right side of the editor, you can select the type of payload format: JSON, TEXT, or XML. You can also use jinja to create dynamic personalized payload or template parameters to create easily editable fields. Created parameters will be accessible under the
Parameters tab is where all the bracket parameters are pulled.
Test webhook button allows you to render the request with non-personalized data.
Done button sends the rendered request
A webhook fail branch allows you to specify further action for customers who did not manage to go through the webhook node. This can sometimes happen due to a number of different reasons such as skipping due to consent & policy, aborting due to using Jinja, or other technical failures. In the Evaluation tab, you will be able to observe them under the Failed category. To set it up, simply connect desired nodes to the fail branch as seen below:
Batching on-events campaigns is a special case that happens only when multiple events are fed into Bloomreach Engagement at the same time. The approach is:
There is a system scenario that is triggered by an event and that sends batched calls to other third parties
other scenarios generate the events that trigger the system one, thus at some point, the system scenario gets a steady feed of new events that are successfully batched
The size of the batch may vary, it could be 180 or 170, etc. with a maximum limit of 200.
Updated about 2 months ago