Skip to main content

Triggers

A package runs in response to a trigger. There are five trigger types:

  • Webhooks: an external system (such as Xurrent) sends an HTTP request to the automator.
  • Schedule: a timer fires on a cron-like schedule.
  • Inbound email: a message arrives in a configured mailbox (IMAP or MS Graph).
  • Service GET: a GET request is made to a service endpoint.
  • Service POST: a POST request is made to a service endpoint.

Configuration of these trigger events is done in two steps:

  1. Configure the trigger itself: set up a webhook, schedule, service, or mailbox.
  2. Link the trigger to the package(s).

Each trigger type has its own tab in the automator and its own page in this section:

A single trigger can be linked to multiple packages, which gives you a powerful organization tool: rather than mixing logic for different types of integrations in a single package, you can cleanly separate them into separate packages. Conversely, a single package can be linked to multiple triggers, which allows you to reuse the same logic.

Relation to account​

When linking a trigger to a package, you always have to specify an account as well.

For webhooks, you specify the webhook and the account separately: the webhook determines which requests trigger the package, the account is the Xurrent account the package works with. The account also helps to identify the API user, as explained in the previous section.

For all trigger types (including webhooks), the account is used as the default account for the package execution. Many functions in the standard library have an optional account parameter, that takes the name of the account to use. One example of this is the http_request function, but almost all functions in the standard library that need to connect to a remote service have this. If the account parameter is not explicitly specified, the package execution will use the default account.

Apart from being shorter to write, this also makes it possible to use the same package for multiple accounts. For example, suppose you have a Xurrent-to-Xurrent integration that you want to run in multiple Xurrent support domains. To avoid duplicating the integration logic, you could create a single package and link a trigger for each Xurrent support domain.