Webhook filter = "tags:bopis" not delivering orders/updated when order has multiple tags

GraphQL Admin API Troubleshooting
1

Hi everyone,

I’m seeing some unexpected behavior with webhook delivery filtering for orders/updated and wanted to confirm whether this is a bug or if I’m misunderstanding how filters on tags are supposed to work.

Context

  • Admin API version: 2026-01
  • Topic: orders/updated (ORDERS_UPDATED)
  • Destination: AWS EventBridge → SQS
  • Webhook subscription created via Admin GraphQL, with a filter on order tags.

Webhook subscription (GraphQL result)

{
  "webhookSubscriptions": {
    "edges": [
      {
        "node": {
          "filter": "tags:bopis",
          "topic": "ORDERS_UPDATED",
          "includeFields": [],
          "id": "gid://shopify/WebhookSubscription/REDACTED"
        }
      }
    ]
  }
}

EventBridge rule

My EventBridge rule only routes by shop domain and topic (no filtering based on tags):

{
  "source": [{ "prefix": "aws.partner/shopify.com" }],
  "detail": {
    "metadata": {
      "X-Shopify-Shop-Domain": [
        { "prefix": "my-test-shop.myshopify.com" },
        { "wildcard": "my-test-shop" }
      ],
      "X-Shopify-Topic": [
        { "prefix": "orders/updated" },
        { "prefix": "ORDERS_UPDATED" }
      ]
    }
  }
}

There is no condition on tags in this EventBridge rule, so any orders/updated webhook that Shopify sends should reach SQS.

Problem

My goal: Receive orders/updated webhooks for any order that has the bopis tag, even if the order has other tags as well.

According to the docs for webhook filters and tag fields:

  • tags in the payload is a string of tags (for example: "bopis, some_other_tag").
  • A filter like tags:bopis should tokenize this string and match whenever at least one token equals bopis.
    Ref: Filter webhook deliveries – Tag fields

However, the behavior I’m seeing is:

  • When an order has only the bopis tag (e.g., "tags": "bopis"), updates do produce orders/updated webhooks that arrive at SQS.
  • When an order has multiple tags including bopis (e.g., "tags": "bopis, some_other_tag"), updates do not result in a webhook reaching SQS.

To be very clear:
If I don’t use a webhook filter at all, the same orders/updated event does reach SQS. When I enable filter = "tags:bopis", the event with "tags": "bopis, some_other_tag" disappears, but the event with "tags": "bopis" still comes through.

Example payload (when I expect it to match but it doesn’t)

Here is the relevant part of an orders/updated webhook payload that I only see when there is no filter applied (values redacted / generalized)

{
  "detail-type": "shopifyWebhook",
  "source": "aws.partner/shopify.com/REDACTED/CommerceWebhook",
  "detail": {
    "payload": {
      "id": 1234567890,
      "admin_graphql_api_id": "gid://shopify/Order/REDACTED",
      "...": "...",
      "tags": "bopis, some_other_tag",
      "updated_at": "2026-09-14T00:29:12-07:00"
    },
    "metadata": {
      "X-Shopify-Topic": "orders/updated",
      "X-Shopify-Shop-Domain": "my-test-shop.myshopify.com",
      "X-Shopify-API-Version": "2025-10",
      "...": "..."
    }
  }
}

With the filter tags:bopis in place, I never see this event at SQS, even though it clearly has bopis in the tags string.

What I expected

Based on the docs, I expected:

  • Any order where the tags field contains bopis as a tag (for example, "bopis", "bopis, some_other_tag", etc.) should satisfy tags:bopis, and orders/updated webhooks should be delivered.

Questions

  1. Is tags:bopis supposed to match when the order has multiple tags, like "bopis, some_other_tag"?
  2. Is there any known limitation or bug with webhook filters on tags for orders/updated?
  3. Is there a recommended alternative expression I should be using for this use case?

I’d really appreciate confirmation on whether this is expected behavior or a bug, and any guidance on how to reliably filter orders/updated by a specific order tag while still allowing other tags to be present.

Thanks!

2

Hi @Purushottam_Khedre! Good question, I had a look on a test store to check. No, tags:bopis isn’t supposed to match orders that carry other tags.

Tags are arrays in the data model, but they serialize as a single comma-joined string in the orders/updated payload, and the filter engine compares that whole string. So tags:bopis matches only when bopis is the entire tag string. I confirmed this live on API 2026-07 with a filter of tags:bopis*, which delivered for a single-tag order (payload “bopis-pickup”) but produced nothing for an order whose payload was “some_tag,bopis”, even though bopis was there as its own tag.

So this is expected behavior rather than a delivery issue, and your unfiltered events arriving as normal backs that up. The wildcard won’t help either. It matches the start of the joined string, so it’s ordering-dependent and would also match a distinct tag like bopis-pickup.

The supported route today is to subscribe without the tag condition and check the tags value in your handler. Feedback like this on per-tag matching is useful for the team to consider, so I’ve logged it internally. Thanks for raising this here!

3 
Two things worth checking while you wait for staff:
1) Isolate the filter from EventBridge. Create a second orders/updated subscription with the exact same filter, pointing at a plain HTTPS endpoint that just logs requests. Then update an order to tags "bopis, some_other_tag". If nothing arrives there either, it's the filter evaluation and not your EventBridge/SQS rule, and you have a clean repro (order ID + timestamp) for Shopify.
2) Try filter variants on that test subscription: tags:bopis*, or combine it with another field. The payload's tags field is one comma+space separated string ("bopis, some_other_tag"), so if tokenizing doesn't behave as the docs say, a wildcard can show you where it breaks.
As a fallback that can't miss events: subscribe without the tag filter (or filter on a cheaper field) and drop non-bopis orders in a small Lambda/EventBridge rule before SQS.
For the logging endpoint any request bin works (webhook.site), or MockLane, which I built (disclosure) - it keeps full headers and body so you can send Shopify the exact X-Shopify-Webhook-Id values.