Expose granular FulfillmentOrder data in generic Webhooks to eliminate redundant API fetching

Webhooks and Events
1

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).

  1. orders/updated is insufficient: The payload contains the legacy fulfillments list (shipped items) but does not include the fulfillment_orders graph. It does not tell us which location the unfulfilled items are currently assigned to.

  2. fulfillment_orders/order_routing_complete is empty: This webhook signals that routing is done, but the payload does not contain the resulting assignedLocation. It forces an immediate API call to find out where the items went.

  3. Specific Topics are Restricted: Webhooks like fulfillment_orders/moved or fulfillment_orders/split seem 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! :slight_smile:

1 Like
2

Hey @M_Athory, thanks for the detailed feedback on this. I’ve submitted this to our product team:

The core issue: Fulfillment order webhooks (orders/updated, fulfillment_orders/order_routing_complete) lack essential data. Specifically assignedLocation and status, forcing IMS apps into a “Webhook-to-Fetch” pattern where you listen for a webhook then immediately fire a GraphQL query to get the data you actually need.

Your requested solutions:

  • Option A: A comprehensive fulfillment_orders/updated webhook that fires on state changes and includes id, status, assigned_location_id, and line_items
  • Option B: Enrich orders/updated to include the fulfillment_orders node with assigned_location_id

Since these would likely be versioned releases, any changes will be posted in the developers changelog.

Thanks again!

1 Like