मैं LLM API गेटवे को वॉइस और WhatsApp एजेंट्स से कैसे कनेक्ट कर सकता हूँ? एक डेवलपर गाइड

मैं LLM API गेटवे को वॉइस और WhatsApp एजेंट्स से कैसे कनेक्ट कर सकता हूँ? एक डेवलपर गाइड

मैं LLM API गेटवे को वॉइस और WhatsApp एजेंट्स से कैसे कनेक्ट कर सकता हूँ? अपने चैनल प्रदाताओं और मॉडल लेयर के बीच एक HTTPS गेटवे रखें: प्रत्येक इनबाउंड इवेंट को सत्यापित करें, वॉइस और WhatsApp पेलोड को एक आंतरिक संदेश कॉन्ट्रैक्ट में सामान्यीकृत करें, रूटिंग और सुरक्षा नीतियाँ लागू करें, चयनित LLM को कॉल करें, फिर परिणाम को WhatsApp संदेश या लाइव वॉइस प्रतिक्रिया में अनुकूलित करें। यह चैनल-निरपेक्ष डिज़ाइन प्रदाता-विशिष्ट वेबहुक और मॉडल इंटीग्रेशन को स्पष्ट अडैप्टर सीमाओं के पीछे रखता है।

आवश्यकता काफी बड़ी है: Meta का कहना है कि दुनिया भर में 2 बिलियन से अधिक लोग WhatsApp का उपयोग करते हैं, जिससे WhatsApp ग्राहकों से जुड़ाव का एक महत्वपूर्ण चैनल बन जाता है, जबकि वॉइस एजेंट्स एक अलग इंजीनियरिंग चुनौती पेश करते हैं—प्रतिक्रियाएँ क्रमिक रूप से तैयार होनी चाहिए, सत्रों का सहसंबंध बना रहना चाहिए, और कॉल करने वाले एजेंट के वाक्य के बीच में उसे रोक सकते हैं। एक टेक्स्ट उत्तर सामान्य अनुरोध-प्रतिक्रिया प्रोसेसिंग को सहन कर सकता है; एक लाइव कॉल आमतौर पर ऑडियो शुरू होने से पहले पूर्ण बहु-पैराग्राफ LLM प्रतिक्रिया की प्रतीक्षा नहीं कर सकता।

यह गाइड दिखाती है कि उत्पादन-केंद्रित डेवलपर वर्कफ़्लो के रूप में यह कनेक्शन कैसे बनाया जाए। आप सीखेंगे कि:

• WhatsApp वेबहुक, वॉइस मीडिया या सत्र एंडपॉइंट, एक आंतरिक इवेंट स्कीमा और LLM API गेटवे वाली आर्किटेक्चर कैसे डिज़ाइन करें।
• टेक्स्ट, मीडिया, कॉल, इंटरप्शन और डिलीवरी इवेंट्स को एक साझा TypeScript कॉन्ट्रैक्ट में कैसे सामान्यीकृत करें।
• नीति जाँच, बजट, रीट्राई, टाइमआउट और सर्किट ब्रेकर के साथ विभिन्न मॉडल प्रदाताओं के बीच अनुरोधों को कैसे रूट करें।
• सिंक्रोनस WhatsApp प्रतिक्रियाओं को स्ट्रीमिंग वॉइस आउटपुट और बार्ज-इन हैंडलिंग से कैसे अलग करें।
• टूल्स को सुरक्षित रूप से कैसे निष्पादित करें, आर्ग्युमेंट्स को कैसे सत्यापित करें, वार्तालाप स्थिति को कैसे बनाए रखें और डुप्लिकेट वेबहुक प्रोसेसिंग को कैसे रोकें।
• चैनल-विशिष्ट प्रतिक्रियाओं को कैसे फ़ॉर्मैट करें और सामान्य प्रमाणीकरण, विलंबता, मीडिया और डिलीवरी विफलताओं का निवारण कैसे करें।

उदाहरण प्रदाता-निरपेक्ष रहेंगे: WhatsApp सिग्नेचर सत्यापन, वॉइस मीडिया स्ट्रीमिंग, कोडेक रूपांतरण और रीयलटाइम LLM सत्र विक्रेता के अनुसार अलग-अलग होते हैं, इसलिए प्रत्येक इंटीग्रेशन बिंदु को एक अडैप्टर के रूप में स्पष्ट रूप से चिह्नित किया जाएगा, न कि सार्वभौमिक रूप से पोर्टेबल रूप में प्रस्तुत किया जाएगा। CallMissed जैसे प्लेटफ़ॉर्म इस व्यापक अभिसरण को दर्शाते हैं, जो वॉइस, WhatsApp और बहुभाषी AI क्षमताओं के साथ OpenAI-संगत गेटवे को जोड़ते हैं, जिसमें 22 भारतीय भाषाओं का समर्थन भी शामिल है।

केंद्रीय कार्यान्वयन सिद्धांत सरल है: एक आंतरिक conversation contract, कई चैनल अडैप्टर और बीच में एक नीति-नियंत्रित LLM गेटवे। यह पृथक्करण स्थापित हो जाने के बाद, कोई अन्य मॉडल, वॉइस प्रदाता, WhatsApp वर्कफ़्लो या टूल जोड़ना इंटीग्रेशन का कार्य बन जाता है—हर एजेंट को फिर से लिखने की आवश्यकता नहीं रहती।

मैं LLM API गेटवे को वॉइस और WhatsApp एजेंट्स से कैसे कनेक्ट कर सकता हूँ? एक चैनल-निरपेक्ष HTTPS गेटवे का उपयोग करें

मैं LLM API गेटवे को वॉइस और WhatsApp एजेंट्स से कैसे कनेक्ट कर सकता हूँ? प्रत्येक प्रदाता और मॉडल लेयर के बीच एक चैनल-निरपेक्ष HTTPS गेटवे रखें: इनबाउंड अनुरोधों को सत्यापित करें, WhatsApp और वॉइस इवेंट्स को एक आंतरिक कॉन्ट्रैक्ट में सामान्यीकृत करें, उन्हें नीति नियंत्रणों के माध्यम से रूट करें और LLM प्रतिक्रिया को सही चैनल के अनुसार अनुकूलित करें। WhatsApp संदेश-केंद्रित बना रहता है, जबकि वॉइस के लिए क्रमिक आउटपुट, सत्र सहसंबंध और इंटरप्शन हैंडलिंग आवश्यक होती है।

मुझे किस आर्किटेक्चर का उपयोग करना चाहिए?

किनारों पर अडैप्टर रखें और बिज़नेस लॉजिक को गेटवे के अंदर रखें:

