Events query complexity limit is changing to 100 points

Webhooks and Events
1

We’re reducing the query complexity limit for Events subscriptions from 250 to 100 points. If your use case needs more than 100 points, we’re open to discussing an exception case by case. Classic Webhook subscriptions are unaffected.

To put it into perspective, this entire query costs 100 points:

query productCatalogDetails($productId: ID!) {
  product(id: $productId) {
    id
    title
    handle
    status
    vendor
    productType
    tags
    descriptionHtml
    onlineStoreUrl
    totalInventory
    isGiftCard
    createdAt
    updatedAt
    seo {
      title
      description
    }
    options {
      id
      name
      position
      optionValues {
        id
        name
        hasVariants
        linkedMetafieldValue
      }
    }
    metafields(first: 10) {
      nodes {
        id
        namespace
        key
        type
        value
      }
    }
    variants(first: 250) {
      nodes {
        id
        title
        sku
        price
        compareAtPrice
        taxable
        position
        availableForSale
        inventoryPolicy
        inventoryQuantity
        sellableOnlineQuantity
        requiresComponents
        createdAt
        updatedAt
        selectedOptions {
          name
          value
        }
        metafields(first: 10) {
          nodes {
            id
            namespace
            key
            type
            value
          }
        }
      }
    }
  }
}

That’s Product details, SEO, options, up to 250 variants, and metafields, all within 100 points. Use that room for the data your app needs to act on each change.

Optimizing your Events subscriptions

Events lets you choose which changes your app receives and what data comes with them. Triggers select the changes, and your query selects the data your handler needs to process them. Start with what your app needs to do when something changes, then shape the subscription around that work.

For example, when a variant’s price changes, your handler may only need that variant’s price, SKU, and parent Product ID. Fetching the Product and its first 250 variants each time also brings back unchanged siblings, and the changed variant might fall outside that first page. Querying the affected variant directly avoids that repeated work.

You can configure multiple subscriptions for the same topic, each with its own triggers and query. Here’s how to separate product creation from variant price changes:

[[events.subscription]]
handle = "product_created"
topic = "Product"
actions = ["create"]
uri = "/api/events/products"

query = """
query productCreated($productId: ID!) {
  product(id: $productId) {
    id
    title
    status
  }
}
"""

[[events.subscription]]
handle = "product_variant_changed"
topic = "Product"
actions = ["update"]
triggers = ["product.variants.price"]
uri = "/api/events/products"

query = """
query variantChanged($variantsId: ID!) {
  productVariant(id: $variantsId) {
    id
    price
    sku
    product {
      id
    }
  }
}
"""

Add these alongside your existing [events] API version configuration in shopify.app.toml. When a variant’s price changes, its delivery contains that variant and the Product ID your app needs to associate it with its parent. Configure the variant subscription once to handle price changes across all variants, including those beyond the first page.

Match each query to the variables its triggers provide. A product title change provides $productId, but not $variantsId, so it needs a separate subscription that queries the Product. Keep the fields and related data your handler needs to act on each change.

When reviewing queries over 100 points, look for opportunities to split them by the changes your app handles. Our guide to optimizing your subscriptions includes examples and checks to preserve the data coverage your app needs.

3 Likes