सीधा जवाब: WhatsApp Business API, Meta का प्रोग्रामेटिक बिज़नेस-मैसेजिंग इंटरफ़ेस है। आपका एप्लिकेशन Graph API को आउटबाउंड रिक्वेस्ट भेजता है। Meta एक मैसेज आइडेंटिफ़ायर लौटाता है, और बाद में इनबाउंड मैसेज और डिलीवरी की स्थिति में बदलाव आपके webhook पर भेजता है। इसके आसपास की हर चीज़, यानी एजेंट को असाइन करना, रीट्राई, CRM अपडेट, सहमति का सबूत और रिपोर्टिंग, आपके एप्लिकेशन या सॉफ़्टवेयर प्रोवाइडर की ज़िम्मेदारी है।
यह गाइड असली सिस्टम का नक्शा बनाती है, ताकि बिज़नेस मालिक, मार्केटर और डेवलपर लॉन्च से पहले एक ही डिज़ाइन की समीक्षा कर सकें।
नाम: Business Platform, Cloud API और "Business API"#
WhatsApp Business Platform प्रोग्रामेटिक बिज़नेस मैसेजिंग के प्रोडक्ट परिवार का नाम है। Cloud API Meta की होस्ट की हुई API का क्रियान्वयन है। "WhatsApp Business API" वह शब्द है जिसे ज़्यादातर खरीदार और टीमें पूरी क्षमता के लिए इस्तेमाल करती हैं।
यह WhatsApp Business ऐप से अलग है। ऐप एक एंड-यूज़र प्रोडक्ट है जिसमें इनबिल्ट इनबॉक्स है। API एक इंटरफ़ेस है जिसे कोई दूसरा एप्लिकेशन कॉल करता है। सिर्फ़ API अपने-आप किसी सेल्स टीम को काम करने लायक कतार नहीं देती।
Meta का आधिकारिक WhatsApp Business Platform कलेक्शन एक काम का, ताज़ा संदर्भ है, क्योंकि उसमें फ़ोन नंबर, मैसेज, टेम्पलेट, webhook और बिज़नेस एसेट की असली रिक्वेस्ट के समूह मिलते हैं।
रिक्वेस्ट से webhook तक का आर्किटेक्चर#
- ग्राहक या बिज़नेस की कार्रवाई: कोई व्यक्ति मैसेज भेजता है, या कोई मंज़ूर वर्कफ़्लो तय करता है कि बिज़नेस का मैसेज भेजा जा सकता है।
- नीति और सहमति की जाँच: एप्लिकेशन मैसेज का प्रकार, सहमति की स्थिति, ग्राहक सेवा विंडो, सप्रेशन और टेम्पलेट की ज़रूरत जाँचता है।
- आउटबाउंड रिक्वेस्ट: एप्लिकेशन फ़ोन-नंबर के
/messagesएंडपॉइंट पर मैसेज ऑब्जेक्ट भेजता है। - तुरंत मिलने वाला जवाब: सफल रिक्वेस्ट एक WhatsApp मैसेज आइडेंटिफ़ायर लौटाती है। इसका मतलब है कि API ने उसे स्वीकार कर लिया, यह ज़रूरी नहीं कि प्राप्तकर्ता तक पहुँच भी गया हो।
- स्टेटस webhook: बाद के इवेंट स्थिति में बदलाव बताते हैं। उन्हें मैसेज आइडेंटिफ़ायर के साथ सेव करें।
- इनबाउंड webhook: ग्राहक का जवाब सब्सक्राइब किए हुए एंडपॉइंट पर आता है और बातचीत के वर्कफ़्लो में जाता है।
- इंसान या ऑटोमैटिक संभाल: इनबॉक्स किसी को मालिक असाइन करता है, ऑटोमेशन अपने रिलीज़ नियमों के भीतर चलता है, और CRM को सिर्फ़ तय किए हुए इवेंट मिलते हैं।
Meta का आधिकारिक मैसेज कलेक्शन एंडपॉइंट और मैसेज के प्रकार बताता है। webhook कलेक्शन सब्सक्रिप्शन की सतह दिखाता है।
एसेट और उनका काम#
| एसेट | काम | मालिक साफ़ न हो तो क्या बिगड़ता है |
|---|---|---|
| Meta बिज़नेस | बिज़नेस की पहचान और अनुमतियाँ | ऑनबोर्डिंग या एक्सेस में रुकावट |
| WhatsApp Business Account | नंबरों और टेम्पलेट का कंटेनर | अलग-अलग ब्रांड के गलत एसेट जुड़ जाना |
| फ़ोन-नंबर ID | API भेजने वाले की पहचान | मैसेज गलत नंबर से जाना |
| एक्सेस टोकन | रिक्वेस्ट की अनुमति | आउटेज या सुरक्षा का जोखिम |
| webhook एंडपॉइंट | इनबाउंड और स्टेटस इवेंट का रिसीवर | काम का खो जाना, दोहराया जाना या देर से होना |
| टेम्पलेट | समीक्षा से पास, दोबारा इस्तेमाल होने वाला मैसेज ढाँचा | रिजेक्शन, गलत कैटेगरी या गलत शब्द |
| सहमति का रिकॉर्ड | अनुमति वाली बातचीत का सबूत | बिना अनुमति का संपर्क और शिकायतें |
| बातचीत का मालिक | अगली कार्रवाई का ज़िम्मेदार व्यक्ति | दोहराए गए या लावारिस जवाब |
webhook रिसीवर: पाँच नियम#
- वेरिफ़ाई करें: webhook वेरिफ़िकेशन का प्रवाह पूरा करें और Meta के मौजूदा निर्देशों के हिसाब से रिक्वेस्ट की प्रामाणिकता जाँचें।
- तुरंत स्वीकार करें: धीमे enrichment या AI के काम से पहले ज़रूरी सफलता का जवाब लौटा दें।
- पहले सेव करें: एसिंक्रोनस प्रोसेसिंग से पहले कच्चा इवेंट उसके आइडेंटिफ़ायर के साथ सेव करें।
- डुप्लीकेट हटाएँ: मान लें कि डिलीवरी दोबारा हो सकती है। दोहराया गया इवेंट दूसरा जवाब, टिकट या डील नहीं बनाना चाहिए।
- निगरानी रखें: रिसीव का समय, प्रोसेसिंग का समय, रीट्राई, डेड लेटर और बेमेल पहचान गिनें।
कई "WhatsApp इंटीग्रेशन" यहीं आकर भरोसेमंद नहीं रहते। डेमो सिर्फ़ सीधा रास्ता साबित करता है। असली ऑपरेटिंग सिस्टम को idempotency key और रीप्ले की प्रक्रिया साबित करती है।
टेम्पलेट का वर्कफ़्लो, बिना सुनी-सुनाई बातों के#
टेम्पलेट भेजने से पहले एप्लिकेशन को मंज़ूर टेम्पलेट का नाम, भाषा और मेल खाते कंपोनेंट चाहिए। Meta का आधिकारिक टेम्पलेट कलेक्शन बनाना, पाना, बदलना और हटाना, और कंपोनेंट ढाँचों के उदाहरण दिखाता है।
रिलीज़ का यह क्रम अपनाएँ:
- एक साफ़ मक़सद लिखें और संभावित कैटेगरी चुनें।
- हर वेरिएबल का मतलब रखें और असली जैसे सैंपल वैल्यू दें।
- जिन लोगों को भेजना है, उनके लिए सहमति और सप्रेशन के नियम जाँचें।
- समर्थित मैनेजमेंट सतह से जमा करें।
- टेम्पलेट ID, भाषा, स्थिति, समीक्षा किया हुआ टेक्स्ट और मालिक सेव करें।
- पहले अंदर के टेस्ट ऑडियंस को भेजें और स्टेटस webhook देखें।
- क्वालिटी पर नज़र रखें और जब ऑडियंस या इस्तेमाल बेमेल हो जाए तो रोक दें।
345 मैसेज के ड्राफ़्ट वाली लाइब्रेरी शब्द चुनने में मदद कर सकती है, पर ड्राफ़्ट पहले से मंज़ूर नहीं होता और कोई भी चेकलिस्ट मंज़ूरी की गारंटी नहीं दे सकती।
सीधे बनाएँ या प्लेटफ़ॉर्म लें?#
| ज़िम्मेदारी | सीधे Cloud API पर बनाना | मैनेज्ड इनबॉक्स या प्रोवाइडर |
|---|---|---|
| Meta ऑनबोर्डिंग और अनुमतियाँ | आपकी टीम की ज़िम्मेदारी | प्रोवाइडर कुछ हिस्से बताता या संभालता है |
| webhook रिसीवर और रीट्राई | आपका इंजीनियरिंग सिस्टम | प्रोवाइडर का सिस्टम; सबूत माँगें |
| एजेंट इनबॉक्स और असाइनमेंट | आप बनाते हैं या जोड़ते हैं | आम तौर पर प्रोडक्ट का हिस्सा |
| CRM फ़ील्ड की मैपिंग | अपनी तरह का कॉन्ट्रैक्ट | नेटिव कनेक्टर या कॉन्फ़िगर होने वाली मैपिंग |
| सुरक्षा और ऑडिट का सबूत | आपके नियंत्रण | साझा ज़िम्मेदारी |
| बदलावों का प्रबंधन | आपकी रिलीज़ प्रक्रिया | प्रोवाइडर की रिलीज़ और आपका कॉन्फ़िगरेशन |
जब संगठन को मैसेजिंग के नतीजे चाहिए, लेकिन वह webhook और इनबॉक्स प्रोडक्ट चलाना नहीं चाहता, तब मैनेज्ड प्लेटफ़ॉर्म लें। सीधे तब बनाएँ जब API का व्यवहार ही आपकी बौद्धिक संपदा हो और टीम प्रोडक्शन की भरोसेमंदी की ज़िम्मेदारी ले सके।
सिस्टम-ऑफ़-रिकॉर्ड का नक्शा#
हर तरह के डेटा का एक मालिक लिखें:
- ग्राहक की पहचान: CRM, आइडेंटिटी सर्विस या मैसेजिंग प्लेटफ़ॉर्म।
- सहमति और सप्रेशन: एक ही प्रामाणिक बही, "जिसने आख़िर में अपडेट किया वही सही" कभी नहीं।
- कच्चा मैसेज इवेंट: प्रोवाइडर ID के साथ न बदला जा सकने वाला इवेंट स्टोर।
- बातचीत की स्थिति: इनबॉक्स का वर्कफ़्लो।
- टिकट या डील: CRM/हेल्प डेस्क, बनाने और अपडेट करने के साफ़ नियमों के साथ।
- ज्ञान का जवाब: मालिक और समीक्षा की तारीख़ वाला वर्ज़न किया हुआ स्रोत।
WhatsApp CRM आर्किटेक्चर वर्कशीट (अंग्रेज़ी) इस नक्शे को फ़ील्ड, इवेंट, टकराव और रिकवरी तक फैलाती है।
लॉन्च से पहले के दस टेस्ट#
- सही इनबाउंड टेक्स्ट एक ही बातचीत बनाए।
- दोहराया गया webhook इवेंट दोहरी कार्रवाई न करे।
- फ़ोटो, डॉक्यूमेंट, रिप्लाई और असमर्थित payload अपेक्षित रास्ते में जाएँ।
- टेम्पलेट रिक्वेस्ट में सही भाषा और वेरिएबल का सही क्रम हो।
- स्वीकार, डिलीवर, पढ़ा गया और विफल की स्थितियाँ एक ही मैसेज ID से जुड़ें।
- ऑप्ट-आउट किया हुआ या अज्ञात सहमति वाला कॉन्टैक्ट डिज़ाइन के मुताबिक़ रोका जाए।
- ग्राहक का जवाब, टकराने वाले किसी भी तय ऑटोमेशन को रद्द कर दे।
- एजेंट को सौंपने पर संदर्भ बना रहे और दूसरा लेखक न बन सके।
- एक्सपायर या रद्द क्रेडेंशियल अलर्ट दे और रिकवरी का मालिक तय हो।
- webhook आउटेज के बाद दोबारा चलाने पर दो बार मैसेज न जाए।
कीमत: परतों को अलग रखें#
लागत को दो बहियों में बाँटें। पहली, Meta का मैसेजिंग शुल्क, जो मौजूदा नियमों, कैटेगरी, प्राप्तकर्ता के बाज़ार और दूसरी शर्तों पर निर्भर है। दूसरी, सॉफ़्टवेयर या प्रोवाइडर की लागत, जो सब्सक्रिप्शन, सीट शुल्क, सेवा शुल्क या मार्कअप हो सकती है। किसी पुराने लेख से दर उठाकर अनुमान में न डालें।
WhatsApp API प्राइसिंग कैलकुलेटर को वर्कशीट की तरह इस्तेमाल करें और अंतिम आँकड़े Meta और प्रोवाइडर के मौजूदा रेट कार्ड से मिलाएँ।
व्यावहारिक अगला कदम#
अगर आप API सीधे चलाना चाहते हैं, तो Meta के आधिकारिक Postman कलेक्शन से शुरू करें और इनबॉक्स का UI बनाने से पहले webhook के टेस्ट बनाएँ। अगर आप मैनेज्ड ऑपरेटिंग लेयर चाहते हैं, तो Instant Reply का WhatsApp API वर्कफ़्लो, टीम इनबॉक्स और मौजूदा सॉफ़्टवेयर प्लान देखें। दोनों में से कोई भी रास्ता हो, गड़बड़ी वाले टेस्ट पास होने के बाद ही लॉन्च करें।