We are forced to use a “Webhook-to-Fetch” pattern (listening for a webhook, then immediately triggering a heavy GraphQL query) because the webhook payloads lack the necessary assignedLocation and FulfillmentOrder status data.
The Problem: To properly calculate inventory, we need to know which Location a FulfillmentOrder is assigned to before it is fulfilled (i.e., when it is OPEN or IN_PROGRESS).
-
orders/updatedis insufficient: The payload contains the legacyfulfillmentslist (shipped items) but does not include thefulfillment_ordersgraph. It does not tell us which location the unfulfilled items are currently assigned to. -
fulfillment_orders/order_routing_completeis empty: This webhook signals that routing is done, but the payload does not contain the resultingassignedLocation. It forces an immediate API call to find out where the items went. -
Specific Topics are Restricted: Webhooks like
fulfillment_orders/movedorfulfillment_orders/splitseem restricted to apps registered explicitly as a Fulfillment Service. Standard IMS apps managing “Merchant Managed” locations do not reliably receive these events.
The Consequence (Inefficiency): To ensure data integrity, we have to fire a standard GraphQL query every time an order is touched.
The Request: Please enable one of the following solutions for standard public apps:
Option A (Preferred): A comprehensive fulfillment_orders/updated webhook Create a generic webhook that fires whenever a FulfillmentOrder changes state (created, moved, held, split) that includes the following fields in the payload:
-
id -
status(OPEN, IN_PROGRESS, etc.) -
assigned_location_id -
line_items(with quantities)
Option B: Enrich orders/updated Include the fulfillment_orders node within the standard orders/updated JSON payload, specifically exposing the assigned_location_id.
This would be really great and an important improvement for application.
Thanks a lot! ![]()