Feature request: "Exists" filter support for JSON metafields

Custom Data
1

Hey folks,

JSON metafield types are currently excluded from the adminFilterable capability (docs reference). I understand why value-based filtering isn’t feasible for JSON - the structure is complex and querying by value wouldn’t be performant.

However, the existing query syntax already supports an “Exists” pattern (field:* / -field:*) that doesn’t require inspecting values at all. It would be very useful if JSON metafields could support at least this existence check, even without full value-based filtering.

A concrete example: our app writes a JSON metafield to orders containing pickup point details selected at checkout. Right now, if we want to find orders that went through our app, the only option is to paginate through all of a merchant’s orders via the API. For stores with large order volumes, this is slow, expensive, and unnecessary. Being able to query orders where metafields.namespace.key:* would let us - and the merchant - pull just the relevant subset directly.

This would unlock simple analytics use cases for apps without requiring heavy infrastructure, and give merchants an easy way to locate orders tied to specific app functionality.

Thanks for considering this!

2 Likes
2

Hey @Patrick_Jakubik

You can query through the definition itself to get back only the orders that have it set. The metafieldDefinitions.metafields.owner path lets you resolve the owning Order directly:

query {
  metafieldDefinitions(ownerType: ORDER, first: 1, 
    query: "namespace:your_app key:pickup_details") {
    nodes {
      metafieldsCount
      metafields(first: 50) {
        nodes {
          owner {
            ... on Order { id name createdAt }
          }
        }
      }
    }
  }
}

The main limitation is that you can’t combine this with other order-level filters (date range, fulfillment status, etc.) in the same query You’d need to filter client-side or take the returned order IDs and run a follow-up query. Not a full replacement for native field:* syntax, but it directly solves the core problem of avoiding full-catalog pagination.

For the analytics side of your request, check out the new analyticsQueryable capability for metafield definitions. Once enabled on your definition, the metafield becomes available as a dimension and filter in ShopifyQL and Shopify Analytics. That could cover the “simple analytics” use case you mentioned without needing any custom infrastructure.

3

Thanks Kyle, I wasn’t aware of querying through the definition itself - that’s an interesting approach. Unfortunately for our use case we need to combine this with other order-level filters (date ranges, fulfillment status, etc.), so having to fetch everything first and filter client-side kind of defeats the purpose.

As for analyticsQueryable - great suggestion, but it doesn’t seem to support JSON metafields either. When I try to enable it on a JSON definition I get:

"message": "The capability analytics_queryable is not valid for this definition.",
"code": "INVALID_CAPABILITY"

So both adminFilterable and analyticsQueryable exclude JSON types, which brings us back to the original request.

4

@Patrick_Jakubik Hey :waving_hand: Your original message said that you were really just trying to flag which orders came through your app, or were created through specific app functionality.

Is there a reason not to have a simple metafield (or tag?) that identifies your app as the source of the order? I understand it’s another metafield definition to create and another metafield to add, or a tag to add.

Never is a long time, but it’s unlikely that that Analytics will support querying arbitrary JSON metafields so I wouldn’t rely on that support being available to make this work.

1 Like
5

Hey Nick,

We use a single JSON metafield for a few reasons, but the main one is that we need a single atomic write. We set the metafield during checkout, and the available APIs don’t support updating multiple metafields in one operation. A single metafield gives us one source of truth with no sync issues. Adding a second, simpler metafield (or tag) just to work around the filtering limitation means maintaining two pieces of data that represent the same information, with all the sync and cleanup overhead that comes with it.

We’re a public app and have processed millions of orders - backfilling a second metafield across all of those would be a significant number of API calls, and we’re not comfortable modifying old orders we’ve already written to.

As for tags - we’d rather not touch the merchant’s tag workflow unless they explicitly opt in. Tags are also easy for merchants to accidentally remove, which would silently skew any analytics built on top of them. And again, keeping a tag in sync with the metafield introduces another point of failure.

There’s also the fact that we have other apps writing to the same metafield namespace/key. Orchestrating a parallel flag across multiple apps adds complexity we’d rather avoid.

All of these are workarounds for what seems like a small platform gap: the field:* existence check doesn’t need to inspect JSON values - it just needs to know the metafield is present. That’s a fundamentally different operation from value-based filtering, and it could work for JSON without running into the complexity concerns that justify excluding JSON from adminFilterable today.

This probably affects other apps too. Any app that writes structured data to an order (or product, or customer) and wants to let merchants filter by “has this data” vs “doesn’t” runs into the same gap.