Orders/create webhook works with CLI trigger but not with real orders

Hi Shopify team/community,

I’m facing an issue with an orders/create webhook in a Shopify app using the React Router template.

I also tested this with a new Shopify app and a new development store, but I’m seeing the same behavior.

My shopify.app.toml contains:

[webhooks]
api_version = “2026-07”

[[webhooks.subscriptions]]
topics = [“orders/create”]
uri = “/webhooks/app/orders_create”

My route is:
app/routes/webhooks.app.orders_create.tsx

The handler just logs:
console.log(“========Received orders/create webhook request=========”);

What I have tested
The CLI webhook trigger works:
shopify app webhook trigger --topic orders/create

It successfully delivers to my endpoint, and I can see the log.

So the route itself is working.

However, when I create an actual order in the development store, the webhook route is never hit. The log does not appear.

I also checked the app logs/monitoring in the Shopify Dev Dashboard, and there is no webhook delivery/trigger shown for the real order at all - not a failed one, just nothing.

I’m currently using shopify app dev with a TryCloudflare URL.
I also queried the Admin GraphQL API:
query {
webhookSubscriptions(first: 50) {
nodes {
id
topic
uri
format
}
}
}

This returned an empty list. I understand TOML-managed/app-specific subscriptions don’t show up in this query anyway, so I’m not treating this as proof of anything by itself.

What I have already tried

  • shopify app dev
  • shopify app deploy
  • Restarting shopify app dev
  • Creating new test orders
  • shopify app webhook trigger --topic orders/create
  • Testing with a brand new Shopify app
  • Testing with a brand new development store
  • Confirmed the webhook route works fine with the CLI trigger
  • Checked Dev Dashboard logs - no delivery attempt shown for real orders

My question

What could cause a TOML-declared orders/create webhook to work fine with shopify app webhook trigger, but never actually get delivered when a real order is placed — especially since this happens even on a fresh app and fresh dev store?

Is there some extra registration/activation step needed beyond dev and deploy for real store events to start flowing, and what’s the best way to confirm from Shopify’s side whether the subscription is actually live for a given store install?

Any guidance would be appreciated.

Hey @Ashwanth_Raj - thanks for reaching out.

I did some digging here, and shopify app webhook trigger sends a synthetic webhook directly to the selected address and doesn’t validate the store’s subscription configuration. A successful trigger confirms that the endpoint can receive the request, but not that the orders/create subscription is active: app webhook trigger

The first thing I’d check is the app’s granted scopes. orders/create requires either read_orders or read_marketplace_orders: WebhookSubscriptionTopic - GraphQL Admin

Could you share your [access_scopes] configuration and the result of this query?

query {
  currentAppInstallation {
    accessScopes {
      handle
    }
  }
}

If you’re comfortable sharing your app ID and the shop ID of your dev store as well, I can look into the specific config on our end. If you’d prefer to set up a DM, please let me know and I can do that as well.

Hope this helps!

Thanks for your help.

I checked the granted access scopes using currentAppInstallation, and read_orders is definitely granted on the app installation.

The complete result is:

{
  "data": {
    "currentAppInstallation": {
      "accessScopes": [
        {
          "handle": "customer_read_customers"
        },
        {
          "handle": "customer_write_customers"
        },
        {
          "handle": "read_customers"
        },
        {
          "handle": "read_discounts"
        },
        {
          "handle": "read_metaobject_definitions"
        },
        {
          "handle": "read_metaobjects"
        },
        {
          "handle": "read_orders"
        },
        {
          "handle": "read_products"
        },
        {
          "handle": "read_publications"
        },
        {
          "handle": "read_themes"
        },
        {
          "handle": "write_customers"
        },
        {
          "handle": "write_discounts"
        },
        {
          "handle": "write_metaobject_definitions"
        },
        {
          "handle": "write_metaobjects"
        },
        {
          "handle": "write_products"
        },
        {
          "handle": "write_publications"
        }
      ]
    }
  }
}

My [access_scopes] configuration is also:

[access_scopes]
scopes = "read_metaobject_definitions,write_metaobject_definitions,read_metaobjects,write_metaobjects,read_customers,write_customers,read_products,write_publications,write_products,read_discounts,write_discounts,read_publications,read_orders,customer_read_customers,customer_write_customers,read_themes"

So read_orders is present both in the app configuration and in the actual granted scopes.

I also tested this with a new Shopify app and a new development store, but the issue still occurs.

shopify app webhook trigger --topic orders/create successfully reaches my endpoint, but creating a real order does not trigger the webhook. I also checked the app logs/webhook monitoring in the Dev Dashboard, and there is no delivery attempt for the real order.

Here are the IDs for investigation:

App ID: gid://shopify/App/414917099521
Development store ID: gid://shopify/Shop/101982732564
Store: new-plus-peb2yfcg.myshopify.com

Could you please check the app/store configuration on your side and help determine why the real orders/create event is not generating a webhook delivery?

Please let me know if you need any additional information.

Hey @Wes-Dev-Shopify - could you please help with this when you get a chance? Thank you!

Hey @Ashwanth_Raj - thanks for sharing the app and shop IDs.

I checked the configuration on our end. The app version released on August 25, 2026 at 09:24 UTC contains subscriptions for orders/create, orders/edited, and app/uninstalled, but their destinations resolve to https://example.com/....

The uri values in your TOML are relative paths, so a released version resolves them against its configured application_url. For example, application_url = "https://example.com" combined with uri = "/webhooks/app/orders_create" produces https://example.com/webhooks/app/orders_create.

Local development works differently. While shopify app dev is running with [build].automatically_update_urls_on_dev = true, Shopify CLI creates a Cloudflare Quick Tunnel and updates the selected development store’s preview to use it. You don’t need to copy that generated tunnel URL into your TOML.

If you intentionally want to manage a specific tunnel URL yourself, use a separate development configuration whose application_url points to that tunnel, set [build].automatically_update_urls_on_dev = false, and run shopify app dev --tunnel-url=<your-tunnel-url>. You don’t need to deploy or release that configuration for local testing because app dev creates the development preview. The bring-your-own-tunnel workflow is documented here: Select a networking option for local development

I also checked the real orders created on August 25 and August 27. Shopify generated orders/create events for them, but your app wasn’t included among the active matching subscriptions, so the requests weren’t reaching and failing inside your route.

Please check that Shopify CLI is using the intended configuration file, start shopify app dev, and confirm in the Dev Console that the active preview shows the correct tunnel URL for these webhook destinations. Then create another order while the development session is running. For a deployed version, replace https://example.com with your hosted production app URL before running shopify app deploy: App configuration

If the webhook still doesn’t arrive, share the new order’s UTC creation time and I can check that event. Hope this helps!

Thanks for checking and explaining this clearly. I understand the issue now. I’ll verify the configuration, test it again locally, and make sure the production URL is set correctly before deploying. Thanks again for your help!