Integrate a webhook with Splunk Observability Cloud

Webhook integrations contain authentication information and a custom payload that Splunk Observability Cloud sends in an HTTP request to the URL specified in the integration’s url property.

Use a Webhook integration when you want to use a notification system for which Splunk Observability Cloud doesn’t provide a specific integration.

To learn more about parameters in the request and response bodies of the Webhook Integration API, see Integrations API.

When you send an API request, you need to use the endpoint specific to your organization's realm. To learn more, see Realms in endpoints.

 Shared secret

The webhook integration uses an encryption key in the form of a string as the shared secret.

If the property is present and non-null, Splunk Observability Cloud does the following:

1. Calculates a hash-based message authentication code (HMAC) for the notification message using the HMAC SHA256 cryptographic hash algorithm and the sharedSecret value as the cryptographic key.
2. Encodes the HMAC in base64.
3. Stores the encoded result in the HTTP header X-SFX-Signature. Splunk Observability Cloud adds this header, so you don’t have to specify it in the headers property.

Do the following to verify notification messages in the webhook target system:

1. Compute the HMAC SHA256 code for the incoming HTTP request payload using the sharedSecret key.
2. Encode the computed result in base64.
3. Compare the encoded value to the value of X-SFX-Signature in the incoming HTTP request. If the values match, the message is valid.

 Default payload

When you don't specify any customization for your webhook payload, the default payload is used. You can use the following template to get similar result.

JSON
{
    "severity": "{{{severity}}}",
    "originatingMetric": "{{{originatingMetric}}}",
    "detectOnCondition": "{{{encodeString detectOnCondition}}}",
    "detectOffCondition": "{{{encodeString detectOffCondition}}}",
    "messageBody": "{{{encodeString messageBody}}}",
    "src": "{{{src}}}",
    "inputs": {{{json inputs}}},
...
Show More

 Default payload example

The following example shows the default payload for an alert when memory usage exceeds 90%.

JSON
{
  "sf_schema": 2,
  "detector": "A detector that alerts when memory usage exceeds 90% for 10 minutes",
  "description": "The value of memory.utilization is above 90.",
  "detectorUrl": "https://app.<REALM>.signalfx.com/#/detector/ABCDEFGHIJK/edit",
  "detectorId": "ABCDEFGHIJK",
  "incidentId": "BCDEFGHIJKL",
  "eventType": "exceedMemoryUse",
...
Show More

 Custom payload variables

You can customize your payload to make sure responders have the context needed to resolve the issues. See the following table for the full list of variables available for customization.

• Unless otherwise indicated in the description, all variables are of type string.
• When a variable is optional, it means it's not always available. If you use an optional variable that isn't available in the present conditions to construct your payload, Handlebars converts it to an empty string.

 inputs array

Each object in the inputs array is named after the program variable it’s bound to. If an object isn’t bound to a program variable, it uses a name like _S0, _S1, and so on.

Each input object contains the following elements:

 Helper functions

Apart from using template variables to customize your payload, you can also use the following helper functions to make sure the right value is set on the outgoing alert.