Um pedido dispara vários tópicos de webhook, não um só
Uma integração de fulfillment, ERP ou automação de marketing reage a mais de um evento ao longo da vida de um pedido no Shopify: orders/create quando o pedido é feito, orders/paid quando o pagamento é confirmado, e orders/fulfilled quando o envio sai. Testar só o evento de criação deixa boa parte dessa lógica sem cobertura.
Modelando com 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\"}" }
]Cada chamada sucessiva ao endpoint devolve o próximo estado do pedido — sua automação recebe exatamente a sequência create → paid → fulfilled que aconteceria numa loja real, sem precisar criar e processar um pedido de teste na Shopify toda vez.
E o header X-Shopify-Hmac-Sha256?
Mesma limitação honesta dos artigos de Stripe e GitHub: o motor de templates do httpdrop não gera HMAC — o header
X-Shopify-Hmac-Sha256 não sai criptograficamente válido do mock. Teste a verificação de assinatura separadamente (o Shopify permite reenviar deliveries reais pela seção de Notifications do admin da loja, ou usar o Shopify CLI em modo de desenvolvimento de app). O que o httpdrop testa bem é a lógica que reage a cada mudança de financial_status/fulfillment_status do payload.Próximo passo: combine com mocks em pipeline de CI/CD pra rodar esses cenários automaticamente a cada build.