Edge 1.0.0

Edge HTTP Request Trigger Node

The HTTP Request Trigger fires a workflow whenever the Gateway Edge Agent receives a request on itslocal web server. The trigger can fire on all requests or those matching a specific method and/or route.

HTTP Request Trigger

Node Properties

There are two configuration settings for the HTTP Request Trigger: Method and Route.

NOTE: Prior to Gateway Edge Agent v1.24.0](/edge-compute/gateway-edge-agent/changelog/), this trigger had no configuration. For those agents, this trigger always matches any incoming request on the local web server.


This is the HTTP method the request should match. Currently, we support these methods: GET, POST, PUT, PATCH, DELETE, OPTIONS. To have the trigger match any request method, choose Any Method (this is the default behavior).


The route is the URL path, or the part after your local server’s domain. If your local server’s domain is http://localhost, the route is everything after that. It always starts with a slash / and may contain a series of static and parameter segments separated by more slashes.

There are a number of rules to consider when specifying a route for the HTTP Request Trigger:

  • Routes can contain string literals, path parameters and wildcards. For example, given the route /devices/{deviceId}/{attribute?}

    • devices is a string literal, which is a static route parameter.
    • {deviceId} is a required path parameter. If a request is made to /devices/ without a {deviceId} after the trailing slash, the request will not match this trigger.
    • {attribute?} is an optional path parameter; a request to /devices/123 and /devices/123/temp will both succeed and will both match the trigger, but the latter will include {"attribute": "temp"} as part of the payload passed to your workflow.
  • Routes can contain wildcards. Wildcards must be used with care, as they will match any request. A typical use case for a wildcard is if you want to create a trigger to deal with all OPTIONS requests; in that case, you would configure a route of /{var*}, where var is available on the payload with the value of whatever the user entered after the first slash.
  • Any matching route trigger is fired. If two triggers, with different route configuration, both match a given request, both triggers will fire.
  • A blank route will match any request. When the route is left blank, this is treated as a match anything route (and this is the default behavior).


The payload for a workflow triggered by the HTTP Request Trigger will include all of the information about the triggering request in the data field. This includes the request path, the request method, any request headers, any request query parameters, any parsed path parameters (based off the route definition for the trigger), any cookies, and the request body. If there is no body present, the value for the body field will be null. Otherwise, if the content type is multipart/form-data, application/x-www-form-urlencoded, or application/json and the request body is valid for that content type, it will automatically be parsed into an object. For other content types, such as text/plain, the body will be left as a string.

In the general case, an HTTP Request Trigger workflow payload will look like the following:

  "applicationId": <id of the current application>,
  "applicationName": <name of the current application>,
  "data": {
    "path": <the path of the request>,
    "params": <any parsed path params for the route>,
    "method": <the request method - delete|get|options|patch|post|put >,
    "headers": <any request headers>,
    "query": <any request query params>,
    "body": <the request body>,
    "cookies": <the cookies on the request>,
    "replyId": <the reply id>
  "deviceId": <id of the edge device>,
  "deviceName": <the edge device name>,
  "deviceTags": {<any tags for the edge device>},
  "flowId": <id of the current workflow>,
  "flowName": <name of the current workflow>,
  "flowVersion": <name of the current workflow version>,
  "globals": <object of workflow globals>,
  "isConnectedToWEGnology": <if the agent is connected to WEGnology>,
  "agentEnvironment": <object of environment variables>,
  "time": <time of the request>,
  "triggerId": "request",
  "triggerType": "request"