Webhook क्या है?
एक Webhook आपको सूचित करने की अनुमति देता है जब कुछ सिस्टम actions आपके द्वारा प्रदान किए गए URL पर एक कॉल के माध्यम से होते हैं। Webhooks को “URL Callbacks” या “HTTP push calls” के रूप में भी जाना जाता है। आपके URL को SSL का उपयोग करना चाहिए और HTTPS से शुरू होना चाहिए।Webhook Actions
webhooks के लिए उपलब्ध actions देखें।
Ayrshare Webhooks को समझना
Webhooks को विशिष्ट action द्वारा वर्गीकृत किया जाता है और Primary Profile या User Profile स्तर पर रजिस्टर किया जाता है। Primary या User Profiles के लिए कोई भी अपडेट पहले User Profile के लिए रजिस्टर किए गए Webhook पर भेजा जाता है। यदि User Profile के पास एक रजिस्टर किया गया Webhook नहीं है, तो अपडेट Primary Profile के रजिस्टर किए गए Webhook पर भेजा जाएगा। उदाहरण के लिए:- यदि एक User Profile के पास एक रजिस्टर किया गया Social Action Webhook है और TikTok को unlink करता है, तो User Profile के लिए रजिस्टर किया गया Social Action Webhook URL कॉल किया जाएगा। Primary Profile webhook कॉल नहीं किया जाएगा।
- यदि एक User Profile TikTok को unlink करता है और उसके पास एक रजिस्टर किया गया Social Action Webhook नहीं है, लेकिन Primary Profile के पास एक रजिस्टर किया गया Webhook है, तो Primary Profile के लिए रजिस्टर किया गया Social Action Webhook URL कॉल किया जाएगा।
एक Webhook रजिस्टर करें
POST/hook/webhook endpoint को एक endpoint URL और action प्रकार प्रदान करके एक Webhook रजिस्टर करें। जब action होता है तो प्रदान किए गए URL पर एक HTTP POST message भेजा जाएगा।
उदाहरण के लिए, scheduled पोस्ट की स्थिति की सूचना पाने के लिए एक URL रजिस्टर करें।
Webhook endpoint URL को redirects का उपयोग नहीं करना चाहिए और यह अंतिम गंतव्य URL होना चाहिए।
यदि आप केवल Primary Profile webhook रजिस्टर करते हैं, तो User Profiles स्वचालित रूप से Primary Profile webhook को inherit करेंगे।
प्रत्येक User Profile के लिए एक अद्वितीय webhook के लिए, आपको प्रत्येक User Profile के लिए एक webhook रजिस्टर करना होगा।
आपके Webhook को
HTTP POST प्राप्त करने के बाद, आपके सर्वर को कॉल को सफल के रूप में चिह्नित करने के लिए
200 की HTTP स्थिति के साथ प्रतिक्रिया देनी चाहिए। यदि आपका सर्वर 15 सेकंड के भीतर प्रतिक्रिया नहीं देता है,
तो प्रयास को विफल के रूप में रिकॉर्ड किया जाता है और पुनःप्रयास किया जाता है। जैसे ही आप request प्राप्त करें प्रतिक्रिया दें
और अपनी processing asynchronously करें — timeout एक अस्वीकृति नहीं है, इसलिए यदि आपका handler काम पूरा कर लेता है
लेकिन देर से उत्तर देता है, तो पुनःप्रयास आपको इसे दो बार process करने के लिए मजबूर करेगा।Webhook Retries
कोई failed delivery retry होगी या नहीं, यह इस पर निर्भर करता है कि वह कैसे fail हुई। हर retry में वहीhookId रहता है। Payload हर attempt पर फिर से बनता है, इसलिए timeStamp — और उस पर signature — भिन्न हो सकते हैं।
Retry होती हैं — transient failures. 429, 408 या 425 response, कोई भी 5xx, timeout, या टूटा हुआ connection लगभग एक घंटे में अधिकतम 9 delivery attempts होते हैं — पहला send और 8 retries। इसके बाद भी fail होता रहे, तो delivery एक घटते schedule पर फिर से कोशिश की जाती है — लगभग 5 मिनट, 30 मिनट, 2 घंटे और 12 घंटे बाद। इसलिए कोई delivery original event के लगभग 16 घंटे बाद तक भी पहुँच सकती है।
Retry नहीं होती — rejections. कोई भी अन्य 4xx response, जैसे 400, 401, 403, 404 या 410, पहले ही attempt पर final मानी जाती है। ये बताती हैं कि request स्वयं reject हुई थी, और उसे दोहराने से परिणाम नहीं बदलेगा।
Delivery Semantics और Idempotency
Ayrshare webhooks को कम से कम एक बार डिलीवर करता है। कभी-कभार duplicates सामान्य संचालन हैं, कोई दोष नहीं — प्रत्येक consumer को स्थायी संपत्ति के रूप में idempotency की आवश्यकता होती है। Duplicates दो अलग-अलग रूपों में आते हैं, और प्रत्येक को एक अलग key की आवश्यकता होती है:hookId एक event की एक delivery को पहचानता है। यह उस delivery के हर retry पर समान होता है, इसलिए इस पर claim करना retries को safe बनाता है — लेकिन उसी अंतर्निहित event की एक नई notification एक नए hookId के साथ आती है, इसलिए अकेले hookId उस मामले को नहीं पहचानेगा।
अनुशंसित receiver pattern:
- पहले प्रतिक्रिया दें। तुरंत
2xxलौटाएं, फिर asynchronously process करें। एक timeout एक अस्वीकृति नहीं है — यदि आप काम पूरा कर लेते हैं लेकिन देर से उत्तर देते हैं, तो event फिर से भेजा जाता है। - जैसे ही request आती है
hookIdको atomically claim करें — एक unique constraint, एकINSERT ... ON CONFLICT DO NOTHING, या एकSET NX— not एक read-then-write check। दो attempts एक साथ पहुँच सकते हैं, और एक check-then-act guard दोनों को अंदर आने देता है। - अपनी एक key भी claim करें, जो payload से बनी हो, ताकि एक नए
hookIdके साथ आने वाली दूसरी notification भी पहचानी जा सके।messagesपर,idकोsubActionके साथ मिलाना अच्छा काम करता है। - फिर काम करें, दोनों claims को retry window और बाद में किसी re-notification को cover करने के लिए पर्याप्त समय तक hold करके रखें। चूँकि कोई retry लगभग 16 घंटे बाद तक आ सकती है, अपने claims को कम से कम 24 घंटे तक hold करें। इससे पहले expire होने वाला claim देर से आई retry को नहीं पहचानेगा, और आप वही event दो बार process कर देंगे।
Payload का
id हर event type के लिए अकेले unique नहीं है — वही message id edits और reactions के दौरान दोहराई जाती है, और messageRead payloads में कोई id नहीं होता — इसलिए इसे अकेले उपयोग करने के बजाय subAction के साथ मिलाएं।Delivery Metadata Headers
प्रत्येक delivery दो headers ले जाती है जो उस विशिष्ट transmission की पहचान करते हैं, ताकि आप एक original को एक retry से अलग बता सकें:X-Ayrshare-Delivery-Attempt पहले send पर 0 होता है और प्रत्येक retry पर एक से बढ़ता है, इसलिए 0 से ऊपर का कोई भी मान इसका अर्थ है कि हम इस delivery को कम से कम एक बार पहले ही भेज चुके हैं। इसे मानों के एक निश्चित समूह के बजाय एक असीमित counter के रूप में मानें — retries की संख्या एक operational विवरण है जो बदल सकता है। X-Ayrshare-Delivery-Id प्रत्येक attempt के लिए unique है — support को यह उद्धृत करें और यह सटीक delivery record की पहचान करता है।
ये transmission की पहचान करते हैं; hookId event की पहचान करता है। hookId पर deduplicate करें, delivery id पर नहीं — delivery id प्रत्येक attempt पर design के अनुसार अलग होती है, इसलिए कुछ भी कभी भी duplicate के रूप में पहचाना नहीं जाएगा।
Webhook Security
आप HMAC authentication को एक HTTP request के रूप में सेट करके अतिरिक्त सुरक्षा जोड़ना चुन सकते हैं। यह अक्सर replay attacks को रोकने के लिए किया जाता है। Ayrshare message की body को hash करने के लिए HMAC-SHA256 का उपयोग करता है और इसे तथा UNIX timestamp को POST के header में शामिल करता है।X-Authorization-Content-SHA256 की तुलना POST body के HMAC-SHA256 के साथ करके पोस्ट को validate कर सकते हैं। Signing secret profile-wide है — प्रति User Profile एक secret, जो उस profile के सभी webhook actions में उपयोग किया जाता है, इसलिए एक action के लिए इसे सेट करने से उस profile के सभी actions के लिए यह बदल जाता है। Multi-profile accounts प्रति profile एक अलग secret प्रबंधित करते हैं (Profile-Key header के साथ किसी profile को target करें)।