Connectors / Trigger / Webhook Trigger

Webhook Trigger

Webhook Trigger

Catch callouts for any service that offers sending a signal to a custom URL.

Overview

A webhook (otherwise known as a web callback or HTTP push API), is a way for applications to provide other apps with real-time information. A webhook typically delivers data to other applications "as and when it happens", meaning you get data immediately.

The Webhook Trigger is designed to allow users to catch callouts for any service that has the option of sending a signal to a custom URL.

Setup & Authentication

Below is a summary of how the Webhook Trigger is configured.

While remaining as general as possible, occasionally Braintree has been used for demo purposes where need be.

1 - Locate the public URL

The Webhook Trigger's public URL is where all Webhook callbacks are sent. This is what allows Tray.io to receive data from a users service of choice.

The steps to find the Webhook Trigger's public URL are as follows:

  1. Create a new workflow and select the WebHook as your trigger.
  2. Click on the menu icon in the top-left corner.
  3. Select Workflow settings followed by the General Settings tab.
  4. Copy the Workflow Public URL for later use.

2 - Configure settings (service side)

In order to work in tandem with the Tray.io, the Webhook Trigger needs to be associated with the selected service. This is where the Webhook's public URL comes into play.

Please be aware this is only a rough guide as it will vary from service to service.

The steps to send all callouts to your Webhook Trigger are as follows:

  1. Log in to your service of choice.
  2. Select 'Account Settings'. Note that this varies by service. Consider looking under 'Preferences', 'Security', 'API', etc.
  3. Select the relevant 'WebHooks' heading. This may also be under the name 'Apps & Credentials', 'API Links', and so on.
  4. Make sure the parameters needed and necessary privacy settings are selected.
  5. Add the Tray.io Workflow public URL to the target field.

Below is a sample of what users should be looking to achieve depending on their application. I.e, the Webhook public URL registered with the service in quesiton.

3 - Test authentication

Once the above steps have been followed, return to the workflow dashboard in order to test/ complete the trigger setup.

The steps to will be as follows:

  1. Click the 'Enable' button found at the bottom-right of the workflow dashboard. Tray.io will now be actively listening for calls from any Webhook, whose target is the Workflow Trigger's public URL.
  2. Navigate back to the service dashboard and deliberately provoke an event type. This needs to be one that the Webhook Trigger is configured to listen out for. Depending on the service, examples include customer creation, survey completion, declined payments etc. What is important is that regardless of the event type, users only provoke the trigger using a fake/ test event.
  3. Some users may be lucky enough to be using a service which already provides a URL check (such as Braintree below):
  1. Return to the workflow dashboard and click the Debug button. If the configuration is correct, users will be able to see a green entry within the workflow logs, containing the data from the test event:

Once setup is complete, any data which is received by the Webhook Trigger can be used and manipulated else where within the workflow, depending on a users needs.

Extracting data

Using and moving data from the Webhook Trigger works the exact same way as it does between connectors. This means that any enabled workflow with a Webhook Trigger can be used to send, receive and change the information to hand.

By targeting the right key/ value pair, via the use of jsonpaths and connector property panel options, users are able to manipulate the data sources to suit their needs.

For example, users could extract some of the data from the trigger by using a 'Send Email' connector. This in turn would forward the information on to another colleague as per the operation selected states. Note that interpolation has been used in this example.

Users can use this method to send data to Salesforce, Slack, or any other service. The only limitation is your imagination.

Triggering an Event Reply

It is possible to send a reply to the service which sent the webhook data to your workflow, by using the 'Await workflow and respond' operation.

For example, after taking steps to process the data received, users may wish to respond with a 200 status and a "Successfully Recorded" message in the body.

Or, after making an unsuccessful boolean check for a user or valid url, you may wish to respond with a 404 'not found' message.

Please see our Trigger Event Reply documentation for details.

Security

Service

It is highly recommended that users secure their Webhook using the permission settings and unique identifiers available service side. This is to help make sure that users only receive requests from trusted sources and accounts/ individuals.

