Webhooks
Webhooks enable your LogicLoop rule to trigger any downstream action that has an API.
To set up your rule to trigger a webhook, first go to Action Destination and create a new Webhook Builder destination. The webhook builder will allow you to construct your webhook request by entering the required method type, URL, Authorization headers, and body. The following example shows you how you can use the Webhook Builder to set up a webhook integration with Twilio, but it can be used for any service that exposes an API including Zapier, Stripe, Asana, Sendgird, Whatsapp, and even your company's own internal API endpoints.
Sample setup of a webhook that triggers a text message to be sent via Twilio
What's powerful about the webhook builder is that a technical team member can configure it once with the correct header and body structure, and they can insert whatever parameters they want for a non-technical user to later plug and play. In this example, we've decided to create two variables called
PHONE_NUMBER and TEXT_MESSAGE_COPY available for replacement.Next, to use this Twilio webhook integration, a non-technical member can go to their Action and add the Twilio integration to be triggered every time their rule runs. The will see the two parameter fields that were made available in the destination configuration that they can fill in. The non-technical member can change the copy of the text message or the phone number it goes out to at any time without involving an engineer to rebuild the webhook integration.
If the phone number and text message changes depending on which user you are sending the text to, you can even inject variables from the result of your queries into your notification as you can with any of our action subscription templating variables.
Here's what this Twilio text message would look like when received by the user:
.png?alt=media&token=3778580f-539a-4307-a2fb-3b6ee13757fb)
Start by giving your webhook a name, and setting the method to POST.
Give it a url. Above, we set the base url, and used a template,
{{API_METHOD}} , for the specific endpoint. This allows you to choose the endpoint when creating an alert with this Destination.For posting to Slack, you'll likely use
chat.postMessage as your endpoint, though you can see all other options here.Add Body fields for API Call.
Again, we use templates so you can specify the Channel ID, Title, and Message Content (along with Rule Url and Action Url. You can copy and paste our example blocks section here:
[{"type": "header", "text": {"type": "plain_text", "text": "{{Title}}"}},{"type": "section", "text": {"type": "mrkdwn", "text": "{{Message Content}}"}},{"type": "section", "fields": [{"type": "mrkdwn", "text": "<{{Rule Url}}|*Go to Rule*>"}, {"type": "mrkdwn", "text": "<{{Action Url}}|*Go to Action*>"}]}]
Lastly, you want to create the actual alert.
To get the channel id, open slack and navigate to the specific channel. Click the channel name at the top, and a pop-up should open. The About tab of the pop-up will have the Channel ID at the bottom.
You can also create an alert that sends messages to a dynamically specified channel.
First, the rule would need a Channel ID column (you can name it
channel_id). Then you would have to set your Action to run For each row returned.
Lastly, you would set Channel ID in the form above to
{{ channel_id }}.Alternatively, you can also use our raw Webhook destination instead of the Webhook Builder if you want to be able to directly construct the body and headers to be sent as raw JSON. First, go to your Action Destinations and create a new destination of type Webhook. Enter a name, URL, and Authorization headers (if any) of your endpoint.
Next, go to your Action and add the webhook action subscription. Enter additional information for your webhook which will include the method, URL, headers and body.
You may leave the URL field blank, in which case the URL will be the one you configured when you created the action destination. If you do specify a URL, it will override the URL you configured in the action destination.
The headers and body fields must be valid JSON. The header fields that you enter in the header section will be appended to default headers that are automatically sent, such as the Authorization. The default content-type is application/json, but you may override this by entering "content-type": "application/x-www-form-urlencoded" in the headers if you wish to use URL encoded format instead.
Header keys and values must be strings in double quotes -- as you can see in the example, you need to specify "{{ ROW_EMAIL }}" not just {{ ROW_EMAIL }}. The body can take nested JSON values as well. Note that in the example we write "Data": {{ ROW }}, instead of "Data": "{{ ROW }}" because {{ ROW }} is a valid JSON structure. For URL encoded content type nested structures are not currently supported.
Here's what this webhook request payload looks like when sent:
Last modified 1mo ago