Configuring webhook fields: Method, Resource, and Payload
The main advantage of configuring a Webhook is that Nexthink data from alerts or events can be pushed into various third-party tools, depending on the destination.
On the Webhook configuration page, three fields are critical to performing an action on the destination third-party tool:
Method
Resource
Payload
The following sections explain how to configure the attributes to execute an action on the third-party tool.
Selecting the Method
From the Webhook configuration page, after choosing the credentials:
Select one option from the Method dropdown: POST, PUT or PATCH. See the table below.
Optionally, review the pertinent third-party software documentation to identify the semantics of each method clearly.
Do not assume all methods are similarly used by all vendors and providers of third-party tools.
The REST standard is used over HTTP, comprising a major portion of the uniform interface constraint and provide the request methods available for webhooks.
POST
Create
POST is most often utilized to create new resources.
PUT
Update/Replace
PUT is most often used for its update capabilities. You can PUT to a known resource URI with the request body containing the newly updated representation of the original resource.
PATCH
Update/Modify
PATCH is used for its modification capabilities. The PATCH request only needs to contain the changes to the resource and not the complete resource.
*CRUD is an acronym for create, read, update, and delete.
Filling in the Resource field
Special considerations for resources:
Resources are data sets accessible via endpoints that can be used with APIs.
Resources relate to other resources and are limited by the operations that can be carried out on them.
Resources are presented as endpoint groups based on related data, or the objects they can work with.
Resources have simple names, making it easy for users to find the right endpoints. However, this may lead to overlooking essential functionality.
To add the Resource value from the Webhook configuration page:
Paste the Resource value which is the action specified by the third-party REST API.
The URI shouldn’t be added since it is concatenated to the Instance URL defined in the webhook credentials.
The Resource value can contain parameters (key=value) that the third-party tool requires.
If needed, add placeholders
{{variable_name}}
to the Resource. Refer to the Using data model variables as placeholders in the payload section on this page.
Examples of valid Resource values
https://webhook.atlassian.net/rest/servicedeskapi/request
rest/servicedeskapi/request
https://api.4me.com/v1/requests
v1/requests
https://fra1.qualtrics.com/API/v3/users
API/v3/users
https://ven01063.service-now.com/api/now/v1/table/incident
api/now/v1/table/incident
https://api.4me.com/v1/requests?api_<token>=
v1/requests?api_<token>=
Writing the Payload
The Payload is the data pack sent with the POST/PUT/PATCH method in HTTP.
To write the Paload value from the webhook configuration page:
Include in the Payload the crucial information you submit to the server when requesting the API.
Optionally, review the pertinent third-party fields and values as the Payload depends on the tool used in the webhook.
If needed, use Nexthink data model variables as placeholders
{{variable_name}}
within the Payload.After filling in the webhook NQL conditions, the system lists the Allowed placeholders in the Nexthink web interface for your convenience.
Use the Examples of Method, Resource and Payload from multiple providers included on this page as reference.
The Payload field only accepts JSON format.
Using data model variables as placeholders in the payload
One of the most significant advantages of pushing data from Nexthink into third-party tools is the ability to pass information about an event that has taken place.
To use Nexthink data model variables as placeholders within the Payload:
Reference Nexthink variables using the placeholder
{{variable_name}}
within any field reported in the payload.After filling in the webhook NQL conditions, the webhook configuration page lists the Allowed placeholders in the Nexthink web interface for your convenience.
The placeholders in the payload must align with the webhook NQL conditions populating the Nexthink variables.
Additionally, you can review the NQL data model to determine the Nexthink variables available for placeholders.
Remember, the NQL data model is organized by namespace > table > field.
For example, the placeholder
{{alert.monitor.name}}
contains thename
field, from themonitor
table, in thealerts
namespace. Refer to the Data organization documentation for more information.
Add the
as(format = text)
in the placeholder to ensure the output is readable and user-friendly when generated in the third-party tool. For example,{{remote_action.execution.outputs.as(format = text)}}
.If needed, use special placeholders not strictly defined in the NQL data model, that are included on this page and also referenced in Allowed placeholders in the Nexthink web interface:
The image below is an example of a payload with placeholders referencing Nexthink data-model variables. Note how the system lists the Allowed placeholders for this case.
The system cannot replace placeholders with empty values or invalid. In these cases, {{variable_name}}
appears as is.
Special placeholders for Alerts data model variables
This table includes special placeholders for alerts not strictly defined in the NQL data properties.
alert.monitor.thresholds
Each array item has an alias
(metric name) and a corresponding value
:
{{alert.monitor.thresholds[n].alias}}
{{alert.monitor.thresholds[n].values}}
Replace the [n]
value with an integer. The number of [n]
values depends on the number of metric thresholds defined in the monitor:
• [0]
value is always available.
• [1]
or higher values are optional.
alert.trigger_values
Each array item has an alias
(metric name) and a corresponding value
:
{{alert.alert.trigger_values[n].alias}}
{{alert.alert.trigger_values[n].value}}
Replace the [n]
value with an integer: [0]
, [1]
, etc.
alert.trigger_reference_value
{{alert.alert.trigger_reference_value}}
Refer to the Metric change item under the Type section in the Customizing built-in monitors documentation to learn more about reference_value
computation.
alert.context
{{alert.alert.context}}
{{alert.alert.context.<property name>}}
{{alert.alert.context.<property name>.label}}
{{alert.alert.context.<property name>.data_path}}
{{alert.alert.context.<property name>.data_type}}
See the examples below*:
{{alert.alert.context.binary.name}}
{{alert.alert.context.binary.name.label}}
{{alert.alert.context.binary.name.data_path}}
{{alert.alert.context.binary.name.data_type}}
*The context
field contains only the data model properties defined in the monitor NQL query and conditions.
Therefore, the context
field may include the name of the binary, device or user associated with the alert.
alert.alert.issue_view_link
alert.alert.device_view_link
alert.alerts.links
This properties are not currently listed in the NQL data model.
alert.alert.issue_view_link
provides the link to the troubleshooting dashboard associated with the alert. You must add the issue_view_link
field to the list
clause in the webhook NQL condition.
alert.alert.device_view_link
provides the link provides the link to the Device view. You must add the device_view_link
field to the list
clause in the webhook NQL condition.
Depending on the alert configuration, the alert.alerts.links
placeholder provides the link to the Device view or to the troubleshooting dashboard associated with the alert.
In this case, you must add both device_view_link
and issue_view_link
fields to the list
clause in the webhook NQL condition.
Special placeholders for Remote actions data model variables
This table includes special placeholders for remote actions not strictly defined in the NQL data properties.
remote_action.execution.outputs
{{remote_action.execution.outputs.<property name>}}
For example:
{{remote_action.execution.outputs.MeteredConnection}}
remote_action.execution.inputs
{{remote_action.execution.inputs.<property name>}}
For example:
{{remote_action.execution.inputs.InputPath}}
remote_action.execution.account_name
This property is not currently listed in the NQL data model.
{{remote_action.execution.account_name}}
This placeholder provides the user/employee that executed a remote action.
Examples of Method, Resource and Payload from multiple providers and tools
Refer to the Webhook use cases setup documentation for full webhook configurations for several third-party tools.
ITSM Tools
Creating an incident for ServiceNow
Method: POST
Resource: api/now/v1/table/incident
Payload:
Follow this guideline to set up webhooks to detect alerts and events and transmit them to ServiceNow to create an incident.
Updating ServiceNow incident ticket from Amplify
Method: PATCH
Resource: api/now/v1/table/incident/{{remote_action.execution.external_reference}}
Payload (message):
Include the as(format = text)
function in "work_notes"
to display the output of a remote action in a readable format.
Follow this guideline to set up webhooks to update ServiceNow executed actions log from Amplify.
Creating a problem for ServiceNow
Method: POST
Resource: api/now/v1/table/problem
Payload:
Creating an incident for BMC
Method: POST
Resource: api/arsys/v1/entry/HPD:IncidentInterface_Create?fields=values(Incident Number , Request ID, First_Name)
Payload:
Creating an incident for 4me
Method: POST
Resource: v1/requests
Payload:
Creating a service request for Jira Service Desk
Method: POST
Resource: rest/servicedeskapi/request
Payload:
Alerting Tools
Creating an incident for Pager Duty
Method: POST
Resource: incidents
Payload:
Messaging Tools
Posting a message on an MS Teams channel
Method: POST
Resource: /workflows/XXXXXXXXXXXXXXXXXXX/triggers/manual/paths/invoke?api-version=?????&sp=/triggers/manual/run&sv=1.0&sig=XXXXXXXXXXXXXXX
Payload:
Follow this guideline to set up MS Teams to receive incoming requests.
Posting a message on a specific channel for Slack
Method: POST
Resource: services/T01S01V0HB3/B02GY9BKZ7G/DIDFWXuCAeFfqkgNntQqJV7e
Payload:
Follow this guideline to set up Slack to receive incoming requests.
Posting a message in Zoom
Method: POST
Resource: chat/webhooks/incomingwebhook/dSUcla-dQaGYgqGuBk3BsQ
.
The URL resource above is for illustration purposes only as it depends on the Endpoint URL you directly configure in Zoom.
Payload: Add the message you want to send to Zoom. See the example below.
Follow this guideline to set up Zoom to receive incoming requests.
Productivity Tools
Creating a bug on a specific project for Jira
Method: POST
Resource: services/T01S01V0HB3/B02GY9BKZ7G/DIDFWXuCAeFfqkgNntQqJV7e
Payload:
Data Platforms
Sending an event to the event collector for Splunk
Method: POST
Resource: services/collector?index=_main
Payload:
Last updated