An order fires several webhook topics, not one
A fulfillment integration, ERP, or marketing automation reacts to more than one event over a Shopify order's lifetime: orders/create when the order is placed, orders/paid when payment is confirmed, and orders/fulfilled when it ships. Testing just the creation event leaves much of that logic uncovered.
Modeling with Response Sequences
// Mock Rule: POST / → Response Sequences, mode: last
[
{ "status": 200, "body": "{\"id\":990001,\"financial_status\":\"pending\",\"fulfillment_status\":null,\"total_price\":\"149.90\"}" },
{ "status": 200, "body": "{\"id\":990001,\"financial_status\":\"paid\",\"fulfillment_status\":null,\"total_price\":\"149.90\"}" },
{ "status": 200, "body": "{\"id\":990001,\"financial_status\":\"paid\",\"fulfillment_status\":\"fulfilled\",\"total_price\":\"149.90\"}" }
]What about the X-Shopify-Hmac-Sha256 header?
Same honest limitation as the Stripe and GitHub articles: httpdrop's template engine doesn't generate HMAC — the
X-Shopify-Hmac-Sha256 header won't come out cryptographically valid from the mock. Test signature verification separately (Shopify lets you redeliver real webhooks from the store admin's Notifications section, or use the Shopify CLI in app development mode). What httpdrop tests well is the logic that reacts to each financial_status/fulfillment_status change in the payload.Next step: combine with mocks in a CI/CD pipeline to run these scenarios automatically on every build.