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.

4 min readSume
All posts

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.

Dedupe keys by hop, from the Shopify changelog and Sume docs, read 2026-10-01.
HopKeySource
Shopify event to your receiverOne you derive; the two headers are goneShopify changelog
Your receiver to Sume submitIdempotency-Key on the requestGeneration admission
Sume job webhook to your receiverjob_idWebhooks

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

All Integrations posts

Written by Sume