Overview of triggered actions and webhooks

Introduction to triggered actions and webhooks, and what can be achieved with each.

Skedulo supports two different ways to integrate with real-time events – Triggered Actions and Webhooks – which can be configured via our API: /triggered-actions and /webhooks.

Triggered actions are back-end configurations that instruct the Skedulo platform to perform an action when a data change or other event occurs.

Triggering events include:

  • a data record being inserted, updated or deleted
  • a timer elapsing and
  • an SMS message being received from a customer.

Actions include:

  • making an HTTP POST request to a URL and
  • sending an SMS message.

Each configuration consists of a filter, a URL, and a GraphQL query or SMS message template.

The filter limits the cases that generate an action. A filter is mandatory for triggered actions and optional (but strongly recommended) for webhooks.

Features and differentiators

Whether you use a triggered action or webhook depends on your use case, as some features are only available using one implementation or the other.

Triggered actions can be used in most use cases but you will need a Webhook for inbound SMS messages and scheduled actions.

Feature Triggered actions Webhooks
Include the previous data for a modified object. ✅ ✅
Query can retrieve extra data after a trigger is fired. ✅ ❌
Send an SMS when triggered. ✅ ❌
Execute after a time offset (deferred action). ✅ ✅
Trigger on inbound SMS. ❌ ✅
Execute on a schedule (cron job). ❌ ✅

Authentication requirements for webhooks and triggered actions

  • To use webhooks and triggered actions, you must have an API access token, which can be obtained through the administrator settings in the Skedulo web application. The API token must be included in the Authorization header using the Bearer method. See Admin Settings: API tokens for more information about how to obtain an API token.
  • Skedulo for Salesforce users must also have an API user configured for the Skedulo team (tenant). See Skedulo API user for more information.
  • Only secure URLs (HTTPS) are accepted.

HTTP request headers

Webhooks and call_url triggered actions (see the triggered actions section for information on action types) set the following headers in their HTTP requests, depending on the context of the request:

Header Context Description Example value
Always, if defined. User-defined headers that are included in the configuration of the triggered action or webhook.
User-Agent Always Identifies the caller. Always set to “Skedulo”. Skedulo
Skedulo-Triggeredactionlogid Always An ID that represents the specific request. Note that webhooks also have this header, since they are implemented as a triggered action. 41701066
Skedulo-Triggeredactionid Triggered actions only The ID of the triggered action configuration that caused the request. This will be the same every time this triggered action is executed. ce8c078c-646b-4aa1-84fa-efd377a5797d
Skedulo-Request-Id Webhooks only An ID that represents the specific request. Included for backward compatibility. The same value as Skedulo-Triggeredactionlogid 41701066
Skedulo-Webhook-Id Webhooks only The ID of the webhook configuration that caused the request. This will be the same every time this webhook is executed. 55b353d8-07f5-4141-8c5b-f7dbc463a6f3