Webhook-signatur och replayfönster: idempotens så att 02:00 förblir tråkigt

En osignerad callback är inte en händelse. Det är oautentiserad HTTP som råkar likna er payload. Team som «accepterar först, verifierar sen» betalar klockan 02:00: en omspelad DLR, en dubblerad STOP eller en andra plånboksdebit som finance inte kan rulla tillbaka. Prepaid gör felet penga-synligt. Tråkiga vanor: signatur på varje begäran, begränsat replayfönster, idempotensnycklar som finance läser bredvid ledger-raden.

IOSOR förväntar sig granskningsbara B2B-integrationer: signerade webhooks, roterbara hemligheter, client-safe fel som inte spiller främmande varumärken. Nära USD 1,000+ månadsanvändning blir korrelations-ID och replaybevis kommersiellt granskningsmaterial.

Osignerade callbacks är inte händelser

Verifiera signaturen innan ni parsar affärsfält. Avvisa saknade, utgångna eller felställda signaturer med ett client-safe fel — bearbeta inte «ändå för piloten». En staging-konsument som hoppar över verifiering tränar produktion att hoppa över. Meddelandekatalog live betyder inte att er webhook-URL är en offentlig tipp.

Replayfönster och varför 02:00 händer

Leverans minst-en-gång retried vid timeout, 5xx och tvetydig nätförlust. En sen retry klockan 02:00 är normalt. Fönstret begränsar hur länge en signerad payload förblir acceptabel: för brett och en angripare spelar om en gammal STOP; för smalt och en legitim retry ser ut som förfalskning. Logga fönsteravvisningar skilt från signaturfel.

Idempotens som finance kan läsa

Samma händelse-ID måste ge samma sluttillstånd. Extrahera plattformens händelse-/meddelande-ID — hitta inte på en nyckel av tidsstämpel plus kropp. Returnera framgång på ett känt ID utan att debitera igen. Utgående sändningar behöver samma disciplin — idempotens, omsändning och pengar. Finance ska förklara varje prepaid-rad mot en statushändelse.

Signaturrotation utan dubbelaccept-kaos

Rotera hemligheter utan ett fönster där gamla och nya signaturer accepteras för alltid. Planera överlapp, klipp sen. Klistra aldrig en produktionshemlighet i ett ärende. Separera sandbox- och produktionskonsumenter. Dead-letter med replayverktyg så ops kan köra om en misslyckad konsument utan att uppfinna en andra debit. Bär korrelations-ID från sändning till ledger-rad så 02:00 är ett runbook, inte arkeologi.

Röda flaggor

• Handler accepterar osignerade kroppar «tills vidare»
• Inget replayfönster, eller ett mätt i veckor
• Statusöverskrivning utan tidsstämpeljämförelse
• CRM/e-post-biverkningar före ACK
• Produktionshemlighet i chatten
• Dubblerade händelse-ID förra månaden utan tillsyn
• Kundfel som spiller råa upstream-koder

Börja med IOSOR

Öppna din IOSOR-konsol och kontrollera dina aktiva webhook-inställningar för inkommande leveranskvitton och händelseåterkopplingar. Sätt ett kort signaturfönster på fem minuter för att förhindra omsändningar och bind din hanterare strikt till plattformens händelse-ID. Testa din slutpunkt mot simulerade dubbletter i testmiljön för att säkerställa att dubbla anrop svarar med 200 OK utan att aktivera redundant affärslogik.

• API-pilotvecka: Nycklar och webhooks i livetrafik
• Spårning av korrelations-ID:n från API-anrop till DLR-webhooks

IOSOR sammanfattning

Overifierade webhook-hanterare och saknade tidsfönster förvandlar vanliga nätverksförsök till säkerhetsrisker och oönskade tillståndsändringar. Genom att begränsa signaturens giltighet via tidsstämplar och kräva fullständig idempotens förblir automatiska leveransförsök mitt i natten helt förutsägbara.