सामग्री पर जाएँ
Wiz Message
Cloud API के अनुरूप

पहले से WhatsApp Cloud API पर बना रखा है? बस होस्ट और टोकन बदलिए।

यह "हमारे पास भी API है" वाली बात नहीं है। यह वही API है। एंडपॉइंट पाथ Meta जैसे ही हैं, रिक्वेस्ट बॉडी वैसी ही, रिस्पॉन्स वैसे ही, और एरर Meta के अपने एनवेलप में आते हैं — इसलिए आपने जो एरर हैंडलिंग पहले लिख रखी है वह चलती रहती है। अपने क्लाइंट को दूसरे होस्ट पर लगाइए, टोकन बदलिए, और बस।

इनमें शामिलWiz BotWiz CampaignWiz Pro

प्लान देखेंप्राइसिंग देखें
एक होस्ट और एक टोकन। बाक़ी इंटीग्रेशन को हाथ नहीं लगता
दो बदलाव
विफलताएँ Meta के अपने एरर एनवेलप में आती हैं, इसलिए मौजूदा हैंडलिंग वैसी ही लागू रहती है
वही एरर
आपके URL में पिन किया वर्ज़न Meta के उसे हटाने के बाद भी चलता रहता है
वर्ज़न की चिंता नहीं

यह किसके लिए है

वह कारोबार या एजेंसी जो Meta के Cloud API को जोड़ने के लिए पहले ही डेवलपर को पैसे दे चुकी है — और माइग्रेशन के लिए दोबारा नहीं देगी।

यह किस चिंता का जवाब देता है

"प्लेटफ़ॉर्म बदलने का मतलब है दोबारा इंटीग्रेशन।" तब नहीं, जब एंडपॉइंट, पेलोड और एरर के आकार बिलकुल एक जैसे हों।

माइग्रेशन कैसे होता है

  1. एक की बनाइए

    डैशबोर्ड में API की बनाइए। इसे उसी हेडर आकार में दिया जाता है जिसमें Meta का टोकन आता है।

  2. बेस URL बदलिए

    अपने मौजूदा क्लाइंट को Meta के बजाय संगत होस्ट पर लगाइए।

  3. टोकन बदलिए

    अपनी की को बियरर टोकन की तरह इस्तेमाल कीजिए। रिक्वेस्ट बनाने के तरीक़े में कुछ नहीं बदलता।

  4. अपने मौजूदा टेस्ट चलाइए

    वही पाथ, वही बॉडी, वही रिस्पॉन्स, वही एरर एनवेलप — आपका टेस्ट सूट ही माइग्रेशन की जाँच है।

क्या-क्या मिरर किया गया है

वे एंडपॉइंट जो असल इंटीग्रेशन सबसे ज़्यादा इस्तेमाल करते हैं, उन्हीं पाथ पर जिन्हें Meta दस्तावेज़ों में देता है।

  • संदेश भेजना उसी मैसेज एंडपॉइंट पर जिसे आप पहले से कॉल करते हैं
  • संदेश पढ़ा हुआ चिह्नित करना और टाइपिंग संकेत भेजना, उसी रिक्वेस्ट बॉडी के साथ
  • मीडिया अपलोड, जो उसी आकार में id लौटाता है जिसे आप पहले से पार्स करते हैं
  • संदेश टेम्पलेट की सूची
  • मीडिया मेटाडेटा, डाउनलोड और डिलीट — मेटाडेटा एक चलता-फिरता URL लौटाता है जिसे आपका क्लाइंट यह जाने बिना ला सकता है कि वह किसका है
  • बाक़ी दस्तावेज़ीकृत पाथ के लिए अनुमति-सूची वाला पासथ्रू
  • एरर Meta के अपने एनवेलप में, इसलिए मौजूदा एरर हैंडलिंग चलती रहती है

वर्ज़न पिनिंग जो Meta के हटाने के बाद भी टिकती है

URL का वर्ज़न वाला हिस्सा स्वीकार किया जाता है और फिर अनदेखा कर दिया जाता है। यह शॉर्टकट लगता है, पर असल में यह ऐसा फ़ायदा है जिसे खुलकर कहना चाहिए: पुराने वर्ज़न पर पिन किया क्लाइंट Meta के उसे हटा देने के बाद भी चलता रहता है, और नया पिन करने से आप किसी ऐसे व्यवहार में शामिल नहीं हो जाते जो तैनात ही नहीं है। आपके कोड में पड़ा वर्ज़न रखरखाव का बोझ नहीं रह जाता।

यह अनुमति-सूची है, आँख मूँदकर चलने वाला प्रॉक्सी नहीं

