इनबाउंड SMS वेबहुक: रीट्राई, इवेंट ऑर्डर, और प्राप्ति पर इडेम्पोटेंसी

हर इनबाउंड मैसेज हैंडलर अंततः एक ही तीन आश्चर्यों का सामना करता है: वही webhook दो बार फायर होता है, एक "delivered" इवेंट उस "failed" इवेंट के बाद आता है जिसे उसे बदलना था, और एक ग्राहक का STOP रिप्लाई दो बार प्रोसेस होता है क्योंकि दो सर्वरों ने एक ही रीट्राई उठाया। इनमें से कोई भी आपको webhook भेजने वाले platform की bug नहीं है — यह किसी भी "कम से कम एक बार" delivery सिस्टम का सामान्य व्यवहार है, और आपके receive endpoint को पहले दिन से ही इस वास्तविकता के लिए बनाया जाना चाहिए।.

IOSOR इनबाउंड SMS, STOP/HELP कीवर्ड, और delivery events को white-label prepaid webhooks के रूप में डिलीवर करता है — नीचे दिया गया retry और ordering व्यवहार वह है जो किसी भी गंभीर B2B integration को मान लेना चाहिए, चाहे इसके पीछे कोई भी platform हो।.

Webhooks आखिर retry क्यों करते हैं

एक webhook platforms यह निश्चित रूप से नहीं जान सकता कि आपके endpoint ने एक delivery को प्रोसेस किया या नहीं। आपका सर्वर एक database commit के बाद 200 वापस कर सकता है जो बाद में rollback हो जाता है; आपका handler सफल होने के बावजूद एक load balancer वापसी के रास्ते में response खो सकता है; एक deploy एक request के बीच में आपकी process को restart कर सकता है।.

तीन failure modes जिनके लिए आपको design करना होगा

Idempotency: वह एक property जो तीनों को ठीक करती है

एक idempotent receive endpoint चाहे एक ही event कितनी भी बार delivered हो, वही अंतिम state produce करता है। यह mechanism सरल और अच्छी तरह समझा गया है: हर incoming event एक unique event ID रखता है; process करने से पहले, आप जाँचते हैं कि क्या आपने पहले ही उस ID को record किया है; अगर हाँ, तो आप बिना reprocess किए तुरंत success return करते हैं। 1. Payload से platforms का event/message ID निकालें — कभी भी timestamp + body से अपना खुद का ID न बनाएं, क्योंकि retries timestamps को milliseconds से shift कर सकते हैं। 2.

Event ordering: "last write wins" खतरनाक क्यों है

खतरे के संकेत

• Webhook payload में कोई unique event ID नहीं, या आपका integration मौजूद वाले को ignore करता है
• Status updates plain overwrite के साथ apply होते हैं बिना timestamp comparison के
• STOP handling वही dedupe logic के पीछे नहीं है जो regular incoming messages के लिए है
• Webhook handler acknowledge करने से पहले synchronous downstream calls (email, CRM, agent routing) करता है
• कोई logs नहीं दिखाते कि पिछले महीने कितने duplicate event IDs आए — मतलब कोई नहीं देख रहा

IOSOR के साथ शुरू करें

पिछले सप्ताह के आवक webhook लॉग निकालें और एक से अधिक बार आए इवेंट ID गिनें। एक दोहरा और एक क्रम-बाहर जोड़ा चलाएँ (failed, फिर delivered)। रिसीवर एक प्रभाव रखे: एक इनबॉक्स पंक्ति, एक STOP लेख, एक वॉलेट छू। STOP उल्टाने वाला last-write-wins असफलता है। यह प्राप्ति पर आइडेम्पोटेंसी और पुनःप्रयास क्रम है, हस्ताक्षर जाँच नहीं, कतार से पहले गेटवे ताला नहीं।

संबंधित लेख: इनबाउंड ऑटो-रिप्लाई लूप · कैरियर लेटेंसी स्पाइक्स के खिलाफ इनबाउंड वेबहुक प्रोसेसिंग को बफर करें · पहली कटौती से पहले प्रीपेड राशि आरक्षित करना.

IOSOR सार

आवक webhook फिर कोशिश करते हैं। प्राप्ति पर आइडेम्पोटेंसी ही सुरक्षित उत्तर है; क्रम वादा नहीं।

करें: इवेंट कुंजी दें और जुड़वाँ अनदेखा करें। न करें: STOP पर last-write-wins या एक इवेंट दो डेबिट नहीं।