IOSOR Kunskap
Inkommande SMS-webhooks: återförsök, händelseordning, och idempotens vid mottagning
En byggguide för B2B-team som hanterar inkommande SMS: varför återförsök sker, varför händelseordningen inte är garanterad, och hur ni gör er mottagningsendpoint idempotent istället för att duplicera konversationer och STOP-hantering.
Varje hanterare för inkommande meddelanden stöter förr eller senare på samma tre överraskningar: samma webhook utlöses två gånger, en "delivered"-händelse anländer efter den "failed" den skulle ersätta, och en kunds STOP-svar bearbetas två gånger eftersom två servrar tog emot samma återförsök. Inget av detta är en bugg i plattformen som skickar er webhooken — det är det normala beteendet hos alla "minst en gång"-leveranssystem, och er mottagningsendpoint måste byggas för denna verklighet från dag ett.
IOSOR levererar inkommande SMS, STOP/HELP-nyckelord, och leveranshändelser som förbetalda white-label-webhooks — återförsöks- och ordningsbeteendet nedan är vad varje seriös B2B-integration bör anta oavsett vilken plattform som ligger bakom.
Varför webhooks alls försöker igen
En webhook-leverantör kan inte veta med säkerhet att er endpoint bearbetade en leverans. Er server kan returnera en 200 efter att ha commitat till en databas som sedan rullas tillbaka; en lastbalanserare kan tappa svaret på vägen tillbaka trots att er hanterare lyckades; en distribution kan starta om er process mitt i en förfrågan.
De tre felägen ni måste designa för
| Felläge | Vad som händer | Vad som går sönder om ni ignorerar det |
|---|---|---|
| Duplicerad leverans | Samma händelse-ID anländer 2+ gånger | Dubbelräknade svar, duplicerad STOP-hantering, duplicerade konversationstrådar |
| Händelser i fel ordning | En senare tidsstämplad händelse anländer före en tidigare | En "delivered"-status skrivs över tillbaka till "sent" |
| Partiellt/tvetydigt fel | Er |
Idempotens: den enda egenskapen som löser alla tre
En idempotent mottagningsendpoint producerar samma slutstatus oavsett hur många gånger samma händelse levereras. Mekanismen är enkel och väl förstådd: varje inkommande händelse bär ett unikt händelse-ID; innan bearbetning kontrollerar ni om ni redan registrerat det ID:t; om så är fallet returnerar ni framgång omedelbart utan att bearbeta igen. 1.
Händelseordning: varför "senaste skrivningen vinner" är farligt
Webhook-händelser för samma meddelande är inte garanterade att anlända i den ordning de inträffade. Ett återförsök av en tidigare "queued"-händelse kan anlända efter en senare "delivered"-händelse på grund av nätverksjitter, köbildning på leverantörssidan, eller er egen worker-pool som bearbetar förfrågningar i fel ordning.
STOP, HELP, och andra inkommande nyckelord behöver samma disciplin
Efterlevnadskritiska inkommande nyckelord förtjänar den strängaste idempotensen av alla. En duplicerad STOP bör aldrig logga en avanmälningshändelse två gånger eller skicka två bekräftelsesvar. En duplicerad HELP bör aldrig utlösa två separata supportinfomeddelanden till samma nummer inom samma minut.
Kom igång med IOSOR
Relaterat: inbound autosvarsslingor · Buffra inkommande webhook-bearbetning mot operatörens latensspikar · reservation av förbetalt saldo före första debiteringen.
IOSOR sammanfattning
Inbound-webhooks retrier. Idempotens vid mottag är det enda säkra svaret; ordning är inget löfte.
Gör: nyckla eventet och ignorera tvillingen. Gör inte: last-write-wins på STOP eller debitera samma event två gånger.
Var den här guiden till hjälp?
Relaterade guider
- Konfigurera automatiska SMS-utlösare vid missade inkommande röstsamtal
Lär dig att konfigurera automatiska SMS-utlösare för missade inkommande röstsamtal och upptagettoner i IOSORs white-label-CPaaS-konsol.
- Buffra inkommande webhook-bearbetning mot operatörens latensspikar
Lär dig hur du konfigurerar IOSOR inkommande buffringsregler för att skydda dina webhooks mot operatörsförseningar, samtidighetstoppar och upstream timeout-fel.
- Synkronisering av inkommande opt-out-nyckelord över multitenant-konton
Bemästra multitenant opt-out-synkronisering i IOSOR. Lär dig hur inkommande stopp-nyckelord hanterar globala spärrar samtidigt som underkonton isoleras.