1. इनबाउंड अडैप्टर: WhatsApp एजेंट वेबहुक या वॉइस-प्रदाता मीडिया/सत्र इवेंट प्राप्त करें।
2. सुरक्षा लेयर: सिग्नेचर सत्यापित करें, टेनेंट्स को प्रमाणित करें और रीप्ले किए गए या अनधिकृत अनुरोधों को अस्वीकार करें।
3. नॉर्मलाइज़र: चैनल पेलोड को साझा ConversationEvent में बदलें।
4. गेटवे राउटर: एक LLM चुनें, बजट और टाइमआउट लागू करें और स्वीकृत टूल्स को निष्पादित करें।
5. रिस्पॉन्स अडैप्टर: WhatsApp संदेश भेजें या सक्रिय कॉल में जेनरेटेड ऑडियो स्ट्रीम करें।
6. ऑब्ज़र्वेबिलिटी लेयर: सहसंबंध IDs, विलंबता, स्थिति और संशोधित त्रुटियों को रिकॉर्ड करें।

Meta का कहना है कि दुनिया भर में 2 बिलियन से अधिक लोग WhatsApp का उपयोग करते हैं, इसलिए आर्किटेक्चर को WhatsApp-विशिष्ट फ़ील्ड्स को मॉडल कोड से जोड़े बिना उच्च-मात्रा वाले संदेश वेबहुक का समर्थन करना चाहिए। वॉइस के लिए, प्रदाता की मीडिया स्ट्रीम और LLM के रीयलटाइम इंटरफ़ेस को अलग-अलग अडैप्टर मानें; उनके कोडेक, फ़्रेमिंग और इवेंट नाम सार्वभौमिक रूप से पोर्टेबल नहीं होते।

मैं वॉइस और WhatsApp इवेंट्स को सामान्यीकृत कैसे करूँ?

मॉडल लॉजिक लिखने से पहले एक आंतरिक कॉन्ट्रैक्ट परिभाषित करें:

type ConversationEvent = {
  id: string; channel: "whatsapp" | "voice";
  tenantId: string; sessionId: string; userId?: string;
  kind: "text" | "audio" | "image" | "interrupt" | "status";
  text?: string; mediaUrl?: string;
  receivedAt: string; raw?: unknown;
};

एक प्रदाता-निरपेक्ष पार्सर चैनल के अंतर को स्पष्ट कर सकता है:

function normalize(input: any, channel: ConversationEvent["channel"]): ConversationEvent {
  if (channel === "whatsapp") return {
    id: input.messageId, channel, tenantId: input.tenantId,
    sessionId: `wa:${input.userId}`, userId: input.userId,
    kind: input.type === "text" ? "text" : "audio",
    text: input.text, mediaUrl: input.mediaUrl,
    receivedAt: new Date().toISOString()
  };

  return {
    id: input.eventId, channel, tenantId: input.tenantId,
    sessionId: input.callId, kind: input.type === "speech" ? "text" : "interrupt",
    text: input.transcript, receivedAt: new Date().toISOString()
  };
}

WhatsApp पार्सर को टेक्स्ट, मीडिया, डिलीवरी रसीदों और संदेश IDs को मैप करना चाहिए। वॉइस पार्सर को ट्रांसक्रिप्ट, ऑडियो फ़्रेम, कॉल IDs और बार्ज-इन इवेंट्स को मैप करना चाहिए। प्रोसेसिंग से पहले event.id के आधार पर एक इडेम्पोटेंसी स्टोर जोड़ें।

HTTPS गेटवे अनुरोधों को कैसे रूट करता है?

क्रेडेंशियल्स को सर्वर-साइड रखें और एक एप्लिकेशन एंडपॉइंट एक्सपोज़ करें:

app.post("/events/:channel", async (req, res) => {
  await verifySignature(req);              // provider-specific adapter
  const event = normalize(req.body, req.params.channel as any);
  if (await seen(event.id)) return res.sendStatus(200);

  const reply = await gateway.chat({
    model: routeFor(event.channel),
    messages: await loadContext(event.sessionId),
    timeoutMs: event.channel === "voice" ? 1200 : 8000
  });

  await adaptAndDeliver(event, reply);     // WhatsApp send or voice stream
  res.sendStatus(200);
});

रीट्राई का उपयोग केवल अस्थायी विफलताओं के लिए करें और एक्सपोनेंशियल बैकऑफ़ तथा सर्किट ब्रेकर का उपयोग करें। RFC 9110 429 को रेट लिमिटिंग, 502 को अमान्य अपस्ट्रीम प्रतिक्रिया, 503 को अस्थायी अनुपलब्धता और 504 को अपस्ट्रीम टाइमआउट के लिए परिभाषित करता है—इन स्थितियों का लॉग और मॉनिटरिंग में निरंतर उपयोग करें।

CallMissed’s OpenAI-compatible gateway जैसे समाधान इस चैनल-निरपेक्ष दिशा को दर्शाते हैं: एक मॉडल-केंद्रित इंटीग्रेशन वॉइस और WhatsApp अनुभवों के पीछे रहकर कई AI क्षमताओं के बीच रूटिंग कर सकता है।

गेटवे बनाने से पहले मुझे किन चीज़ों की आवश्यकता होगी? (तालिका)

निर्माण शुरू करने से पहले पाँच परतें तैयार करें: सुरक्षित HTTPS एंडपॉइंट, प्रदाता क्रेडेंशियल, साझा इवेंट स्कीमा, वॉइस-मीडिया रणनीति, और रूटिंग, पुनःप्रयास तथा ऑब्ज़र्वेबिलिटी के लिए परिचालन नियंत्रण। Meta की रिपोर्ट के अनुसार दुनिया भर में 2 बिलियन से अधिक लोग WhatsApp का उपयोग करते हैं, इसलिए गेटवे को WhatsApp डिलीवरी, सहमति और डुप्लिकेट-इवेंट हैंडलिंग को उत्पादन आवश्यकताओं के रूप में देखना चाहिए—वैकल्पिक ऐड-ऑन के रूप में नहीं।

गेटवे कोड लिखने से पहले मुझे क्या तैयार करना चाहिए?

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

किन चैनल अंतरों पर मुझे जल्दी निर्णय लेना चाहिए?

WhatsApp संदेश-केंद्रित है, इसलिए एडाप्टर आम तौर पर एक वेबहुक प्राप्त करता है, गेटवे को इनवोक करता है और WhatsApp Business API के माध्यम से एक अलग आउटबाउंड संदेश भेजता है। टेक्स्ट और मीडिया सामान्यीकरण, डिलीवरी-स्टेटस कॉलबैक, उपयोगकर्ता सहमति और जहाँ लागू हो वहाँ टेम्पलेट नियमों के लिए योजना बनाएँ। messageId-आधारित आइडेम्पोटेंसी स्टोर पुनःप्रयासों के कारण डुप्लिकेट उत्तर बनने से रोकता है।

वॉइस सेशन और लेटेंसी के प्रति संवेदनशील है। तय करें कि वॉइस प्रदाता ऑडियो WebSocket, HTTP कॉलबैक या विक्रेता-विशिष्ट मीडिया स्ट्रीम के माध्यम से भेजता है। गेटवे को LLM से पहले स्पीच-टू-टेक्स्ट और उसके बाद टेक्स्ट-टू-स्पीच की आवश्यकता हो सकती है, या वह रीयलटाइम मॉडल इंटरफ़ेस से ब्रिज कर सकता है। ये अलग-अलग प्रोटोकॉल हैं: वॉइस प्रदाता की ऑडियो स्ट्रीम LLM के रीयलटाइम एंडपॉइंट के साथ स्वतः संगत नहीं होती।

