Webhooks
Author:
Fluent Commerce
Changed on:
5 May 2025
Overview
Fluent Commerce can post standard webhooks to a configured endpoint so that the third-party system can be notified or react to the provided . For example, common scenarios include status updates and shipping notifications.
Key points
- A webhook is a way for Orchestrated Workflow Logic to call back to an external application.
- Fluent Commerce provides some standard webhooks as Rules within the Rule Library for common third-party integrations.
- Since the payload and HTTP request cannot be customised, it is rarely necessary to implement a custom rule to send a webhook
A is a way for Orchestrated Logic to call back to an external application, such as a notification provider, client middleware, or ERP system. The Fluent Engine can post an to a configured endpoint so that the third-party system can be notified or react to the provided . For example, common scenarios include status updates and shipping notifications.
Webhooks provide the ability for external systems to rely on receiving the in real-time rather than having to poll the Fluent APIs for information.
When To Use a Webhook
Webhooks form part of the integration patterns provided by the Fluent Platform, and should be used when appropriate.
Use Case | Webhook? | Event API? | Examples |
Real-time Updates | ✅ | ❌ | Webhooks are perfect for individual orchestrated changes such as Status Updates, Shipping Notifications, etc. |
Bulk / High Load Batch Orchestration | ❌ | ✅ | Webhooks must NOT be used under high-load bulk orchestrations such as Batches. If required, the Event API may be used to query for information. |
Polling | ❌ | Rarely | Webhooks should not be used to poll any third party or external system, ever! We do not recommend polling the Fluent Platform via the Event API; however, if required, this should be done as optimally as possible and not too frequently. |
Standard Webhooks
Fluent Commerce provides some standard webhooks as Rules within the Library for common third-party integrations.
- SendWebhook Rule - see below.
- Email provider hook
- SMS provider hook
- Carrier aggregator hook
- Courier hook
Default SendWebhook Rule
`SendWebhook`
is a standard that can be added to any in a . The `SendWebhook`
is used to post the corresponding message to any endpoint that is specified.
The only accepts one parameter, which is the URL.
1{
2 "rules": [
3 {
4 "name": "FLUENTRETAIL.base.SendWebhook",
5 "props": { "url": "https://testwebhook.fluentretail.com/clicksend" }
6 }
7 ]
8}
The Editor can be used to add the to the in the that is triggered by the specific that needs to be captured:

Custom Webhooks
Since the payload and HTTP request cannot be customised, it is rarely necessary to implement a custom to send a . Rather, the recommended approach is to add a to your , naming the specific required, and simply add the SendWebhook to that , configured with the target URL. This will take the received by the and post it to the target URL.
Should you wish to enforce more validation on the interface for a particular , you can add rules that define required Attributes to be present prior to executing the itself.
Example :
SendOrderStatusUpdateToEcom |
ValidateEventAttribute |
ValidateEventAttribute |
ValidateEventAttribute |
SendWebhook |
Should you wish to perform any additional custom logic not available with composition of existing rules, you may wish to build your own using the Fluent SDK, and creating a custom . The custom will have access to an called `postWebhook`
.
For information on Fluent SDK, please check out the pages below.
Custom Webhook rule failure logic
By default, when a in a custom fails it reverts back to the default logic. To prevent this and use the logic set up in the custom , add the following Setting to any containing a custom .
` "settings": {"fc.rubix.sdk.webhook.retry.method":"preserve-event-details"}`
Learn more about adding settings to a Workflow.
Webhook Sample payload
All webhooks posted by the Fluent platform use the standard Model. This is the same as the API payload. More information can be found under Event API
The following is a sample payload for a :
1{
2 "id": "b34281d0-ada4-11e9-a1a7-5da7a83b9sd97cd",
3 "name": "OrderStatusChange",
4 "accountId": "ACME",
5 "retailerId": "1",
6 "rootEntityId": "123",
7 "rootEntityRef": "O_123",
8 "rootEntityType": "ORDER",
9 "entityId": "123",
10 "entityRef": "O_123",
11 "entityType": "ORDER",
12 "entityStatus": "SHIPPED",
13 "type": "NORMAL"
14}
Webhook Retries
There are two options for retry schedules, Exponential Back-off and 2 Second Intervals.
Option A: Exponential Back-off (recommended)
Error / Exception Type | Retries | Default Connection Timeout | Additional Read Timeout | Retry Interval | Retry Fallback Schedule | Retry Max Attempts |
Connection Timeout | ✅ | 10 seconds | 10 seconds | Exponential | Immediate, 1 minute, 1 hour, 1 day | 4 |
HTTP 4xx | ❌ | - | - | - | - | - |
HTTP 5xx | ❌ | - | - | - | - | - |
All others | ❌ | - | - | - | - | - |
If the request fails due to a connection timeout, the Engine will automatically reattempt the request four times.
The "Retry Delay" for every retry is as follows:
- Immediate: for random errors
- 1 minute: for short-term issues like rate limiting
- 1 hour: for scheduled downtimes
- 1 day: for production outages on the target environment
How to enable Exponential Back-off
To enable Exponential Back-off, add the following setting to the Settings Object in your :
`"settings": {"fc.rubix.sdk.webhook.retry.schedule":"exponential"}`
To learn how to enable Settings like this, see the adding a setting to a Workflow guide.
To learn more about available settings, see the Workflow Settings page.
Option B: 2 Second Intervals
Error / Exception Type | Retries | Default Connection Timeout | Additional Read Timeout | Retry Interval | Retry Fallback Formula | Retry Max Attempts |
Connection Timeout | ✅ | 10 seconds | 10 seconds | 2 seconds |
| 3 |
HTTP 4xx | ❌ | - | - | - | - | - |
HTTP 5xx | ❌ | - | - | - | - | - |
All others | ❌ | - | - | - | - | - |
If the request fails due to a connection timeout, the Engine will automatically reattempt the request three times.
The "Retry Delay" for every retry is calculated using the Retry Fallback Formula as below:
- Retry delay for 1st retry = [Math.pow(2, 0) * 2] = 2 seconds
- Retry delay for 2nd retry = [Math.pow(2, 1) * 2] = 4 second
- Retry delay for 3rd retry = [Math.pow(2, 2) * 2] = 8 seconds
Total Retry Delay after all 3 retries = 2 + 4 + 8 = 14 seconds.
How to enable 2 Second Intervals
This option is set as default and does not need to be enabled.
Webhook id
The that is sent as part of the requires the id field to ensure that the retries are executed correctly. For example, the following code has randomUUID set as id.
1Event event = Event.builder()
2 .id(UUID.randomUUID()) //REQUIRED
3 .name(action)
4 .accountId(incomingEvent.getAccountId())
5 .retailerId(incomingEvent.getRetailerId())
6 .entityId(invoiceId)
7 .entityRef(invoiceRef)
8 .entityType(incomingEvent.getEntityType())
9 .attributes(attributes)
10 .build();
11
12context.action().postWebhook(webhookEndpoint, event);
Webhook Exceptions
If the request fails more than the maximum amount of failures based on the chosen retry schedule, it will audit a `RetriesExceededException`
, and create an named `<RuleName> Exception`
. This can be used to execute a custom in your to act on this issue, such as sending an email or SMS notification.
Non-retry-able Webhook Exceptions
If the failed due to an issue in generating the digital signature for the request, then it will not retry since this is not considered a transient exception. Instead, this will be audited as an `ActionException`
in the audit events.
For more info on Signing, see Signature Validation.