IOSOR Znanje

Potpis webhooka i prozor ponavljanja: idempotencija da 02:00 ostane dosadno

Provjerite potpise, ograničite prozor ponavljanja i učinite ulazne webhooke idempotentnima — nikad ne primajte nepotpisane callbackove, nikad ne debitirajte prepaid dvaput na retry.

Nepotpisani callback nije događaj. To je neautenticirani HTTP koji slučajno izgleda kao vaš payload. Timovi koji «prvo prihvate, kasnije provjere» plaćaju u 02:00: ponovljeni DLR, duplicirani STOP ili drugi debit novčanika koji finance ne može vratiti. Prepaid čini grešku vidljivom u novcu. Dosadne navike: potpis na svakom zahtjevu, ograničeni prozor ponavljanja, ključevi idempotencije koje finance čita uz redak ledgera.

IOSOR očekuje revidibilne B2B integracije: potpisani webhookovi, rotabilne tajne, client-safe greške bez tuđih marki. Blizu USD 1,000+ mjesečne upotrebe ID-ovi korelacije i dokaz ponavljanja postaju materijal komercijalnog pregleda. Parirajte s webhookovi i ključevi pri pokretanju i webhookovi koji prežive pokretanje.

Nepotpisani callbackovi nisu događaji

Provjerite potpis prije nego parsirate poslovna polja. Odbijte nedostajuće, istekle ili krive potpise client-safe greškom — ne obrađujte «ipak za pilota». Staging potrošač koji preskače provjeru trenira proizvodnju da preskače. Katalog live poruka ne znači da je URL webhooka javno odlagalište. Ako ne dokažete tko je potpisao tijelo, nemate događaj; imate krivotvoreni zahtjev.

Prozori ponavljanja i zašto se događa 02:00

Isporuka barem-jednom retried na timeout, 5xx i dvosmisleni gubitak mreže. Kasni retry u 02:00 je normalan. Prozor ograničava koliko dugo potpisani payload ostaje prihvatljiv: preširok i napadač ponavlja stari STOP; pretijesan i legitimni retry izgleda kao krivotvorina. Bilježite odbijanja prozora odvojeno od grešaka potpisa. Pogledajte ponavljanja dolaznog webhooka. Odgovorite brzo, persistirajte prvo, obradite async — handler koji radi CRM prije ACK proizvodi duplikate.

Idempotencija koju finance može čitati

Isti ID događaja mora dati isto krajnje stanje. Izvucite ID događaja/poruke platforme — ne izmišljajte ključ iz vremenskog pečata plus tijela. Vratite uspjeh na poznatom ID-u bez ponovnog debita. Odlasne pošiljke trebaju istu disciplinu — idempotentnost, ponavljanja i novac. Finance mora objasniti svaki prepaid redak naspram statusnog događaja. Ako timeout izazove oluju retryja klijenta, ledger pokazuje štetu prvi. Katalog in setup nije izgovor da preskočite idempotenciju «do Live».

Rotacija potpisa bez kaosa dvostrukog prihvaćanja

Rotirajte tajne bez prozora u kojem se stari i novi potpisi prihvaćaju zauvijek. Planirajte preklapanje, zatim režite. Nikad ne lijepite proizvodnu tajnu u tiket. Odvojite sandbox i proizvodne potrošače. Dead-letter s alatima ponavljanja da ops može ponovno voziti neuspjelog potrošača bez izmišljanja drugog debita. Nosite ID-ove korelacije od slanja do retka ledgera da 02:00 bude runbook, ne arheologija.

Crvene zastave

  • Handler prima nepotpisana tijela «zasad»
  • Nema prozora ponavljanja, ili jedan mjeren u tjednima
  • Prepis statusa bez usporedbe pečata
  • Nuspojave CRM/e-pošte prije ACK
  • Proizvodna tajna u chatu
  • Duplicirani ID-ovi događaja prošli mjesec bez nadzora
  • Greške klijentu koje sipaju sirove upstream kodove

Započnite s IOSOR-om

Otvorite svoju IOSOR konzolu i provjerite postavke aktivne web-kuke za dolazne potvrde isporuke i povratne pozive događaja. Postavite uski prozor ponavljanja provjere potpisa na pet minuta i strogo vežite svoj rukovatelj za ID događaja platforme. Testirajte krajnju točku na ponovljene terete u testnom okruženju kako biste osigurali da duplikati vraćaju status 200 OK bez pokretanja suvišne poslovne logike.

Sažetak IOSOR

Provjera potpisa i prozor ponavljanja sprječavaju ranjivosti pri mrežnim pokušajima. Postavite strogu idempotenciju u konzoli i provjerite UTC dnevnik kako bi isporuka u 02:00 ostala predvidljiva uz /learn/ link za rad.

Je li vam ovaj vodič pomogao?

Povezani vodiči