Developer cookbook

प्रति-कॉल व्हेरिएबल्स

डिप्लॉय केलेला prompt, टूल्स किंवा सेटिंग्ज न बदलता प्रत्येक कॉलसाठी जतन केलेला एजंट वैयक्तिकृत करा.

तुमच्या जतन केलेल्या एजंटच्या prompt मध्ये प्लेसहोल्डर ठेवा, त्यानंतर कॉल सुरू करताना variables ऑब्जेक्ट द्या. जतन केलेले कॉन्फिगरेशन आणि आवृत्ती इतिहास बदललेले राहतात. कॉल कॉन्फिगरेशन व्हॉइस रनटाइमला पाठवण्यापूर्वी ThunderPhone मजकूर रेंडर करते.

जेव्हा मूल्यांची आवश्यकता नसते, तेव्हा variables वगळा; null पाठवू नका (400 सह नाकारले जाते).

प्लेसहोल्डर आणि डीफॉल्ट#

You are calling {{name|Friend}} about account {{account_id}}.
The available appointment is {{ appointment_slot }}.

नावे केस-संवेदी असतात आणि [A-Za-z_][A-Za-z0-9_]* चे अनुसरण करतात. नावाभोवती व्हाइटस्पेस मान्य आहे; | नंतरची व्हाइटस्पेस डीफॉल्टचा भाग असते आणि जतन केली जाते. {{name|Friend}} मध्ये name अनुपलब्ध असल्यास किंवा null असल्यास Friend वापरले जाते; रिकामी स्ट्रिंग हे स्पष्टपणे पुरवलेले मूल्य असते. डीफॉल्टशिवाय अनुपलब्ध मूल्ये रिकाम्या स्ट्रिंग बनतात आणि त्यांची नावे unresolved_variables मध्ये दिसतात. दुहेरी कंसांमधील वैध प्लेसहोल्डर नसलेला मजकूर काढून टाकला जातो. प्रत्येक पुरवलेल्या मूल्यातील दुहेरी कंसांमधील मजकूर स्वतंत्रपणे काढून टाकला जातो; एखादे मूल्य आजूबाजूचा prompt मजकूर किंवा दुसरे मूल्य काढून टाकू शकत नाही. जुळणारे नसलेले दुहेरी-कंस विभाजकदेखील काढून टाकले जातात. prompt मधील JSON उदाहरणांमध्ये {{ वापरू नका. मूल्ये साधा मजकूर असतात; ती कधीही कोड म्हणून मूल्यांकन केली जात नाहीत किंवा टेम्पलेट्स म्हणून पुनरावृत्तीने विस्तारित केली जात नाहीत.

फोन कॉलसाठी ते फील्ड पाठवले असल्यास, व्हेरिएबल्स स्वीकारोक्ती prompt, आउटबाउंड व्हॉइसमेल संदेश आणि संमती घोषणेच्या मजकुरातही दिसू शकतात. एजंटकडे स्वतंत्र first_message फील्ड नाही: त्याच्या सुरुवातीच्या सूचना prompt मध्ये ठेवा. विद्यमान व्हॉइसमेल {agent_name} आणि {org_name} प्लेसहोल्डर कार्यरत राहतात.

मूल्ये स्ट्रिंग्ज, संख्या, बूलियन किंवा null असू शकतात; बूलियन true आणि false म्हणून रेंडर होतात. नवीन ओळ (\n), टॅब (\t), आणि कॅरेज रिटर्न (\r) वगळता Unicode नियंत्रण (Cc) वर्ण, सर्व फॉरमॅट (Cf) वर्ण आणि सरोगेट (Cs) कोड पॉइंट्स काढून टाकले जातात; \r\n ला \n मध्ये सामान्यीकृत केले जाते. रेंडर केल्यावर प्रत्येक मूल्य 2,000 वर्णांपर्यंत मर्यादित असते. पुरवलेल्या स्ट्रिंग्ज स्टोरेजपूर्वीही स्वच्छ करून छाटल्या जातात. मूळ ऑब्जेक्ट UTF-8 JSON चे 32 KB मध्ये बसला पाहिजे; त्यापेक्षा मोठ्या ऑब्जेक्ट्सना कॉल/सेशन विनंत्यांवर 400 मिळते, तर कॅम्पेन इम्पोर्टमध्ये अवैध पंक्ती स्वतंत्रपणे नोंदवल्या जातात. अॅरे आणि नेस्टेड ऑब्जेक्ट्स मूल्ये म्हणून स्वीकारले जात नाहीत. न जुळणाऱ्या मेटाडेटा कीज (उदाहरणार्थ स्पेस असलेला CSV हेडर) जतन केल्या जातात आणि परत दर्शवल्या जातात, परंतु प्लेसहोल्डरद्वारे संदर्भित करता येत नाहीत.

मूल्ये कुठून येतात#

आउटबाउंड API#

POST /v1/call वर agent_id सोबत variables पाठवा:

{
  "from_number": "+15551234567",
  "to_number": "+14155550199",
  "agent_id": 12,
  "variables": {
    "name": "Ada",
    "account_id": "A-17",
    "appointment_slot": "Tuesday at 10 AM"
  }
}

हे फोन नंबरच्या डीफॉल्ट आउटबाउंड एजंटसोबत किंवा इनलाइन config.prompt सोबतही कार्य करते. वेगवेगळ्या व्हेरिएबल्ससह idempotency key पुन्हा वापरता येत नाही.

मोहिम CSV#

फोन नसलेले CSV स्तंभ आधीच संपर्क व्हेरिएबल्स म्हणून संग्रहित केलेले असतात. प्रत्येक डायल आता त्यांचा स्वयंचलितपणे वापर करतो. तुमच्या प्लेसहोल्डर्सशी जुळण्यासाठी name, account_id, आणि appointment_slot यांसारखे हेडर्स वापरा. विद्यमान नाव मॅपिंग पहिल्या आणि आडनावाच्या स्तंभांना एकत्र करून name व्हेरिएबल तयार करू शकते.

डायनॅमिक कॉन्फिगरेशन वेबहुक#

अवरोधक कॉन्फिगरेशन वेबहुक मार्गावर, तुमच्या संस्थेतील जतन केलेला एजंट आणि कोणतीही प्रति-कॉल मूल्ये परत करा:

{"agent_id": 12, "variables": {"name": "Ada", "account_id": "A-17"}}

प्रतिसादाच्या कीज विनंती-स्तरीय व्हेरिएबल्स अधिलिखित करतात, तर इतर विनंती कीज कायम राहतात. null प्रतिसाद मूल्य प्लेसहोल्डरचे डीफॉल्ट निवडते. विलीन केलेला ऑब्जेक्ट 32 KB मध्येही बसला पाहिजे. जतन केलेल्या एजंटच्या प्रतिसादांमध्ये फक्त agent_id आणि variables स्वीकारले जातात; prompt किंवा सेटिंग्ज बदलायच्या असल्यास इनलाइन कॉन्फिगरेशन परत करा. prompt असलेला प्रतिसाद नेहमी इनलाइन कॉन्फिगरेशन वापरतो: त्या प्रतिसादातील कोणतेही agent_id दुर्लक्षित केले जाते, त्यात null किंवा पूर्णांक नसलेल्या मेटाडेटाचाही समावेश आहे. इनलाइन prompt ला तरीही सामान्य पडताळणी उत्तीर्ण करावी लागते. इनलाइन वेबहुक प्रतिसादांमध्ये variables देखील समाविष्ट असू शकतात. जतन केलेल्या एजंटचे वेबहुक प्रतिसाद फोन आणि विजेट कॉल्सवर एजंटचा तैनात केलेला A/B विभाजन वापरतात; व्हेरिएंट निवडल्यानंतर व्हेरिएबल्स रेंडर होतात. इनबाउंड फोन कॉल्ससाठी, नियुक्त इनबाउंड एजंट नसलेला नंबर वापरा आणि त्याचा फोन-नंबर किंवा संस्थेचा वेबहुक कॉन्फिगर करा; विजेट कीज mode="webhook" वापरतात. एंडपॉइंट-सिस्टम येणाऱ्या सूचना अवरोधक कॉन्फिगरेशन प्रतिसाद पुरवत नाहीत.

विजेट आणि Realtime सत्र API#

POST /v1/widget/session उच्च-स्तरीय variables ऑब्जेक्ट स्वीकारते. त्याची प्रकाशित करण्यायोग्य की जतन केलेला एजंट निवडते. वेबहुक-मोड कीज ही मूल्ये कॉन्फिगरेशन वेबहुककडे पाठवतात आणि वर वर्णन केल्याप्रमाणे प्रतिसाद विलीन करतात. ब्राउझरने पुरवलेले विजेट/रिअलटाइम variables क्लायंट-नियंत्रित असतात, वर वर्णन केलेल्या पडताळणी आणि स्ट्रिंग साफसफाईनंतर web.incoming मध्ये जसेच्या तसे पाठवले जातात, आणि पूर्णता वेबहुक्स व कॉल इतिहासात प्रतिध्वनित केले जातात. त्यांना विश्वसनीय ओळख किंवा अधिकृतता डेटा समजू नका.

POST /v1/realtime/sessions हे agent_id (किंवा इनलाइन config) सोबत variables स्वीकारते. हे सत्र-निर्मिती API फील्ड्स आहेत. Realtime WebSocket ब्रिज व्हेरिएबल्स पर्याय फॉरवर्ड करत नाही; तो थेट सत्र-निर्मिती API ला पुरवा. विजेट क्लायंटनी पोस्ट केलेल्या सत्र पेलोडमध्ये variables समाविष्ट करणे आवश्यक आहे; SDK फॉरवर्डिंग हा या API बदलाचा भाग नाही. Builder माइक आणि सिम्युलेटेड चाचणी कॉल्स डीफॉल्ट्स आणि अनुपस्थित प्लेसहोल्डर्स सोडवतात, परंतु त्यांच्यासाठी प्रति-कॉल व्हेरिएबल्स इनपुट नसते.

कॉलबनंतर परत मिळणारी मूल्ये#

GET /v1/calls, GET /v1/calls/{call_id}, telephony.complete, आणि web.complete मध्ये अंतिम विलीन केलेले variables आणि unresolved_variables समाविष्ट असतात. data.history समाविष्ट करणाऱ्या लेगसी पूर्णता पेलोड्समध्येही ते समाविष्ट असतात:

{
  "variables": {"name": "Ada", "account_id": "A-17"},
  "unresolved_variables": ["appointment_slot"]
}

पूर्ण झालेला कॉल त्याच्या स्रोत रेकॉर्डशी जोडण्यासाठी तुमचा CRM किंवा कार्य ओळखकर्ता व्हेरिएबल्स ऑब्जेक्टमध्ये संग्रहित करा. ही फील्ड्स कॉल रेकॉर्डसह जतन केली जातात; कॉल इतिहास आणि वेबहुक्समध्ये जतन करणे योग्य असेल अशीच माहिती पाठवा.

विद्यमान prompt सुसंगतता#

रेंडरिंग विद्यमान सेव्ह केलेल्या एजंट आणि A/B व्हेरिएंट prompt, इनलाइन आउटबाउंड आणि रिअलटाइम कॉन्फिगरेशन, तसेच कॉन्फिगरेशन वेबहुकद्वारे परत केलेल्या prompt वरही लागू होते. अज्ञात {{name}} प्लेसहोल्डर रिक्त मजकूर बनतात, जरी कोणतेही variables दिलेले नसले तरीही. रोलआउटपूर्वी विद्यमान prompt तपासा, ज्यामध्ये ThunderPhone सूचीबद्ध करू शकत नसलेल्या बाहेरून पुरवलेल्या इनलाइन/वेबहुक prompt चा समावेश आहे. बिल्डर मायक्रोफोन आणि सिम्युलेशन कॉलवरही तेच डीफॉल्ट/रिक्त वर्तन लागू होते.