Wakati webhook haifiki kabisa

Fanya kazi kwa mpangilio - kumbukumbu ya utoaji, jina la tukio, firewall, saini. Kichupo cha Deliveries kinakuambia kama Didit iliituma, jambo linalogawanya tatizo mara moja.

Imeandikwa na Usaidizi wa Didit · Imesasishwa 19 Agosti 2026

#Hatua ya 1: Je, Didit ilijaribu kuituma?

Fungua lengo katika API & Webhooks na angalia kichupo cha Deliveries. Kila jaribio limeandikwa kando, pamoja na jibu lake.

1234

1. Last sent inakuambia kama Didit ilijaribu kabisa.
2. View stats inaonyesha majaribio na hitilafu za lengo hilo.
3. Utoaji wa jaribio hutenganisha endpoint yako na tukio lenyewe.
4. Lengo linaloendelea kushindwa linaweza kuzimwa wakati unalirekebisha.

Ukaguzi huo mmoja unagawanya tatizo mara mbili:

• Hakuna jaribio lililoandikwa → tukio halikuzalishwa kamwe kwa lengo hilo. Nenda hatua ya 2.
• Jaribio limeandikwa, limeshindwa → Didit iliituma na upande wako ulikataa au haukuipokea. Nenda hatua ya 3.
• Jaribio limeandikwa, 2xx → ilitolewa kwa mafanikio. Tatizo liko ndani ya kishughulikia chako, si kwenye utoaji.

#Hatua ya 2: hakuna jaribio lililoandikwa

Kwa mpangilio wa uwezekano:

1. Tukio halijasajiliwa. Hakuna wildcard - kila kundi la matukio lazima liorodheshwe wazi wazi. Na jina lisilokuwepo (session.status.updated, kyc.completed) hupokea kimya kabisa. Angalia dhidi ya orodha ya matukio.
2. Programu isiyo sahihi. Malengo yanahusiana na programu. Ikiwa vikao vyako vinaendeshwa chini ya programu tofauti na ile ya lengo, hakuna tukio litakalofika kwenye hilo kamwe. Hii ndiyo sababu ya kawaida zaidi wakati kila kitu kinaonekana kimewekwa sawa.
3. Hakuna kilichobadilika kweli. Webhooks huzindua wakati wa mabadiliko. Kikao ambacho hakijasogea, au uchunguzi wa AML unaorudia uchunguzi bila kupata chochote juu ya kiwango, huzalisha tukio sifuri kwa usahihi.
4. Hali unayosubiri bado haijatokea. Kikao kilicho In Progress hakijamalizika. Angalia wakati kikao hakimaliziki.

#Hatua ya 3: utoaji ulijaribiwa na ukashindwa

404 inamaanisha ombi lilifika kwenye kitu ambacho hakikuwa na njia yako. Angalia:

• Njia hasa, ikiwa ni pamoja na slash ya mwisho. Mfumo unaoelekeza upya /hook kwenda /hook/ unaweza kugeuza endpoint inayofanya kazi kuwa 404 au maudhui yaliyopotea.
• Kama URL ni ya umma. Seva ya ndani au ya staging isiyofikika kutoka mtandao inashindwa kwa njia hii.
• Kama proxy, load balancer, au kielekezi cha njia mbele ya programu yako kinapeleka njia hiyo mahali pengine.

5xx inamaanisha kishughulikia chako kilitupa hitilafu. Andika maudhui ghafi kabla ya kuyachambua ili uone kile kilichopokelewa kihalisia.

Timeout inamaanisha haukujibu haraka vya kutosha. Rudisha 2xx kwanza, chakata baadaye.

Hakuna kabisa / muunganisho umekataliwa inamaanisha ukingo wako uliuzuia. Didit hutuma kutoka IP tuli 18.203.201.92 ikiwa na user agent ya DiditWebhook/2.0. Ikiwa uko nyuma ya Cloudflare au WAF yenye msimamo wa kukataa kwa chaguo-msingi, ruhusu IP hiyo kwa hostname inayopokea.

#Hali ya kawaida: utoaji wa kiotomatiki unarudisha 404 lakini Resend inafanya kazi

Hii inatokea mara nyingi vya kutosha kustahili jina. Utoaji wa kiotomatiki unashindwa na 404, kisha kubofya Resend kwenye tukio lile lile hufanikiwa.

Mchanganyiko huo unamaanisha payload na endpoint yako zote ziko sawa - hivyo tofauti ni ya muda au njia, si ya maudhui. Angalia:

• Deploy au restart wakati wa utoaji wa awali. Resend inafanikiwa baadaye kwa sababu programu iko juu tena.
• Cold start iliyozidi muda wa timeout wa jukwaa lako - jambo la kawaida kwenye serverless yenye wito wa kwanza wa polepole.
• Uelekezaji wa njia uliobadilika kati ya majaribio mawili, au kanuni inayolingana na baadhi tu ya maombi.
• Kikomo cha kasi au ulinzi wa bots kwenye ukingo wako kilichoruhusu resend ya mkono kupita kwa sababu ilifika peke yake badala ya kundi la maombi.

Kichupo cha Deliveries kina majaribio yote mawili pamoja na muda wao - yalinganishe na kumbukumbu zako za deploy na hitilafu za dakika hiyo.

#Uthibitishaji wa saini unaposhindwa

Karibu kila mara ni mojawapo ya vitu vitatu:

1. Ulihesabu JSON iliyorudiwa kuandikwa (re-serialised). Fanya HMAC kwenye bytes ghafi za ombi hasa kama zilivyopokelewa. Kuchambua na kuandika upya kunabadilisha nafasi tupu na mpangilio wa funguo, na saini haitalingana. Mifumo mingi inahitaji usanidi wazi kupata maudhui ghafi.
2. Siri isiyo sahihi. Siri ya kusaini ni ya kila lengo, na si ufunguo wako wa API. Malengo mawili yana siri mbili tofauti.
3. Dhana isiyo sahihi ya usimbaji. Ikiwa huna uhakika kama siri inatumika kama string halisi au inafumbuliwa kwanza, usibashiri - fuata rejea ya uthibitishaji wa saini kwa usahihi, na andika maudhui ghafi wakati wa kurekebisha ili uweze kulinganisha.

#Marudio mawili si foleni

Kwenye 5xx, 404, timeout, au kushindwa kwa muunganisho, Didit hujaribu tena mara mbili - takriban dakika 1 kisha dakika 4 baadaye - kisha huachana na utoaji. Ikiwa endpoint yako ilikuwa chini kwa muda mrefu zaidi ya hapo, matukio hayo yamepotea milele.

Jenga njia ya upatanisho: wakati wa kuanza, fuatilia endpoint ya uamuzi kwa kikao chochote ambacho huna hali ya mwisho kwacho. Chukulia webhooks kama njia ya haraka na polling kama hifadhi ya nyuma.

#Kujaribu bila kuendesha uthibitishaji

Try Webhook kwenye ukurasa wa lengo hutuma tukio lililoundwa kikamilifu la aina yoyote uliyochagua - approved, declined, in review, KYB, entity, transaction. Kitumie kuthibitisha endpoint yako, ukaguzi wa saini, na kishughulikia kabla kikao halisi hakijategemea navyo.

Sandbox ni nusu nyingine ya hili: kikao cha sandbox hutoa webhooks halisi zenye "environment": "sandbox", hivyo unaweza kufanya mazoezi ya njia nzima mwanzo hadi mwisho bila malipo. Angalia kujaribu kwenye sandbox.