Shopify Events query_filter: ACTIVE products only for Sume runs

Shopify's Events subscription has a query_filter that decides which query results are delivered to your app, and its own example limits deliveries to products with an ACTIVE status. Use it so draft products are dropped at Shopify, before your handler can start a paid Sume job for them.

The filter description is from Shopify's Next Gen Events announcement, read 2026-10-01; Sume limits are from Bulk runs and Jobs and results.

What are the three parts of an event?

Shopify says an Events subscription, set in shopify.app.toml, has three components, and that the trigger and the query are independent.

Why filter before Sume rather than in my code?

A delivery you never receive cannot start a job. Shopify's advice is to shape the subscription around what the app needs to do when something changes, and to measure deliveries and follow-up calls. Filtering in your handler also works, but the filter at Shopify removes the draft deliveries and the work of discarding them. The query must return the status for the filter to check it, so include it in the query.

How do I queue many active products at once?

After a catalog import many products can arrive together. Sume's Format bulk runs queue up to 100 Format runs with a concurrency window: POST /v1/formats/{handle}/{slug}/bulk-runs, then poll GET /v1/format-run-queues/{id}. Collect the ACTIVE deliveries, split them into groups of up to 100, and send each group as one queue with its own Idempotency-Key.

curl -X POST "https://api.sume.com/v1/formats/sume/sume-product-commercial/bulk-runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: active-batch-2026-10-01-a" \
  -d '{
    "concurrency": 3,
    "items": [
      { "instruction": "product 1", "input": { "url": "https://example.com/p1.jpg" } },
      { "instruction": "product 2", "input": { "url": "https://example.com/p2.jpg" } }
    ]
  }'

What if a retry hits a draft that went active?

Reuse the same key for the same intent, as the jobs docs say: the retry returns the original job rather than a second charge. A product that turns ACTIVE later is a new delivery with its own key. For the trigger side, see the product video webhook guide and fields_changed.