How to Configure Webhooks to Fluid Boards Integration

Webhooks let you subscribe to events happening in a Fluid and automatically receive a delivery of data to your server whenever those events occur.

When an event that your webhook is subscribed to occurs, Fluid will send an HTTP request with data about the event to the URL that you specified. If your server is set up to listen for webhook deliveries at that URL, it can take action when it receives one.

On a Fluid board the events are based on the Actions/Cards that form part of the board. The events supported are Create, Update and Delete. Whenever one of these events occurs on an Action for the board, your webhook will be called. 

To start off, navigate to the integrations options on your board from the the Tools tab. 

Once the Integration options is selected and the dialog opens, you will then be able to select the integration for Action Webhooks.

The following dialog will present the Set Up page where the integration details for the board can be completed. 

You can learn more about how to initially create a board in Fluid by clicking here. 

Each of the sections for the integration details are as follows:

Fluid supports Shared secret, PAT tokens or Basic Authentication for access to your webhook url endpoint. Project managers should work with their internal IT teams to provide the information below as part of the setup requirements.

NOTE: All password/secrets are stored securely and encrypted in our cloud keyvault. All access to the keyvault is authenticated.

A shared secret is a signature that is added to the webhook payload that is verified by your organisation on delivery. The secret value is used to sign the payload using SHA-256

You should set a webhook secret for your webhook and verify that the signature of each webhook delivery matches the secret. This helps to ensure that the webhook delivery is from Fluid. For more information, see Validating Webhooks

The webhook secret should be a random string of text with high entropy. You should securely store your webhook secret in a way that your server can access.

PAT tokens are generated from your systems, these are bearer tokens that will be passed to the url endpoint in the Authorization header. Your systems will then verify the bearer token and allow access if authenticated/authorized.

This is the username and password details that will be passed in the Authorization header. Your systems will then verify the username and password and allow access if authenticated/authorized.

Define a comma delimited list of fields you want to include as part of the payload for the webhook. eg. if you only want to receive the Title and Description properties of the Action, then use "Title,Description" 

If not set, then a predetermined default list of fields will be used.

Only set values here if you want to streamline the data payload that is sent as part of the webhook request. Reducing payload size will increase performance when parsing results.

Note: Request parameters only apply to the Action Entity itself.

Define a comma delimited list of optional data you want to include as part of the payload for the webhook. eg. if you want to receive the Chats of the Action, then use "Chats" or "Chat,Related" for both Chat and Related.

If not set, then no expanded options will be returned. You will receive the standard default set of data for an Action.

Supported expand options include:

• All

  Will expand all available options for the action and return the full set of data.

• Method

  Will include Method data for the Action. Methods are URL links to specific calls that can be made on this action. They are helper URLs.

• Related

  Any other actions that are related to this Action

• Chats

  Comments/Chat information available for this Action.

Define the type of events you want to receive webhook messages for. You can toggle Yes/No to control what events will be sent.

• How to Configure Webhooks with Power Automate