मुझे कौन-सा परीक्षण डेटा एकत्र करना चाहिए?

कार्यान्वयन से पहले फ़िक्स्चर बनाएँ:

• एक WhatsApp टेक्स्ट संदेश, छवि, ऑडियो नोट और डिलीवरी-स्टेटस इवेंट।
• एक वॉइस session.started, ट्रांसक्रिप्ट, व्यवधान और session.ended इवेंट।
• अमान्य सिग्नेचर, समाप्त टाइमस्टैम्प, डुप्लिकेट ID, टाइमआउट और प्रदाता की 5xx प्रतिक्रियाएँ।
• मान्य, अनुपस्थित और दुर्भावनापूर्ण आर्ग्युमेंट वाले टूल कॉल।

भारतीय परिनियोजनों के लिए बहुभाषी परीक्षण कवरेज महत्वपूर्ण है। CallMissed 22 भारतीय भाषाओं के समर्थन का दस्तावेज़ देता है, जो यह दर्शाता है कि भाषा पहचान, ट्रांसक्रिप्शन और संश्लेषित वाणी आंतरिक कॉन्ट्रैक्ट में स्पष्ट फ़ील्ड होने चाहिए, न कि चैनल एडाप्टर के भीतर छिपी धारणाएँ।

एक वॉइस और WhatsApp गेटवे के लिए मुझे किस आर्किटेक्चर का उपयोग करना चाहिए?

मैं LLM API गेटवे को वॉइस और WhatsApp एजेंट से कैसे जोड़ सकता हूँ? चैनल-निरपेक्ष नियंत्रण तल के रूप में HTTPS गेटवे का उपयोग करें: प्रदाता अनुरोधों का सत्यापन करें, WhatsApp और वॉइस इवेंट को एक आंतरिक कॉन्ट्रैक्ट में सामान्यीकृत करें, रूटिंग और सुरक्षा नीतियाँ लागू करें, चयनित LLM को कॉल करें और परिणाम को मूल चैनल के अनुरूप ढालें। WhatsApp संदेश प्रबंधन को अनुरोध-आधारित रखें, जबकि वॉइस को सेशन-उन्मुख, स्ट्रीमिंग वर्कलोड के रूप में संभालें।

एक वॉइस और WhatsApp गेटवे के लिए मुझे किस आर्किटेक्चर का उपयोग करना चाहिए?

एज पर अलग-अलग चैनल एडाप्टर और उनके पीछे एक साझा ऑर्केस्ट्रेशन पाइपलाइन का उपयोग करें:

WhatsApp webhook ─┐
                  ├─> Verify ─> Normalize ─> Session lookup
Voice media/API ──┘                            │
                                               v
                                  Policy + model routing
                                               │
                                               v
                                      LLM API gateway
                                               │
                                  Tools / conversation state
                                               │
                         ┌─────────────────────┴──────────────────┐
                         v                                        v
                 WhatsApp response                         Voice audio stream

यह डिज़ाइन महत्वपूर्ण है क्योंकि Meta के अनुसार दुनिया भर में WhatsApp के 2 बिलियन से अधिक उपयोगकर्ता हैं, जबकि वॉइस एजेंट को लाइव सेशन, इन्क्रिमेंटल आउटपुट, मीडिया फ़ॉर्मैट और कॉलर के व्यवधानों का प्रबंधन करना होता है। WhatsApp का उत्तर आम तौर पर एक आउटबाउंड संदेश के रूप में पूरा किया जा सकता है; वॉइस एजेंट को लंबे उत्तर का इंतज़ार किए बिना ऑडियो बनाना शुरू कर देना चाहिए।

अनुशंसित घटक हैं:

1. इनबाउंड एडाप्टर: WhatsApp वेबहुक और वॉइस सेशन या मीडिया इवेंट प्राप्त करें।
2. सत्यापन मिडलवेयर: सिग्नेचर, टाइमस्टैम्प, प्रदाता टोकन और टेनेंट प्राधिकरण मान्य करें।
3. नॉर्मलाइज़र: प्रदाता-विशिष्ट पेलोड को साझा इवेंट स्कीमा में परिवर्तित करें।
4. ऑर्केस्ट्रेटर: बातचीत की स्थिति लोड करें, बजट लागू करें, मॉडल चुनें और स्वीकृत टूल निष्पादित करें।
5. LLM गेटवे: चैट, स्पीच, टूल और—जहाँ समर्थित हो—स्ट्रीमिंग या रीयलटाइम मॉडल के लिए एक प्रमाणित इंटरफ़ेस प्रदान करें।
6. आउटबाउंड एडाप्टर: WhatsApp संदेशों को फ़ॉर्मैट करें या संश्लेषित ऑडियो को वॉइस प्रदाता तक स्ट्रीम करें।
7. ऑब्ज़र्वेबिलिटी परत: सहसंबंध ID, टाइमिंग, डिलीवरी स्थिति और छिपाई गई त्रुटियाँ रिकॉर्ड करें।

साझा इवेंट कॉन्ट्रैक्ट में क्या शामिल होना चाहिए?

प्रदाता विवरण को मॉडल परत के बाहर रखें। एक न्यूनतम TypeScript कॉन्ट्रैक्ट दोनों चैनलों का प्रतिनिधित्व कर सकता है:

type Channel = "whatsapp" | "voice";

interface AgentEvent {
  id: string;                 // provider event ID; used for idempotency
  tenantId: string;
  channel: Channel;
  sessionId: string;          // call ID or WhatsApp conversation key
  userId: string;
  type: "text" | "audio" | "media" | "status" | "interrupt";
  text?: string;
  audio?: { codec: string; sampleRateHz: number; base64: string };
  metadata: Record<string, string>;
  receivedAt: string;
}

WhatsApp एडाप्टर टेक्स्ट, मीडिया, डिलीवरी रसीदों और स्थिति परिवर्तनों को इस कॉन्ट्रैक्ट में मैप करता है। वॉइस एडाप्टर कॉल-आरंभ, ऑडियो फ़्रेम, ट्रांसक्रिप्शन, व्यवधान और कॉल-समाप्ति इवेंट्स को मैप करता है। कोडेक रूपांतरण अब भी एडाप्टर की ज़िम्मेदारी है: किसी वॉइस प्रदाता की मीडिया स्ट्रीम अपने-आप LLM के रीयलटाइम इंटरफ़ेस के साथ संगत नहीं होती।

गेटवे को कौन-से HTTP रिस्पॉन्स लौटाने चाहिए?

मानकों पर आधारित रिस्पॉन्स का उपयोग करें और डुप्लिकेट डिलीवरी को स्पष्ट बनाएं:

