HTTP Request Trigger

Automations can be triggered via HTTP requests to enable external integrations either from web hooks, custom HTTP integrations, or even end-users.

Triggering Automations using HTTP Requests

HTTP triggering allows an automation to directly handle an incoming HTTP request from an automation-specific URL extension to the REST API. To enable an automation to be triggered via HTTP,

1. On the automation's Overview, locate Triggers, and check HTTP Request.
2. Select the authentication option required by the automation
   1. REST Authentication. When authenticating with REST Authentication, each request to the automation will be authenticated using the same options used to authenticate other REST API requests. OAuth, API Keys, and requests made from platform-rendered UI using the $.telligent.evolution.post/get/put/del() client-side APIs are supported. If authentication fails, the automation will not execute. If authenticated, the accessing user (if Execute as the service account is not checked) and context_v2_automationTrigger.TriggeredBy will be set to the user who was used to authenticate.
   2. No Authentication. When no authentication is selected, no authentication or access restriction is applied to the request. Every request is provided to the automation to process. This technique is suitable for web hooks, for example, where a signature header may be provided and can be validated against a pre-shared secret key and hashing algorithm. When choosing to use no authentication on an automation, ensure that the automation is implementing appropriate logic to ensure it should be executing.
3. Take note of the URL in the inline documentation. This is the URL at which you can trigger the automation.

Using HTTP Triggers in Automation Implementations

When an automation is triggered by an HTTP request, details about the request are made available through the context_v2_automationTrigger API which provides the following members to handle interaction with the HTTP request and providing a response:

• Entity. For HTTP triggers, the Entity will always be "Http"
• Event. For HTTP triggers, the Event is the HTTP method used to make the HTTP request. For example: "GET", "POST", "PUT", "DELETE"
• Arguments. For HTTP triggers, the Arguments property is always exposes two properties:
  • Request. Request provides data about the incoming request:
    • Body. The raw body text from the request.
    • Data. If the request defines a content type of "application/json", Data represents the parsed object from the JSON provided in the request's body. This property makes it easy to handle rich data definitions encoded as JSON.
    • Form. If the request defines a content type of "application/x-www-form-urlencoded" or "multipart/form-data", Form provides the parsed form values from the body of the request. 
    • Headers. The parsed headers from the request.
    • Method. The HTTP method of the request.
    • QueryString. The parsed query string from the request.
  • Response. Response provides access to format the response back to the HTTP client:
    • Body. The raw body text to respond with.
    • Headers. The headers to respond with.
    • StatusCode. The HTTP status code to respond with. If not provided, 200 will be used.

See the inline documentation for the context_v2_automationTrigger for more details about HTTP trigger arguments.

HTTP Trigger Notes

1. HTTP enablement is provided on an automation, however, the automation is not enabled until an instance is created in Administration > Automations > Automations. Until at least one instance of the automation is enabled, the URL provided in the inline documentation for the automation will not be accessible.
2. Automations support multiple instances, but only one HTTP response can be provided. For automations that can be triggered by HTTP requests, if there are multiple enabled instances defined in Administration > Automations > Automations, the automation will be executed multiple times (once for each instance) when an HTTP request triggers the automation.