Webhook authentication

You can add an extra layer of security to your webhook data by either marking the webhook as private or by setting an authentication method for it.

Private Webhook

All webhooks are public by default. You can mark an individual webhook as private by enabling the Private Webhook option.

When a webhook is marked as private, it cannot be accessed over a public network. It can only be accessed using API Gateway.

When the Private Webhook is enabled, the Webhook URL shows two distinct URLs -

Internal url - An internal endpoint is accessible only from webMethods network. You can view and copy the URL details using the copy icon alongside.

Note: The Internal url domain is subject to change. To ensure accuracy, verify the URL through the user interface.

Private url - A private endpoint is used when a private network is configured. Access is limited exclusively to your private network, preventing any outside access, including from your network or webMethods applications within your tenant. You can view and copy the URL details using the copy icon alongside.

Note: Support for domains with -internal will soon be deprecated, so you must reconfigure the alias in IBM webMethods API Gateway by using the Internal URL provided on the webhook configuration page once the Private Webhook is enabled.

Webhook Authentication Methods

You can optionally set an authentication method for your webhooks to enhance their security.

Note: All cloned, imported, and deployed workflows containing a webhook will by default have the webhook authentication method as Tenant Credentials irrespective of the webhook authentication method configured in the source workflow.

None

Select this option if you do not want to apply any authentication mechanism on your webhook data.

Tenant Credentials

You can secure the webhook by selecting the Tenant Credentials option. This will require the users of this webhook to provide the tenant credentials first before they can send an execution request.

Webhook Key

The webhook key functionality allows you to generate a secret webhook key, which you need to send in the headers as webhook_key while sending the webhook execution request.

To do this, click GENERATE TOKEN to generate a random token for webhook key (for example, 6f9a1854848sample663157d1460712634541)

Note:

If you enable Webhook Key authentication for your webhook, you will need to pass the webhook key in headers as Webhook Key each time you send the webhook execution request.
You can change the token at any time by clicking GENERATE TOKEN. If you change the token of your webhook, ensure that you send the updated token as the value of the Webhook Key in headers while sending the webhook execution request.

Autoconnect Return Data on Sync Webhook

You can optionally enable the Return Data on Sync Webhook action to automatically attach it as the last action of your workflow by enabling the toggle button. This action will fetch the workflow output and send it back to the webhook. Read more about How to use the Return Data on Sync Webhook action.

Note:

When you enable Return Data on Sync Webhook for your webhook, it expects a response within 180 seconds after the triggering event. If the response is not received within the specified period, the 408 Request Timeout error will appear. This error means that the server chooses to terminate the connection rather than continue waiting for the response.
However, if you are using any other web browsers, like Google Chrome, Microsoft Edge, other than Mozilla Firefox, you may observe automatic retries performed by the browser before getting the 408 Request Timeout error. This means, your browser is automatically making multiple requests to get a response, and hence, you may have to wait for more than 180 seconds before you see the 408 Request Timeout error.
If you are using services like Postman, and the response is not received within 180 seconds, the 408 Request Timeout error will appear soon after the timeout duration.

Once you have configured the required settings, click Next.