इन अर्थों को RFC 9110, HTTP Semantics में परिभाषित किया गया है। प्रोडक्शन में, प्रोसेसिंग से पहले इवेंट ID संग्रहीत करें, एक सुरक्षित स्वीकृति लौटाएं, और ऐसी कतार का उपयोग करें जहां प्रदाता की टाइमआउट विंडो मॉडल या टूल निष्पादन समय से कम हो। CallMissed जैसे प्लेटफ़ॉर्म वॉइस और WhatsApp क्षमताओं के साथ OpenAI-संगत गेटवे को जोड़कर इस व्यापक अभिसरण का अनुसरण करते हैं, जिसमें 22 भारतीय भाषाओं का समर्थन भी शामिल है।

मैं वॉइस और WhatsApp इवेंट्स को एक संदेश कॉन्ट्रैक्ट में कैसे सामान्यीकृत करूं?

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

साझा संदेश कॉन्ट्रैक्ट में क्या शामिल होना चाहिए?

एक व्यावहारिक कॉन्ट्रैक्ट में टेक्स्ट, मीडिया, लाइव ऑडियो, व्यवधान और लाइफ़साइकल इवेंट्स को इस तरह प्रस्तुत किया जाना चाहिए कि WhatsApp और वॉइस के एक समान व्यवहार करने का दिखावा न हो:

type Channel = "whatsapp" | "voice";
type EventKind = "message" | "audio" | "interrupt" | "status";

interface NormalizedEvent {
  id: string;                 // provider event ID; used for deduplication
  channel: Channel;
  kind: EventKind;
  tenantId: string;
  conversationId: string;
  senderId: string;
  occurredAt: string;         // ISO-8601 timestamp
  text?: string;
  media?: {
    url?: string;
    mimeType: string;
    bytes?: Uint8Array;
    durationMs?: number;
  };
  replyMode: "message" | "stream";
  replyAddress: string;       // WhatsApp number or voice session ID
  metadata: Record<string, unknown>;
}

WhatsApp के लिए replyMode: "message" और लाइव वॉइस सत्र के लिए replyMode: "stream" का उपयोग करें। किसी वॉइस प्रदाता की मीडिया स्ट्रीम अपने-आप LLM के रीयलटाइम इंटरफ़ेस के साथ संगत नहीं होती: आपके एडाप्टर को प्रदाता के ऑडियो को डिकोड करने, उसका पुनः सैंपलिंग करने, उसे ट्रांसक्राइब करने और जनरेट किए गए ऑडियो को प्रदाता के लिए आवश्यक कोडेक में वापस बदलने की आवश्यकता हो सकती है।

मैं WhatsApp और वॉइस वेबहुक को कैसे पार्स करूं?

किसी भी पेलोड को पार्स करने से पहले प्रदाता के सिग्नेचर का सत्यापन करें। सत्यापन एल्गोरिदम, टाइमस्टैम्प सहनशीलता और हेडर नाम प्रदाता-विशिष्ट होते हैं, इसलिए उन्हें एडाप्टर के भीतर रखें और नीचे दिए गए उदाहरण को सार्वभौमिक न मानें:

function parseWhatsApp(p: any, tenantId: string): NormalizedEvent {
  const m = p.entry?.[0]?.changes?.[0]?.value?.messages?.[0];
  if (!m) throw new Error("unsupported WhatsApp event");

  return {
    id: m.id,
    channel: "whatsapp",
    kind: "message",
    tenantId,
    conversationId: `wa:${m.from}`,
    senderId: m.from,
    occurredAt: new Date(Number(m.timestamp) * 1000).toISOString(),
    text: m.text?.body,
    media: m.image || m.audio
      ? { url: m.image?.id || m.audio?.id,
          mimeType: m.image?.mime_type || "audio/ogg" }
      : undefined,
    replyMode: "message",
    replyAddress: m.from,
    metadata: { providerType: m.type }
  };
}

function parseVoice(p: any, tenantId: string): NormalizedEvent {
  return {
    id: p.eventId,
    channel: "voice",
    kind: p.type === "speech.started" ? "interrupt" : "audio",
    tenantId,
    conversationId: `voice:${p.callId}`,
    senderId: p.callerId,
    occurredAt: new Date().toISOString(),
    text: p.transcript,
    media: p.audio
      ? { bytes: p.audio, mimeType: p.codec || "audio/pcm" }
      : undefined,
    replyMode: "stream",
    replyAddress: p.callId,
    metadata: { sequence: p.sequence }
  };
}

मैं डुप्लिकेट या गलत रूट किए गए इवेंट्स को कैसे रोकूं?

मॉडल को कॉल करने से पहले एक विशिष्ट कंस्ट्रेंट के साथ event.id को स्थायी रूप से संग्रहीत करें। पहले से देखे जा चुके इवेंट के लिए उसकी पिछली प्रोसेसिंग स्थिति की पुष्टि करने के बाद सफलता लौटाएं; अन्यथा वेबहुक रीट्राई से डुप्लिकेट उत्तर या बार-बार टूल कॉल हो सकते हैं।

इसके अतिरिक्त, निम्नलिखित लागू करें:

• बातचीत की खोज के दौरान टेनेंट और प्रेषक प्राधिकरण।
• लॉग में PII को न्यूनतम करना और रिडैक्ट करना।
• वॉइस ऑडियो के लिए अनुक्रम जांच और बार्ज-इन पर स्पष्ट रद्दीकरण।
• डिलीवरी-स्थिति इवेंट्स को उपयोगकर्ता संदेशों से अलग रखना।
• कम समय के लिए वैध, प्रमाणीकरणयुक्त URL के माध्यम से मीडिया प्राप्त करना।

यह कॉन्ट्रैक्ट CallMissed के OpenAI-संगत गेटवे जैसे LLM API गेटवे को चैनल-निरपेक्ष अनुरोध प्राप्त करने देता है, जबकि अंतिम एडाप्टर तय करता है कि उत्तर WhatsApp संदेश बनेगा या वॉइस एजेंट के लिए क्रमिक ऑडियो।

मैं LLM गेटवे के माध्यम से अनुरोधों को कैसे रूट करूं और विफलताओं को कैसे संभालूं?

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

मैं LLM गेटवे के माध्यम से अनुरोधों को कैसे रूट करूं?

गेटवे को रूटिंग के निर्णय टेनेंट नीति, कार्य प्रकार, भाषा, लागत सीमाओं और चैनल की लेटेंसी आवश्यकताओं से लेने चाहिए—न कि सीधे किसी अविश्वसनीय वेबहुक पेलोड से।

type RouteInput = {
  messages: { role: "system" | "user" | "assistant"; content: string }[];
  channel: "whatsapp" | "voice";
  language?: string;
  maxOutputTokens?: number;
};

const routes = {
  fast: { model: "provider-a/fast-chat", timeoutMs: 2_500 },
  quality: { model: "provider-b/quality-chat", timeoutMs: 8_000 }
};

async function callGateway(input: RouteInput) {
  const profile =
    input.channel === "voice" || input.language
      ? routes.fast
      : routes.quality;

  return withRetry(
    () => fetchModel(profile.model, input.messages, profile.timeoutMs),
    { attempts: 2, timeoutMs: profile.timeoutMs }
  );
}

