fc.rubix.webhook.retry.event
Setting
Changed on:
5 Nov 2026
| Setting Area | Workflow |
|---|---|
| Supported context levels: | ACCOUNT |
Overview
This setting is a feature toggle that controls which event a failed webhook is retried with.By default, the retry uses the webhook event, which is the event that triggered the ruleset in which the webhook action was produced. A webhook reached through inline events is then retried for its own ruleset and entity, with the attributes of the original call.Values
| Data Type | Values |
|---|---|
| STRING | Default Value(s):
|
Detailed technical description
Webhook Retry Behavior
The setting switches between the following behaviors:- Default behavior:
- A failed webhook is retried with the webhook event, which is the event that triggered the ruleset in which the webhook action was produced. The retry has the name, entity, and attributes of that event, so it repeats the original call. After the final retry, the
`<WebhookRulesetName> Exception`event is raised for that ruleset and entity. This is valid under the following conditions:- The
`fc.rubix.webhook.retry.event`setting is created with the`webhook-event`value set - The
`fc.rubix.webhook.retry.event`setting is created with any other value - The
`fc.rubix.webhook.retry.event`setting is not created or not present
- The
- Previous behavior:
A failed webhook is retried with the initial event, which is the event that started the event context. When the webhook event is an inline event, the retry has the name, entity, and attributes of the initial event, so it’s a different call from the original one. If the receiving system responds, with any HTTP status code, the retry counts as delivered and the original call isn’t sent again. After the final retry, the`<InitialRulesetName> Exception`event is raised for the ruleset and entity of the initial event. This is valid under the following conditions:- The
`fc.rubix.webhook.retry.event`setting is created with the`initial-event`value set (the value is case-insensitive)
- The
Scope
- The setting changes only the event a webhook is retried with. The number of retries is the same for both values
- Only the webhook is sent again. The other rules of the ruleset in which the webhook action was produced aren’t run again
- With
`fc.rubix.sdk.webhook.retry.method`set to`preserve-event-details`, the rule that produced the webhook action is rerun with both values: with`webhook-event`on the webhook event, with`initial-event`on the initial event - With
`webhook-event`, the Send Webhook audit events of a webhook reached through inline events reference the entity of the webhook. With`initial-event`, they can reference the entity of the initial event of the event context - Allow up to 5 minutes for a change to the setting to take effect. It applies to event contexts that start after that
Explanation through an Example
The`CREATE` ruleset of an Order sends an inline event that triggers the `NotifyCarrier` ruleset of a Fulfillment. The webhook action produced in `NotifyCarrier` fails:`webhook-event`: the retry uses the`NotifyCarrier`event, with the Fulfillment and the attributes of the original call. After the final retry, the`NotifyCarrier Exception`event is raised for the Fulfillment`initial-event`: the retry uses the Order`CREATE`event, with the Order and the attributes of that event. After the final retry, the`CREATE Exception`event is raised for the Order
Configuration example
1POST {{fluentApiHost}}/graphql
2
3mutation CreateSetting {
4 createSetting(input: {
5 name: "fc.rubix.webhook.retry.event",
6 valueType: "STRING",
7 value: "initial-event",
8 context: "ACCOUNT",
9 contextId: 0
10 }) {
11 id
12 name
13 }
14}Update example
1POST {{fluentApiHost}}/graphql
2
3mutation updateSetting {
4 updateSetting(input: {
5 id: 123,
6 name: "fc.rubix.webhook.retry.event",
7 valueType: "STRING",
8 value:"webhook-event",
9 context: "ACCOUNT",
10 contextId: 0
11 }) {
12 id
13 name
14 }
15}