Skydd mot dubbla leveranser

Kopiera sidan

Ange rubriken som innehåller avsändarens unika händelse-ID. Upprepade leveranser inom 24 timmar accepteras, men skickas inte vidare till Shopify Flow.

De flesta system gör ett nytt försök med en webhook om de inte får ett snabbt svar. Om det första försöket faktiskt nådde fram körs ditt Shopify Flow-arbetsflöde två gånger för en och samma händelse - ett andra e-postmeddelande, en dubbel tagg, en upprepad orderkommentar.

Skyddet mot dubbla leveranser förhindrar detta. Det är avstängt som standard för alla webhooks.

Så här fungerar det

Om ditt sändningssystem innehåller ett unikt ID per händelse ska du ange namnet på den rubrik som innehåller detta under Avancerade inställningar -> Detektering av dubbla leveranser.

	Beteende
Första förfrågan med ett visst id	Vid normal hantering utlöser det Shopify Flow
Upprepa inom 24 timmar	`200 OK` med `duplicate: true` - skickas inte till Shopify Flow
Ett annat ID	Behandlas på vanligt sätt
Begäran utan den rubriken	Behandlas på vanligt sätt
Fältet har lämnats tomt	Varje begäran har behandlats - ingenting förändras

Vanliga rubriknamn: Event-Id, Idempotency-Key, X-Request-Id. Vid matchning beaktas inte storlekar på bokstäver.

bash

# Same Event-Id twice - the second is accepted but not re-sent to Flow
curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -H "Event-Id: evt_12345" \
  -d '{"orderId":"1001"}'

Varför returnerar upprepningen fortfarande 200?

Ett svar som inte är av typen 2xx är just det som gör det svårare för avsändaren att göra ett nytt försök. Ett svar med koden 200 visar att händelsen har hanterats korrekt, så att avsändaren avbryter försöket - medan duplicate: true i svarstexten gör att du kan skilja mellan de två utfallen om du loggar svaren.

Var dubbletter dyker upp

En undertryckt dubblett:

skapar ingen post i anropshistoriken, så det räknas inte in i ditt abonnemang
visas i Live Request Inspector medan du redigerar webhooken, markerad som en borttagen dubblett

Den kombinationen är avsiktlig: din historik och din kvot förblir oförändrade, men ett samtal ser aldrig ut som om det tyst försvunnit.

Att välja rätt rubrik

ID:t måste vara oförändrat under hela omförsöket och unikt för varje händelse - det är hela mekanismen.

Bra: ett händelse-ID eller en idempotensnyckel som genereras en gång av avsändaren när händelsen inträffar.

Felaktiga och avvisade vid lagring: proxy-styrda rubriker såsom X-Forwarded-For, CF-* eller X-Signature. Deras värde ändras per begäran eller per hop, vilket innebär att de aldrig skulle stämma överens vid en upprepning - vilket leder till att felet hanteras tyst istället för att signaleras tydligt.

Om lagringsplatsen för deduplicering tillfälligt är otillgänglig

Leveransen behandlas istället för att avbrytas. Att ett arbetsflöde körs två gånger är ett betydligt mindre problem än att en händelse går förlorad, så funktionen är utformad så att den väljer den säkraste lösningen.