Multi-Retailer Return Orders, Stock Totals by Condition and Storage Area, and Webhook Retries on the Right Entity
Release
Author:
Kirill Gaiduk
Changed on:
6 Nov 2026
| Target release date: | 2026-11-09 |
|---|---|
| Release status: | Released |
Description
This release includes the following improvements:- Multi-Retailer setups: Users who work with several Retailers can now create Return Orders and Fulfillment Options for a Retailer other than their own. Each entity is processed by the workflow of the Retailer it belongs to. For Return Orders, existing accounts keep their current behavior until the
`fc.graphql.returnOrder.create.event`setting is changed - Inventory Quantity filters: The filters are now consistent across GraphQL queries and mutations, so you can aggregate and update segmented stock by condition and storage area
- Webhook retries: A failed webhook is now retried with the event that triggered its ruleset, instead of the initial event of the event context, so the retry keeps the original event name, entity, and attributes. Existing accounts keep their current behavior until the
`fc.rubix.webhook.retry.event`setting is changed
Changelog
GraphQL API- Return Orders and Fulfillment Options created for another Retailer now start the workflow of that Retailer. The
`CREATE`event is generated with the Retailer of the new entity, instead of the Retailer of the user who makes the call. In a multi-Retailer setup, a single user can now create Return Orders and Fulfillment Options for several Retailers with the`createReturnOrder`and`createFulfilmentOption`mutations- For Return Orders, the behavior is controlled by the new account setting
`fc.graphql.returnOrder.create.event`:`normal`uses the Retailer of the Return Order,`disable-cross-retailer`keeps the Retailer of the user. Orders keep using`fc.graphql.order.create.event` - Fulfillment Options always use the Retailer of the Fulfillment Option
- For Return Orders, the behavior is controlled by the new account setting
- The
`condition`and`storageAreaRef`filters are now available in the`inventoryQuantityAggregate`query, the`InventoryPosition.quantitiesAggregate`and`InventoryQuantity.quantitiesAggregate`fields, and the`updateInventoryQuantityChildren`mutation, so stock can be totaled and updated per condition and storage area. See Stock Segmentation - Data Model and API Overview - The
`updateInventoryQuantitiesStatus`mutation now accepts the same 13 Inventory Quantity filters as the queries:`condition`,`storageAreaRef`,`expiresOn`,`associationType`,`associationRef`,`countryOfOrigin`,`channel`,`manufacturer`,`manufacturerBatchNumber`,`supplier`,`segment1`,`segment2`, and`segment3` - The new filters match values exactly and ignore case. Aggregate queries that use them respond as fast as before
- A failed webhook can now be 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. With
`webhook-event`, a webhook reached through inline events is no longer retried with the initial event of the event context, and after the final retry the`<RulesetName> Exception`event is raised for the ruleset and entity of the webhook event. The Send Webhook audit events of such a webhook also reference the entity of the webhook event - The retry event is controlled by the new account setting
`fc.rubix.webhook.retry.event`:`webhook-event`retries with the webhook event,`initial-event`retries with the initial event of the event context. Allow up to 5 minutes for a change to the setting to take effect - With
`fc.rubix.sdk.webhook.retry.method`set to`preserve-event-details`and`fc.rubix.webhook.retry.event`set to`webhook-event`, the rule that produced the webhook action runs again with the webhook event
Limitations
- Existing accounts keep the previous behavior:
`fc.graphql.returnOrder.create.event`is set to`disable-cross-retailer`and`fc.rubix.webhook.retry.event`to`initial-event`. New accounts are created with`normal`and`webhook-event`. To use the new behavior on an existing account, update the settings. See Account Settings - With
`initial-event`, a webhook reached through inline events is retried with the initial event. If the receiving system responds, the retry counts as delivered, the original call isn’t sent again, and the failure goes unnoticed. To decide whether to switch to`webhook-event`, see Webhook Retries and Inline Events - Before you set
`fc.rubix.webhook.retry.event`to`webhook-event`, check the workflows that handle the Exception event of a webhook reached through inline events. The Exception event is raised for the ruleset that contains the webhook, so the workflow needs a`<WebhookRulesetName> Exception`ruleset for the entity type of that ruleset, with triggers for every status the entity can be in when the final retry fails - For custom webhook rules and the reference
`SendWebhook`rule, add`preserve-event-details`to the workflow, so the retry reruns the rule that produced the webhook action. Check first that the rule can run more than once. See`fc.rubix.sdk.webhook.retry.method`
| Released capability depth: | Enhancement |
|---|---|
| Release bundle / Capability type: | Platform |