सिर्फ़ दस्तावेज़ीकृत पाथ मौजूद हैं, और हर एक यह जाँचता है कि पाथ में दिया पहचानकर्ता उसी की का है जो कॉल कर रही है। इससे सतह ऑडिट करने लायक रहती है — आप ठीक-ठीक बता सकते हैं कि यह एंडपॉइंट कहाँ तक पहुँच सकता है — और इसका मतलब यह भी है कि आपके क्लाइंट की ग़लती पर आपको ईमानदार एरर मिलता है, न कि रिक्वेस्ट कहीं अनपेक्षित जगह भेज दी जाती है। हर भेजा हुआ संदेश प्लेटफ़ॉर्म से होकर जाता है, इसलिए वही रेट लिमिटिंग और खाता सुरक्षा लागू रहती है जो कहीं और।

जानना ज़रूरी है

यह सुविधा कहाँ तक जाती है, साफ़ शब्दों में — ताकि ख़रीदने के बाद यहाँ कुछ भी चौंकाए नहीं।

  • सक्रिय सब्सक्रिप्शन चाहिए, और बाक़ी API की तरह वही एंटाइटलमेंट व रेट-लिमिट जाँचें लागू होती हैं।
  • यह अनुमति-सूची है, खुला प्रॉक्सी नहीं। सिर्फ़ दस्तावेज़ीकृत पाथ मौजूद हैं, और हर एक यह पुष्टि करता है कि पाथ का पहचानकर्ता आपकी की का है।
  • वर्ज़न वाला हिस्सा मिलाया तो जाता है पर फिर अनदेखा कर दिया जाता है — कॉल हमेशा कॉन्फ़िगर किए प्लेटफ़ॉर्म वर्ज़न पर जाती हैं। यह जानबूझकर है, और इसी वजह से पुराना पिन चलता रहता है।
  • सिर्फ़ GET, POST और DELETE। PUT या PATCH नहीं है, क्योंकि उनका भरोसेमंद दिखने वाला एरर देना 404 देने से कम ईमानदार होता।
  • भेजे गए संदेश सीधे बाहर जाने के बजाय प्लेटफ़ॉर्म गेटवे से होकर जाते हैं, इसलिए खाता-स्तर की रेट लिमिटिंग और सुरक्षा लागू रहती है।

इनमें शामिल

यह सुविधा नीचे दिए गए प्लान का हिस्सा है।

  • Wiz Bot
  • Wiz Campaign
  • Wiz Pro
प्लान और क़ीमतें देखें
FAQ

अक्सर पूछे जाने वाले प्रश्न

मेरे कोड में कितना बदलना पड़ेगा?

बेस URL और टोकन। पाथ, रिक्वेस्ट बॉडी, रिस्पॉन्स और एरर आकार वही हैं — यही इस सुविधा का पूरा मक़सद है।

क्या यह सचमुच वही API है, या बस मिलती-जुलती?

वही पाथ, वही रिक्वेस्ट बॉडी, वही रिस्पॉन्स और वही एरर एनवेलप। "मिलती-जुलती" होने पर भी आपको दोबारा लिखना पड़ता; यह इस तरह बनाया गया है कि आपके मौजूदा टेस्ट बिना बदले पास हों।

मेरे URL में लिखे वर्ज़न नंबर का क्या?

उसे स्वीकार कर के अनदेखा कर दिया जाता है, इसलिए पुराने वर्ज़न पर पिन किया क्लाइंट Meta के उसे हटा देने के बाद भी चलता रहता है। आपको हर डिप्रिकेशन के पीछे भागना नहीं पड़ता।

कौन-से HTTP मेथड समर्थित हैं?

GET, POST और DELETE। PUT या PATCH नहीं — जो चीज़ मौजूद ही नहीं है उसके लिए भरोसेमंद दिखने वाला एरर देने से हम ईमानदार 404 देना बेहतर मानते हैं।

क्या Meta की हर सुविधा उपलब्ध है?

नहीं। यह दस्तावेज़ीकृत पाथ की जानबूझकर बनाई गई अनुमति-सूची है, आँख मूँदकर चलने वाला प्रॉक्सी नहीं, ताकि सतह ऑडिट करने लायक रहे।

क्या मुझे प्लेटफ़ॉर्म की अपनी सुविधाएँ भी मिलती हैं?

हाँ। संदेश उसी प्लेटफ़ॉर्म से होकर जाते हैं जिसे आपका डैशबोर्ड इस्तेमाल करता है, इसलिए इनबॉक्स, विश्लेषण, खाता सुरक्षा और रेट लिमिटिंग सब लागू रहती हैं।

दोबारा इंटीग्रेशन किए बिना बदलिए

होस्ट बदलिए, टोकन बदलिए, और अपने मौजूदा टेस्ट चला लीजिए।

प्लान देखें

अधिक विशेषताएं एक्सप्लोर करें

अन्य टूल खोजें जो WizMessage को पूर्ण WhatsApp प्लेटफ़ॉर्म बनाते हैं।