Outgoing Webhook
Learn about outgoing webhooks and how events are triggered for your account.
Last updated
Was this helpful?
Learn about outgoing webhooks and how events are triggered for your account.
Last updated
Was this helpful?
Outgoing Webhooks are requests made by PagerTree to a user-defined URL, the payload provided represents an alert. Webhooks allow you to extend PagerTree by performing any logic you wish.
by clicking the Outgoing Webhook logo.
Provide the URL you want PagerTree to send webhooks to.
Outgoing webhooks will send data in a POST request in JSON format to your configured URL. Each request has the following format:
Outgoing webhooks can also send data in a custom format. The request is still a POST request and must be in JSON format.
You can edit the format in the JSON Template section of the integration settings.
The data you have access to are the following properties:
If you do not see a log, ensure the integration is enabled
If you do see a log, view the log by clicking the log link. An error should be provided in the status
field in the content section on the right hand side.
Linked data is a convenience option that embeds referenced objects. Linked data will send the following extra attributes.
d_team
d_team_id
d_user
d_user_id
source
source_id
s_log
s_log_id
If you are using a custom template you can access the linked data like so: {{alert.d_user.name}}
.
Currently PagerTree support 8 events:
alert.created
- fired exactly once, when the alert is created in the database.
When routers are matching rules they are given access to data. Namely you are given access to the alert
, integration
, and event
in context, and a special field always
which is always true (especially useful for catch all rules).
In our most basic example, we can suppress events when the alert is created by a specific integration.
In a second example, we suppress any event that is not “critical”.
Responses in the 2xx family will be considered a success, any other response will be considered a failure.
Webhooks retries will be attempted up to 14 times with exponential backoff.
Where event_type
is an and data
is an alert.
Templates support Handlebars substitution with the event
and alert
objects. You can use any to support any logic. Use to access deeply nested data (ex: alert.d_user.name
).
For the .
If for any reason you do not receive the webhook with a custom template, it is likely you have a formatting error. On the integration page, look at the .
alert.open
- Fired exactly once, when the alert .
alert.acknowledged
- fired 0-N times, when the alert is by a user.
alert.rejected
- can be fired 0-N times, when the alert is by a user.
alert.timeout
- can be fired 0-M times, when an alert layer times out and moves to the next .
alert.resolved
- fired 0-1 times, when the alert is .
alert.dropped
- fired 0-1 times, when the alert is .
alert.handoff
- fired 0-N times, when the alert is .
You can suppress outgoing webhooks or modify the payload using rules. This feature uses the same engine as the and is also expressed in YAML. You can use all the same as routers for matching conditions, but you can only use the and actions. The root element should always be rules
(an array), with each rule having a match
(hash) and actions
(array).
In the next example, we are working with the integration and we switch the channel PagerTree sends the notification to.
There is a special value webhook_url
that if set using the operator will change the URL that the webhook is sent to. You can use this to dynamically change where webhooks are sent to.