Orders Create webhook not firing but Orders Updated is

Webhooks and Events
1

I am having issues with the orders_create webhook not firing when I place an order. I also had trouble with the orders_updated but that seems to be 50/50 whether they fire or not now after some combination of adding/removing the webhook and then doing shopify app dev and shopify app deployshennanigans.

  [[webhooks.subscriptions]]
  topics = ["orders/create"]
  uri = "/webhooks/orders_create"
  include_fields = ["id", "updated_at", "line_items.properties.name", "discount_allocations", "note_attributes"]
  filter = "line_items.properties.name:_rental_intent_token OR line_items.properties.name:_cycle OR line_items.properties.name:_credit_allowance OR line_items.properties.name:Charge OR line_items.properties.name:rental_id OR note_attributes.name:_supercycle_track"

  [[webhooks.subscriptions]]
  topics = ["orders/updated"]
  uri = "/webhooks/orders_updated"
  include_fields = ["id", "updated_at", "line_items.properties.name", "discount_allocations", "note_attributes"]
  filter = "line_items.properties.name:_rental_intent_token OR line_items.properties.name:_cycle OR line_items.properties.name:_credit_allowance OR line_items.properties.name:Charge OR line_items.properties.name:rental_id OR note_attributes.name:_supercycle_track"

I am struggling as this is hindering local development of our app.

2

Looks like they are working, just the webhook issue happening right now is delaying them being sent.

3

There appears to be a delay with webhooks, and the Shopify webhooks team is addressing the issue.

4

Okay, I’m still having an issue where webhooks for orders will work for a bit, then just stop being sent by Shopify

5

"I ran into this on a Shopify app I shipped a while back. For me, the bug wasn’t actually that orders/create didn’t fire, it was that orders/updated fired before orders/create for the same order, and depending on how your handler is built, the create either no-ops or errors silently when it eventually lands.

Quick way to confirm before changing anything: in the webhook delivery log on the Shopify Dev dashboard, filter by the X-Shopify-Order-Id of one of the affected orders and look at timestamps for both topics. If you see an orders/updated with that order ID before any orders/create, that’s the pattern.

The fix that worked for me, assumes you own the handler and can return arbitrary status codes, was to reject the first orders/updated for any order ID I had not yet seen with a 409 Conflict. Shopify treats non-2xx as a failed delivery and retries on its standard backoff. Meanwhile orders/create arrives, you process it and return 200, the order is in your DB, and the retried update lands in sequence and processes normally. End-to-end idempotency without changing how Shopify sends.

The bigger thing I wish I’d known earlier: orders/updated is extraordinarily noisy. It fires for tag changes, fulfillment status, financial status, note edits, line-item metafield edits, risk-score updates — dozens of distinct reasons. Once you can actually see the stream of update events for a single order’s lifetime, you can be much more surgical about which ones your handler reacts to. I ended up wanting a delivery log I could replay against my handler while I sorted through the reason taxonomy, which is what prompted me to build FlurryPORT. Either way, the 409 trick should unstick your immediate problem.

One caveat: if you’re on Shopify’s managed-webhook flow inside an app template that returns 200 unconditionally, the 409 trick doesn’t apply — you’ll want idempotency-via-DB-uniqueness or a small queue-and-reconcile layer instead.