Webhook: Reply Node

The Webhook: Reply Node allows a workflow to send a custom reply to an HTTP request or send a message to a connected WebSocket client. For HTTP replies, the webhook must be configured to wait for a reply.

Configuration

For HTTP webhooks, all the standard components of an HTTP response are configurable in the Webhook: Reply Node - the response code, the body, and the headers. For WebSocket webhooks, the available configuration fields are message encoding (which defaults to UTF-8) and the message to send. When using a WebSocket webhook, you must select the WebSocket Message radio button.

In the above example, the response code is set to 200, although that field is templatable and so can be configured from the current payload. It is expected to resolve to a valid response code number, and if it does not, the reply will default to a response code of 200.

The body of an HTTP reply or a WebSocket message can be set either as a string template or as a payload path. In the above example, it is a string template that resolves to a string of JSON. If payload path is chosen and the payload path points to an object, that object is stringified as JSON for use as the body. For HTTP replies, the body is allowed to be empty, if no body is desired on the reply. WebSocket messages must contain a value.

If you attempt to send a WebSocket message as a reply to an HTTP webhook, you will receive the following error:

Cannot write a WebSocket message to an HTTP webhook.

If you reference a payload path that does not exist as the WebSocket message or HTTP reply, the platform will send an empty string.

Arbitrary headers can also be set on the reply. Both the header name and value fields are templatable, so they are configurable based on the payload. In the example above, only one header field is set - Content-Type is set to application/json. This is set because the body of the reply is JSON. This will probably be the most common header to set - WEGnology does not automatically attempt to determine the content type.

Notes About Security

• Webhook replies allow a limited set of values for the Content-Type header: application/json, application/xml, text/plain, text/xml and text/csv. If no Content-Type is set, or an invalid Content-Type is set, the Content-Type of the response will be set to application/json.
• WEGnology automatically sets protective values for the following headers, none of which can be overridden in a webhook reply: X-Content-Type-Options, Content-Security-Policy and X-XSS-Protection.

Advanced Options

The Webhook: Reply Node has one optional advanced option - setting the payload path for the replyId.

The reply ID path defaults to data.replyId, which is where the Webhook Trigger places the ID that represents the current HTTP request or WebSocket client. If you have moved this identifier to a different location on the payload, or you’re using multiple workflows and passing this ID between them, you can provide an alternative payload path in this field. If there is no reply ID at the path given, the Webhook: Reply Node does nothing.

If you wish to send a message to a WebSocket client that is in response to some event other than a WebSocket client connection or received message, you must store the replyId value somewhere so that it can be referenced later when invoking this node (such as in workflow storage).

Considerations

The Webhook: Reply Node allows for sending a maximum message size of 1MB.