fetchModel को एक ऐसे एडाप्टर के पीछे रखें जो आपके आंतरिक अनुरोध को चयनित प्रदाता के API में रूपांतरित करता हो। CallMissed जैसा OpenAI-संगत गेटवे कई LLM के लिए एक एंडपॉइंट उपलब्ध करा सकता है, जबकि आपका एप्लिकेशन रूटिंग नीति, बजट और चैनल व्यवहार पर नियंत्रण बनाए रखता है।

टाइमआउट और रीट्राई प्रबंधन कैसे काम करना चाहिए?

केवल उन विफलताओं को रीट्राई करें जो संभवतः अस्थायी हों, जैसे कनेक्शन रीसेट, HTTP 429, 502, 503 और 504। गलत अनुरोधों, प्रमाणीकरण विफलताओं, अमान्य टूल तर्कों या ऐसे अनुरोध को बिना सोचे-समझे रीट्राई न करें जिसने पहले ही कोई बाहरी साइड इफ़ेक्ट उत्पन्न कर दिया हो।

async function withRetry<T>(
  operation: () => Promise<T>,
  cfg: { attempts: number; timeoutMs: number }
): Promise<T> {
  let lastError: unknown;

  for (let attempt = 0; attempt < cfg.attempts; attempt++) {
    try {
      return await Promise.race([
        operation(),
        new Promise<never>((_, reject) =>
          setTimeout(() => reject(new Error("upstream_timeout")), cfg.timeoutMs)
        )
      ]);
    } catch (error) {
      lastError = error;
      if (attempt + 1 < cfg.attempts) {
        await new Promise(r => setTimeout(r, 150 * 2 ** attempt));
      }
    }
  }
  throw lastError;
}

टेनेंट, बातचीत और इनबाउंड इवेंट ID से प्राप्त idempotency key का उपयोग करें। यह दोबारा प्रयास किए गए WhatsApp webhook या voice event को डुप्लिकेट उत्तर उत्पन्न करने या किसी tool action को दोहराने से रोकता है।

गेटवे को कौन-सी HTTP विफलताएँ उजागर करनी चाहिए?

अपस्ट्रीम विफलताओं को स्थिर प्रतिक्रियाओं में मैप करें, ताकि चैनल अडैप्टर पूर्वानुमानित रूप से व्यवहार कर सकें। RFC 9110 निम्नलिखित मानक HTTP अर्थ परिभाषित करता है:

लगातार होने वाली अपस्ट्रीम विफलताओं के बाद सर्किट ब्रेकर खुलना चाहिए, नए अनुरोधों को उसी-स्तर के fallback पर भेजना चाहिए और स्वास्थ्य जाँच सफल होने के बाद ही बंद होना चाहिए। provider, model, request ID, latency, status और retry count लॉग करें—लेकिन operational रूप से आवश्यक न होने तक message content और व्यक्तिगत जानकारी को redact करें।

मैं voice response को कैसे stream करूँ और WhatsApp पर संदेश कैसे भेजूँ?

मैं LLM API gateway को voice और WhatsApp agents से कैसे जोड़ सकता हूँ? LLM के output को voice-provider adapter के माध्यम से stream करें, जो text को provider के लिए आवश्यक audio format में बदलता है, जबकि WhatsApp responses को provider के outbound Messages API के माध्यम से भेजें। दोनों paths को एक ही gateway के पीछे रखें, लेकिन voice को एक incremental, interruptible session और WhatsApp को एक idempotent message-delivery workflow मानें।

मैं voice response को कैसे stream करूँ?

किसी voice provider का media stream अपने-आप किसी LLM provider के realtime interface जैसा नहीं होता। आपके adapter को codecs बदलने, audio frames बनाने, session identifiers प्रबंधित करने और model output के अंशों को चलाए जा सकने वाले audio में बदलने की आवश्यकता हो सकती है।

एक व्यावहारिक streaming loop यह है:

1. सामान्यीकृत voice.input event प्राप्त करें।
2. utterance या audio frames को LLM gateway पर भेजें।
3. streamed text या audio chunks पढ़ें।
4. प्रत्येक audio chunk को voice provider पर forward करें।
5. voice.interruption event आने पर generation को तुरंत रोक दें।

async function streamVoiceReply(sessionId: string, text: string) {
  const response = await fetch("https://api.callmissed.com/v1/chat/completions", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.LLM_GATEWAY_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "your-selected-model",
      stream: true,
      messages: [{ role: "user", content: text }]
    })
  });

  if (!response.body) throw new Error("Missing model stream");

  for await (const chunk of response.body as any) {
    const token = parseGatewayChunk(chunk);
    if (token) {
      // Adapter-specific: synthesize token/chunk and send media frames.
      await voiceProvider.sendAudio(sessionId, await ttsAdapter.synthesize(token));
    }
    if (await voiceProvider.wasInterrupted(sessionId)) break;
  }
}

स्वाभाविक turn-taking के लिए, हर token को synthesize करने के बजाय text-to-speech से पहले छोटे text fragments को buffer करें। Voice adapter को call/session correlation, sequence numbers, cancellation और codec conversion भी बनाए रखना चाहिए। CallMissed जैसे platforms उन स्थितियों में प्रासंगिक हो सकते हैं जहाँ किसी AI agent को WhatsApp Business voice calls या बहुभाषी voice interactions को इसी orchestration layer में जोड़ना हो।

मैं response को WhatsApp पर वापस कैसे भेजूँ?

WhatsApp आम तौर पर open bidirectional audio stream के बजाय message-based channel है। Gateway द्वारा final response तैयार करने के बाद, WhatsApp adapter को text या media message भेजना चाहिए, provider message ID रिकॉर्ड करनी चाहिए और delivery-status webhooks को अलग से process करना चाहिए।