The options available to users will vary depending on your use case and the service itself (such as challenge codes, hashes, account ID's etc).

Tray.io

It is highly recommended that users secure their Webhook via the use of a CSRF token.

This is an advanced settings feature, and more details can be found under the below CSRF tokens heading.

CSRF tokens

A CSRF token is a unique hash usually generated by the server-side application (or service). This is then transmitted to the client (aka Tray.io). When the request is made, the service validates that the request includes the expected CSRF token. This is a continuous enabled check.

The security token will need to be matched with 'X-Crsf-Token HTTP' header value passed by the client, in order to successfully trigger the workflow.

Any calls which do not contain the x-csrf-token header, or contain an incorrect value, will receive an Invalid value for header: X-Csrf-Token response.

Test your security setup by using an API development environment such as Postman. Make a POST request to your Webhook Trigger public URL and add the same CSRF token as a header:

The output in the Debug panel should display the header as expected:

Manual CSRF tokens

If CSRF tokens are not available within your source service, users can manually add a token query to the webhook public URL.

For example, the user Webhook Trigger public URL might be: https://a9e4a8db-c123-4a12-12a3-013c00485c87.trayapp.io.

Users could then suffix a randomised token such as 90wLtzYZnj2378h3d2XNpoZhKtzEzVy to the end of the URL.

Note that like a server side generated token, this would need to be difficult to replicate and ideally randomised; using letters with alternative cases and numbers.

The resulting header should be similar to: https://a9e4a8db-c123-4a12-12a3-013c00485c87.trayapp.io?token=90wLtzYZnj2378h3d2XNpoZhKtzEzVy.

You can test this by using the same method outlined above (using an API development environment). This time, add a boolean connector as well and add Trigger Reply connector to confirm successful runs.

Webhook technical limitations

Payload size limitations

The typical size limit for a basic Webhook payload is 1MB.

File content can also be sent as multi-part http requests instead. These would have an overall size limit of 10MB.

Rate limiting

While the basic 'Auto respond with 200' operation is not, the 'Validate and respond' and 'Await workflow and respond' operations are subject to rate limiting.

If too many requests (i.e. several hundred per second) come in to your webhook trigger at once, Tray.io will respond with an HTTP 429 (too many requests) error.

Please be sure to throttle requests appropriately at the source third-party service.

Enabling CORS

For webhook requests originating from within the browser, users need to enable the CORS feature.

CORS is a system that allows browsers to send data to Tray.io across domains without triggering errors. This setting also adds a few headers to the Tray.io response, from the Tray.io webhook.

CORS is automatically turned off on by default. This will have implications on whether or not the webhook is be able to work with other browsers.

To enable CORS features, users must make sure 'Allow webhooks from browsers?' is checked within the advanced properties section. This is found behind the 'Show advanced properties' button on the input panel.

This option is only available for the following two operations. There is a notable difference between what happens when this feature is enabled, depending on the operation selected.

  1. Validate and respond

By enabling CORS with this operation, users add three headers:

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods

These three response headers placed within the response itself, prevent browsers from blocking said response.

  1. Await workflow and respond

When users have the CORS checkbox ticked when using the "await workflow" option, the trigger correctly sends back the response to the browser for a preflight request.

The workflow is kicked off, but the response is obscured by the browser unless users properly add the necessary access control headers manually.

Timeout

Users can set the number of milliseconds the Webhook Trigger will wait before timing out the incoming request.

This option is found behind the 'Show advanced properties' button within the input tab.

Operations

Auto respond with HTTP 200

This operation is not subject to rate limiting for requests coming in from a third-party

Regardless of what webhook request is received, the Webhook Trigger responds immediately with an HTTP 200 status code. This ensures execution but has no validation.

This is a fire and forget operation type, and is particularly useful for services that DO NOT have the option to retry webhook calls.

Use case

Having no validation in place means that the Webhook Trigger will always reply with a status code of 200, no matter what.

For example, the user has a theoretical service which does not retry webhook calls. This means that should the call 'fail' (i.e. return with any status code other than 200), the payload and data for that call will be lost.

Having an operation available that replies automatically with the 'correct' HTTP status code means that services with no re-try option like the one mentioned, will still be able to have their workflows run as expected without any payload losses.

Should the status codes pick up on anything wrong, it is recommended that users have a fallback in place within their workflows in order to handle this.

Validate and respond

This operation is subject to rate limiting.

If too many requests (i.e. several hundred per second) come in to your webhook trigger at once, Tray.io will respond with an HTTP 429 (too many requests) error

Please be sure to throttle requests appropriately in the source third-party service

A webhook request is received and validated. The Webhook Trigger responds to the webhook sender with a relevant HTTP status code.

This operation is best used when a service needs to check if the webhook has been successfully called or not. The Webhook Trigger will always reply with whatever HTTP status code is relevant to the current situation.

Services which are able to re-try webhook calls benefit most from using this operation.

Use case

Some services require clarification on how the webhook call is responding, ideally before continuing.

For example, a service may have called the Webhook Trigger but the call itself has failed some sort of validation test. The callback has returned a 400 code as a result. In theory, the service will automatically try to resend the call to make sure Tray.io gets the original payload as expected.

If the call continues to fail, and a successful status code is necessary before proceeding, ideally the service itself will have fallbacks in place in order to handle such an event.

If this is not the case, then Tray.io is able to catch the failed payload provided the user has put the correct implementation steps in place to handle such an event. This is highly recommended by Tray.io in order to prevent data loss.

Await workflow and respond

This operation is subject to rate limiting.

If too many requests (i.e. several hundred per second) come in to your webhook trigger at once, Tray.io will respond with an HTTP 429 (too many requests) error

Please be sure to throttle requests appropriately in the source third-party service

This allows you to configure your own response. A webhook request is received and the webhook trigger waits for the workflow to complete before replying.

This operation is best used when a service requires workflow completion, before checking to see if the webhook itself has been successfully called.

IMPORTANT!: It is mandatory to use this operation in conjunction with the Trigger Event Reply connector. The response has to be sent/ placed at the end of the workflow so that it is sent upon completion. This operation will not process accurately, without a returning a response to the source. This must only be done through the use of the Trigger Event Reply connector.

The operation checks that the payload is suitable, which in itself is its own form of validation, but does not return a HTTP status code. The workflow is then run. Upon successful completion of the workflow (aka, another validation type in itself), the Trigger Event Reply connector sends a response.

The lacking HTTP status code can be handled within the Trigger Event Reply connector step, as this connector has a 'Status' field available. The Trigger Event Reply connector needs to be placed at the end of said workflow, in order to send the response once the workflow is complete.

Services which are able to re-try webhook calls benefit most from using this operation.

Use case

Some services require the workflow to complete, before replying with a status code on how the webhook call is responding.

For example, a service may expect to call the Webhook Trigger and complete a series of workflow steps successfully before continuing, because it is the only way to collect the current payload, regardless of the HTTP status.

If the service is not able to catch the current payload - should the webhook reply with a non 200 status code - then the Tray.io workflow needs to collect the data for before responding. Otherwise the data would be lost.

In theory, if the call itself has failed some sort of validation test the service will automatically try to resend the call. This is to make sure Tray.io gets the original payload as expected. By having Tray.io handle the data collection before replying, both the payload and the status code is recorded without any data loss even if the call fails.

All Operations

Latest version:

2.3