Shopify events: event-id header gone, dedupe on Sume job_id
Shopify events no longer send shopify-event-id. On the Sume side, dedupe job webhooks on job_id and send an Idempotency-Key on every paid submit that may retry.
Shopify's events deliveries no longer include the shopify-event-id or shopify-resource-id headers, so you cannot use them as your dedupe key. On the Sume side nothing changes: dedupe job webhooks on job_id, and send an Idempotency-Key on every paid submit that may be retried.
The Shopify change is from its 2026-09-16 changelog, read 2026-10-01. Sume behavior is from Webhooks and Generation admission.
What exactly did Shopify remove?
The changelog says events deliveries no longer include shopify-event-id or shopify-resource-id. It tells you to update your Shopify API packages and, if your own code reads these headers or requires them for validation, to remove that dependency. It also says classic webhook subscriptions are unaffected.
The practical result for a store automation: the first hop (Shopify to your receiver) needs a dedupe key that you derive yourself. What that key should be is your design choice; this post does not claim what Shopify's payload contains beyond the changelog text.
Where does idempotency live on the Sume side?
Two places, one per direction. Outbound, a paid submit that may be retried carries an Idempotency-Key, and a retry reuses the same key for the same operation and payload. Inbound, Sume job webhooks are delivered at least until a 2xx arrives, so the docs say to use job_id as the idempotency key on your side.
| Hop | Key | Source |
|---|---|---|
| Shopify event to your receiver | One you derive; the two headers are gone | Shopify changelog |
| Your receiver to Sume submit | Idempotency-Key on the request | Generation admission |
| Sume job webhook to your receiver | job_id | Webhooks |
How many times can a Sume webhook arrive?
Network errors and non-2xx responses are retried up to 10 attempts in total, so a slow or failing receiver will see the same job_id again. Sume sends terminal job events only, so for a given job you expect one terminal event, possibly delivered more than once. Store the event durably, then return a 2xx.
What should I change in my handler?
Remove any check that requires the removed Shopify headers, derive your own key for the Shopify hop, put an Idempotency-Key on the Sume submit so a retry cannot create a second paid job, and keep a unique constraint on job_id for the webhook. For the product-video flow itself, see Shopify product video automation with a webhook.
Sources
Related posts
More in Integrations
- Shopify product.variants.* trigger: one Sume image per variant
A product.variants.* Shopify events trigger can fire many times at once. Fan each event out to one Sume image job, and queue bursts on your side.
- Shopify's Meta AI channel: product image variants from Sume
Shopify now lists Meta as an AI channel and shares products through Shopify Catalog. Here is what Sume can make for those listings: image variants and a video.
- Slack incoming webhook 1/sec: when 100 Sume jobs finish together
Slack incoming webhooks allow about 1 message per second. When 100 Sume jobs finish at once, store each webhook, then post to Slack from a paced queue.
- Snapchat Ads MCP and hosted Sume tools in one agent
Snap's Ads MCP server answers campaign questions and is read-only at launch. Add Sume's hosted MCP in the same agent to turn the findings into creative.
Written by Sume