async function sendWhatsAppText(to: string, body: string, idempotencyKey: string) {
  return fetch(`${process.env.WA_API_BASE}/messages`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.WA_TOKEN}`,
      "Content-Type": "application/json",
      "X-Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify({
      messaging_product: "whatsapp",
      to,
      type: "text",
      text: { body }
    })
  });
}

इस adapter boundary पर provider-specific consent, template, session-window, media और authentication नियम लागू करें। कभी यह न मानें कि सफल HTTP response का अर्थ है कि user ने संदेश प्राप्त कर लिया है; बाद में delivery events का मिलान करें।

गेटवे को कौन-से HTTP outcomes संभालने चाहिए?

RFC 9110 इन सामान्य outcomes को परिभाषित करता है:

दोनों paths पर webhook signature verification, replay protection, tenant authorization, rate limits, per-request budgets और circuit breakers का उपयोग करें। Correlation IDs और provider message IDs लॉग करें, लेकिन अनावश्यक phone numbers, transcripts और अन्य व्यक्तिगत डेटा को redact करें।

Production में मुझे कौन-से advanced tips और HTTP status codes उपयोग करने चाहिए? (तालिका)

Production reliability इस बात से आती है कि gateway को केवल proxy नहीं, बल्कि policy boundary माना जाए: विफलताओं को वर्गीकृत करें, केवल सुरक्षित operations पर दोबारा प्रयास करें और voice तथा WhatsApp events में correlation और idempotency बनाए रखें। RFC 9110 HTTP status semantics का लगातार उपयोग करें, ताकि channel adapters, model providers, queues और observability tools विफलताओं की व्याख्या एक ही तरह से करें।

मेरे gateway को कौन-से HTTP status codes लौटाने चाहिए?

IETF द्वारा जून 2022 में प्रकाशित RFC 9110, नीचे दिए गए HTTP status codes के मानक अर्थ परिभाषित करता है। Webhook receivers के लिए, accepted work को जल्दी acknowledge करें और जहाँ channel इसकी अनुमति देता हो, धीमे LLM या media operations को asynchronous रूप से process करें।

तालिका में स्थिति की परिभाषाएँ RFC 9110 से आती हैं; प्रदाता-विशिष्ट webhook आवश्यकताएँ अपने स्वयं के स्वीकृति नियम जोड़ सकती हैं।

वॉइस और WhatsApp के लिए पुनः प्रयास को सुरक्षित कैसे बनाऊँ?

प्रदाता इवेंट ID, टेनेंट ID और ऑपरेशन प्रकार से बनी idempotency key का उपयोग करें। LLM, टूल, आउटबाउंड WhatsApp API, या वॉइस कार्रवाई को कॉल करने से पहले इसे संग्रहीत करें। दोहराए गए webhook को पहले से रिकॉर्ड किया गया परिणाम या 409 Conflict लौटाना चाहिए, न कि दूसरा संदेश भेजना या डुप्लिकेट रिफंड निष्पादित करना चाहिए।

इन उत्पादन नियंत्रणों को लागू करें:

• अलग-अलग connect, model, tool, और total-request timeouts निर्धारित करें; किसी धीमे टूल को लाइव वॉइस टर्न को अनिश्चितकाल तक अवरुद्ध न करने दें।
• अस्थायी 429, 502, 503, और 504 प्रतिक्रियाओं पर सीमित एक्सपोनेंशियल बैकऑफ और जिटर के साथ पुनः प्रयास करें।
• गैर-idempotent आउटबाउंड संदेशों या टूल पर कभी भी बिना सोचे-समझे पुनः प्रयास न करें; टूल सीमा पर idempotency key आवश्यक करें।
• बार-बार होने वाली अपस्ट्रीम विफलताओं के बाद सर्किट ब्रेकर खोलें, फिर समान-स्तर के फ़ॉलबैक मॉडल या सुरक्षित चैनल प्रतिक्रिया पर रूट करें।
• तुरंत एक छोटा वॉइस फ़ॉलबैक लौटाएँ, जबकि प्रसंस्करण असिंक्रोनस रूप से जारी रहने पर WhatsApp को कतारबद्ध स्थिति संदेश भेजा जा सकता है।
• प्रत्येक एडेप्टर और लॉग रिकॉर्ड के माध्यम से trace_id, tenant_id, conversation_id, call_id, और provider_event_id को आगे भेजें।

उन्नत सुरक्षा और ऑब्ज़र्वेबिलिटी की कौन-सी प्रथाएँ महत्वपूर्ण हैं?

चैनल क्रेडेंशियल और LLM कुंजियों को सर्वर-साइड रखें, पेलोड को पार्स करने से पहले webhook हस्ताक्षरों का सत्यापन करें, डिफ़ॉल्ट लॉग से फ़ोन नंबर और संदेश सामग्री को छिपाएँ, और प्रत्येक टूल तर्क को स्कीमा के विरुद्ध मान्य करें। केवल कुल अनुरोध समय को मापने के बजाय चरण के अनुसार लेटेंसी रिकॉर्ड करें—नॉर्मलाइज़ेशन, रूटिंग, मॉडल, टूल, सिंथेसिस और डिलीवरी।

CallMissed जैसा गेटवे, जिसमें OpenAI-संगत मल्टी-मॉडल एंडपॉइंट है, इस नीति-और-रूटिंग पैटर्न को दर्शाता है: एकीकरण मॉडल चयन और फ़ॉलबैक लॉजिक को केंद्रीकृत कर सकता है, जबकि वॉइस और WhatsApp एडेप्टर चैनल-विशिष्ट बने रहते हैं।

वॉइस और WhatsApp एजेंट कनेक्ट करते समय मुझे किन सामान्य गलतियों से बचना चाहिए? (तालिका)

सबसे आम एकीकरण विफलताएँ वॉइस और WhatsApp को समान चैनल मानने, अप्रमाणित webhooks पर भरोसा करने, और प्रत्येक अनुरोध को सीधे एक ही मॉडल पर भेजने से उत्पन्न होती हैं। साझा संदेश अनुबंध, idempotent इवेंट हैंडलिंग, चैनल-विशिष्ट प्रतिक्रिया एडेप्टर, और गेटवे-स्तरीय टाइमआउट, पुनः प्रयास, प्रमाणीकरण तथा रूटिंग नीतियों को लागू करके इन गलतियों से बचें।

आर्किटेक्चर डिज़ाइन करते समय मुझे किन गलतियों से बचना चाहिए?

मैं चैनल-विशिष्ट विफलताओं से कैसे बच सकता हूँ?

WhatsApp एजेंट webhooks संदेश-केंद्रित होते हैं; वॉइस एजेंट सत्र और लेटेंसी के प्रति संवेदनशील होते हैं। WhatsApp उत्तर को सामान्यतः आउटबाउंड API कॉल के लिए कतारबद्ध किया जा सकता है, जबकि लाइव वॉइस टर्न में कॉल सहसंबंध बनाए रखना, व्यवधान संभालना, आवश्यकता पड़ने पर मीडिया फ़ॉर्मैट बदलना और ऑडियो को क्रमिक रूप से शुरू करना आवश्यक है।

साझा गेटवे प्रतिक्रिया के बाद अलग-अलग एडेप्टर का उपयोग करें:

• WhatsApp एडेप्टर: टेक्स्ट, मीडिया, बटन या टेम्पलेट को प्रदाता के आउटबाउंड फ़ॉर्मैट में बदलें; डिलीवरी और विफलता स्थितियों को ट्रैक करें; जहाँ लागू हो, सहमति और टेम्पलेट नियम लागू करें।
• वॉइस एडेप्टर: जनरेट किए गए टेक्स्ट को स्ट्रीमिंग स्पीच में बदलें, प्रदाता के मीडिया सत्र को बनाए रखें, और बार्ज-इन इवेंट आने पर कतारबद्ध ऑडियो रोक दें।
• गेटवे एडेप्टर: एक प्रदाता को हार्ड-कोड करने के बजाय टेनेंट नीति, भाषा, लागत बजट और फ़ॉलबैक नियमों के अनुसार LLM या स्पीच मॉडल चुनें।

एक व्यावहारिक सुरक्षा उपाय पूरे इवेंट जीवनचक्र का परीक्षण करना है: इनबाउंड इवेंट, नॉर्मलाइज़ेशन, मॉडल अनुरोध, टूल सत्यापन, चैनल प्रतिक्रिया, डिलीवरी स्थिति, टाइमआउट, पुनः प्रयास और डुप्लिकेट डिलीवरी। एक ही आंतरिक बातचीत अनुबंध का उपयोग करके WhatsApp टेक्स्ट इवेंट और वॉइस व्यवधान—दोनों का परीक्षण करें।

मुझे उत्पादन में क्या मॉनिटर करना चाहिए?

प्रमाणीकरण विफलताओं, डुप्लिकेट-इवेंट दरों, मॉडल टाइमआउट, टूल-सत्यापन विफलताओं, कतार की गहराई, डिलीवरी स्थिति और चैनल-से-सत्र सहसंबंध को मॉनिटर करें। सामान्य लॉग से फ़ोन नंबर, ट्रांसक्रिप्ट, एक्सेस टोकन और अन्य PII को छिपाएँ; डिबगिंग और अनुपालन के लिए आवश्यक न्यूनतम डेटा ही रखें।

चैनल का पैमाना इन नियंत्रणों को महत्वपूर्ण बनाता है: Meta का कहना है कि WhatsApp का उपयोग दुनिया भर में 2 बिलियन से अधिक लोग करते हैं, इसलिए webhook या retry में छोटी-सी खामी भी बड़ी मात्रा में संदेशों को प्रभावित कर सकती है। CallMissed जैसे प्लेटफ़ॉर्म WhatsApp engagement, voice agents और OpenAI-compatible multi-model gateway को एक साथ जोड़कर इस अभिसरण को संबोधित करते हैं; 22 भारतीय भाषाओं के लिए इसका समर्थन यह भी दर्शाता है कि भाषा और चैनल नीति को provider-specific code के भीतर छिपाने के बजाय स्पष्ट रखा जाना चाहिए।

मुझे सबसे पहले क्या troubleshoot करना चाहिए?

प्रश्न: अलग-अलग payloads का उपयोग करने वाले webhooks के साथ मैं LLM API gateway को voice और WhatsApp agents से कैसे जोड़ सकता हूँ?

उत्तर: दोनों channel providers और model layer के बीच एक HTTPS gateway रखें, फिर हर inbound event को एक आंतरिक schema में normalize करें, जिसमें tenantId, conversationId, channel, text, media, timestamp, और eventId शामिल हों। Parsing से पहले provider signature सत्यापित करें, conversation देखें, normalized request को LLM तक route करें, और परिणाम को या तो WhatsApp message या streamed voice output में बदलें।

प्रश्न: API keys उजागर किए बिना मैं LLM API gateway को voice और WhatsApp agents से कैसे जोड़ सकता हूँ?

उत्तर: WhatsApp, voice-provider और model credentials को केवल अपने server या gateway पर रखें; उन्हें browser code, mobile applications, prompts या client-visible logs में कभी न रखें। केवल short-lived session tokens या authorized application responses लौटाएँ, tenant और user authorization लागू करें, व्यक्तिगत जानकारी को redact करें, और जब किसी secret के उजागर होने की संभावना हो तो credentials को rotate करें।

प्रश्न: LLM request सफल होने के बावजूद मेरा voice agent धीमी प्रतिक्रिया क्यों देता है?

उत्तर: Voice agents को audio को incremental रूप से उत्पन्न करना शुरू करना पड़ता है, इसलिए webhook processing, session lookup, model time-to-first-token, text-to-speech time, media conversion और provider delivery को अलग-अलग मापें। जहाँ model और voice provider इसका समर्थन करते हों, वहाँ streaming का उपयोग करें, prompts और tool calls को सीमित रखें, स्पष्ट timeouts निर्धारित करें, और caller द्वारा barge-in event भेजने पर पिछली generation को cancel करें; एक पूर्ण text response के बाद एक बड़ी audio file भेजना आमतौर पर live calls के लिए उपयुक्त नहीं होता।

प्रश्न: मेरा WhatsApp agent duplicate replies क्यों भेज रहा है?

उत्तर: Inbound webhooks को at-least-once delivery मानें और LLM को invoke करने से पहले प्रत्येक provider event ID को idempotency table में store करें; repeated events को पहले से दर्ज परिणाम लौटाना चाहिए, न कि एक और response बनाना चाहिए। Outbound message IDs और delivery states को भी persist करें, क्योंकि provider acknowledgement आवश्यक नहीं कि final delivery के समान हो; Meta WhatsApp को दुनिया भर में 2 बिलियन से अधिक लोगों द्वारा उपयोग की जाने वाली service के रूप में पहचानता है, जिससे बड़े पैमाने पर duplicate-prevention महत्वपूर्ण हो जाता है।

प्रश्न: LLM API gateway से मिलने वाली 401, 403, 429 या 5xx error को मैं कैसे troubleshoot करूँ?

उत्तर: 401 सामान्यतः missing या invalid authentication दर्शाता है, 403 authorization या policy rejection दर्शाता है, और 429 rate limiting दर्शाता है; retry करने से पहले credential scope, tenant permissions, request budgets और retry headers की पुष्टि करें। RFC 9110 के अनुसार, 502 bad gateway response को दर्शाता है, 503 temporary unavailability को, और 504 gateway timeout को, इसलिए केवल transient failures के लिए bounded exponential backoff का उपयोग करें और उपयुक्त होने पर same-tier model fallback या circuit breaker सक्रिय करें।

प्रश्न: मेरा voice provider LLM का audio response क्यों नहीं चला पा रहा है?

उत्तर: Voice media stream और LLM realtime interface अलग-अलग codecs, sample rates, framing या transport protocols का उपयोग कर सकते हैं, इसलिए bytes को सीधे forward करने के बजाय उनके बीच एक explicit media adapter रखें। Provider के आवश्यक audio format की पुष्टि करें, server-side audio convert करें, प्रत्येक frame को call या session ID के साथ correlate करें, interruption events संभालें, और format तथा frame size जैसे metadata को log करें, लेकिन default रूप से sensitive audio record न करें; भारतीय-भाषा deployments के लिए CallMissed जैसे प्लेटफ़ॉर्म 22 भारतीय भाषाओं में speech technologies का समर्थन करते हैं, लेकिन channel-specific audio requirements के लिए अभी भी adapter testing आवश्यक है।

इस gateway को production में ले जाने में कौन-से resources और next steps मेरी मदद करेंगे?

आपके gateway को production में ले जाने में सहायक resources और next steps में provider API references, channel और voice webhook documentation, OWASP API Security Top 10 जैसी security guidance, contract tests, failure simulations और staged rollout plan शामिल हैं।

मुझे gateway architecture को कैसे संरचित करना चाहिए?

Gateway को एक simple model proxy के बजाय policy-controlled platform मानें। Channel adapters, normalized conversation events, model routing, tool execution, safety policies और delivery adapters को अलग रखें। Shared schemas को version करें ताकि voice और WhatsApp integrations downstream services को तोड़े बिना विकसित हो सकें।

मुझे inbound webhooks को कैसे सुरक्षित करना चाहिए?

Payload process करने से पहले प्रत्येक provider के webhook signature को verify करें। जहाँ समर्थित हो, timestamp या nonce checks लागू करें, replay किए गए event IDs को reject करें, payload schemas validate करें और credentials को server-side रखें। Tenant authorization लागू करें और logs, traces तथा model requests से sensitive data को redact करें।

Voice और WhatsApp agents को context कैसे share करना चाहिए?

Stable tenant, customer और session identifiers से keyed canonical conversation state store करें। Channel events को shared format में normalize करें, लेकिन call state, message IDs, media references, consent और delivery status जैसे channel-specific metadata को बनाए रखें। Transcripts और customer data के लिए स्पष्ट retention limits और access controls का उपयोग करें।

Reliable streaming voice के लिए क्या आवश्यक है?

Incremental audio input और output, cancellation, interruption detection और session correlation का समर्थन करें। Time to first audio, transcript accuracy, packet loss, codec conversion और disconnects के बाद recovery को मापें। Real-time operations के लिए tight deadlines लागू करें और non-urgent tasks को asynchronous queues में भेजें।

WhatsApp delivery को मुझे कैसे संभालना चाहिए?

Outbound message ID को track करें और बाद में आने वाले delivery-status events को state transitions के रूप में process करें। Duplicate, delayed या out-of-order webhooks की अपेक्षा रखें और handlers को idempotent बनाएँ। Template और consent requirements, media retrieval, opt-outs तथा initial send request स्वीकार होने के बाद होने वाली failures का भी परीक्षण करें।

Gateway को किन failures पर retry करना चाहिए?

Operation सुरक्षित होने पर ही transient failures को retry करें। Rate limits, timeouts और temporary upstream unavailability के लिए jitter के साथ bounded exponential backoff का उपयोग करें। Validation, authentication या authorization failures को automatically retry न करें। ऐसे message sends और tool calls में idempotency keys जोड़ें जो duplicate side effects उत्पन्न कर सकते हैं।

मुझे कौन-सी observability जोड़नी चाहिए?

Channel webhook, gateway, model request, tool call और outbound delivery के बीच trace या correlation ID propagate करें। Latency, error category, retry count, fallback use, token या media consumption और delivery outcome record करें। Structured logs, metrics और distributed traces का उपयोग करें, लेकिन raw credentials और अनावश्यक personal data से बचें।

Agent को किसी व्यक्ति को hand off कब करना चाहिए?

Explicit customer requests, repeated misunderstandings, sensitive actions, policy restrictions, low-confidence outcomes और provider failures के लिए handoff triggers निर्धारित करें। Human operator को संक्षिप्त conversation summary और relevant context दें तथा customer को स्पष्ट रूप से बताएँ कि handoff हो रहा है। Automated services unavailable होने पर model-independent emergency response बनाए रखें।

Production checklist

• [ ] सामान्यीकृत वॉइस, संदेश, मीडिया, स्थिति और सत्र इवेंट का संस्करण तैयार करें और परीक्षण करें।
• [ ] वेबहुक हस्ताक्षरों, प्राधिकरण, रीप्ले सुरक्षा और सीक्रेट स्टोरेज का सत्यापन करें।
• [ ] चैनल परिवर्तन, पुनः कनेक्शन और समवर्ती सत्रों में साझा संदर्भ का परीक्षण करें।
• [ ] स्ट्रीमिंग ऑडियो, व्यवधान प्रबंधन, टाइमआउट और नेटवर्क में गिरावट का लोड परीक्षण करें।
• [ ] WhatsApp की सहमति, टेम्पलेट, मीडिया, डिलीवरी स्थिति, डुप्लिकेट और ऑप्ट-आउट का सत्यापन करें।
• [ ] डेडलाइन, सीमित रीट्राई, इडेम्पोटेंसी, रेट लिमिट, फॉलबैक और सर्किट ब्रेकर कॉन्फ़िगर करें।
• [ ] लेटेंसी, त्रुटियों, डिलीवरी, लागत और फॉलबैक उपयोग के लिए डैशबोर्ड और अलर्ट बनाएँ।
• [ ] मानव हस्तांतरण, घटना प्रतिक्रिया, रोलबैक और प्रदाता-विफलता प्रक्रियाओं का दस्तावेज़ीकरण करें।
• [ ] विकास, स्टेजिंग, सीमित कैनरी और निगरानी वाली सामान्य उपलब्धता के माध्यम से रोलआउट करें।

निष्कर्ष

LLM API गेटवे को वॉइस और WhatsApp एजेंट से जोड़ने का अर्थ है प्रदाता वेबहुक, मीडिया सत्र और मॉडल API के बीच एक चैनल-निरपेक्ष HTTPS परत रखना। गेटवे अनुरोधों का सत्यापन करता है, इवेंट को एक आंतरिक वार्तालाप अनुबंध में परिवर्तित करता है, रूटिंग और सुरक्षा नीतियाँ लागू करता है, चयनित मॉडल को आमंत्रित करता है और WhatsApp या लाइव वॉइस के लिए प्रतिक्रिया को फ़ॉर्मैट करता है।

प्रोडक्शन पैटर्न है:

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

यह आर्किटेक्चर वैश्विक स्तर पर महत्वपूर्ण है: Meta के अनुसार, WhatsApp का उपयोग दुनिया भर में 2 अरब से अधिक लोग करते हैं, जबकि वॉइस एजेंट स्ट्रीमिंग मीडिया, रीयलटाइम मॉडल और व्यवधान प्रबंधन के बीच अधिक कड़े समन्वय की मांग करते हैं। आगे बढ़ते हुए, देखें कि रीयलटाइम मॉडल इंटरफ़ेस, बहुभाषी स्पीच सिस्टम और चैनल प्रदाता अधिक इंटरऑपरेबल एजेंट प्रोटोकॉल के इर्द-गिर्द कैसे अभिसरित होते हैं।

यह जानने के लिए कि यह संचार परत कैसे विकसित हो रही है, CallMissed पर जाएँ, जो वॉइस एजेंट, WhatsApp क्षमताएँ और 22 भारतीय भाषाओं के समर्थन के साथ OpenAI-संगत गेटवे को संयोजित करता है। गेटवे—चैनल नहीं—नीति और रूटिंग लॉजिक का स्वामित्व रखने लगे, तो आपका एप्लिकेशन कौन-सा नया एजेंट चैनल जोड़ सकता है?

संबंधित पठन

• LLM गेटवे के साथ ChatGPT को WhatsApp और वॉइस एजेंट से कनेक्ट करें
• WhatsApp Calling API आर्किटेक्चर: CallMissed के साथ प्रोडक्शन वॉइस और AI चैट एजेंट
• WhatsApp Business API गाइड: वॉइस और AI एजेंट के लिए CallMissed API