Webhooks

Assemblified subscribes to twelve Shopify webhook topics: seven core topics that drive inventory and lifecycle automation, plus five fulfillment-order lifecycle topics that drive per-location features such as order reservations.

You don’t have to create any of these by hand. They are registered for you when you install the app, and re-checked afterwards — see How subscriptions stay current at the bottom of this page.

The seven core topics

Topic	What it does in Assemblified
app/uninstalled	Cleans up after you. Your session ends, any AI connector grants are revoked, a store group you belonged to is told you have left, and the shop’s Assemblified data is deleted.
orders/updated	The main execution trigger. A new, edited, cancelled or refunded order arrives here, and Assemblified works out which bills it touches and which components to deduct or restore.
app_subscriptions/update	Keeps your plan up to date when you upgrade, downgrade, or a charge lapses — and re-checks your multi-store entitlement, because a plan change can pause a store group.
fulfillments/create	A fulfillment was created. Used to deduct (or record) at the location the goods actually shipped from.
fulfillments/update	A fulfillment changed. Handled on the same path as fulfillments/create.
products/update	A product or variant changed in Shopify. Assemblified refreshes the raw materials bound to those variants — title, SKU, image, cost and tracked quantity — and notices variants it does not yet know about.
inventory_items/update	An inventory item’s cost or tracking setting changed in Shopify. Assemblified updates the matching raw material so your bill costs stay right.

orders/updated is the only order topic Assemblified acts on. Shopify also offers orders/create, orders/edited and orders/cancelled, but each of those describes a change orders/updated already reports, and acting on both would process the same order twice — so they are not subscribed, and are ignored if one arrives anyway.

Orders created before you installed the app are skipped, so installing Assemblified never re-runs your back catalogue. To process historical orders on purpose, use Historical orders.

The five fulfillment-order topics

Topic	What it does in Assemblified
fulfillment_orders/order_routing_complete	Shopify has decided which location will ship the order. Commit (or hold) the reservation at that location.
fulfillment_orders/placed_on_hold	Release the reservation back to available and mark it held.
fulfillment_orders/hold_released	Re-commit the held reservation.
fulfillment_orders/moved	Release at the source location and commit at the destination, as one step.
fulfillment_orders/cancelled	Release the reservation back to available.

These five are gated on one setting, not two. They are acted on when multi-location sensitive adjustments is on. With it off, the topics are still subscribed but Assemblified does nothing with them — your shop is being treated as a single-location shop, so there is no per-location decision to make.

Order reservations chooses the mode, it does not gate the topics. With order reservations on, these webhooks reserve stock: quantities move from available to reserved when Shopify routes the order. With order reservations off, the same webhooks still run, in tracking mode: they record which location each fulfillment order is destined for, with no stock movement at all, and the deduction happens when the fulfillment itself arrives. That is what lets an order that splits across several locations, or ships in several fulfillments, deduct in the right place each time.

See Order reservations for the full flow.

The topic Assemblified deliberately does not subscribe to

Shopify offers inventory_levels/update, which fires whenever a stock number changes. Assemblified does not subscribe to it, on purpose.

That topic reports an absolute level after the fact, with no indication of what caused it. Assemblified’s own adjustments would come straight back through it, and a movement already applied would be applied a second time. Shopify-tracked quantities are refreshed through products/update instead, which is tied to the product that changed rather than to the movement.

If a delivery of that topic ever reaches the app, it is accepted and discarded.

How subscriptions stay current

Every subscription points at an address Shopify delivers to. If that address changes, every stored subscription is stale and has to be repointed, or deliveries stop arriving.

Assemblified handles this in the background:

• Subscriptions are registered when you install the app and whenever you re-authorise it.
• Beyond that, the app re-checks its own subscriptions periodically while you use it. Missing topics are created, topics pointing at an old address are repointed, and duplicates left over from an earlier one are removed.
• A change of address forces an immediate re-check, regardless of when the last one ran.

The Set up Assemblified card on the Home page reports the result: “Webhooks checked 3h ago”, or “Webhook check pending” when no successful check has been recorded yet. Pending is normal right after install and should clear on its own within a few page views; if it persists for days, re-open the app from your Shopify admin so it can re-authorise.

Delivery failures

Shopify retries a webhook it could not deliver. Assemblified answers an error rather than a success when it genuinely failed to take the work on, precisely so that Shopify’s retry does its job. Repeated failures show up on the Logs page as failed runs, with the reason attached — see Read and repair the execution logs. That page, not this one, is where you diagnose a specific order.