मुख्य कंटेंट पर जाएँ
Sursa Developers

POST/v1/chat

असिस्टेंट के जवाब की स्ट्रीम (SSE)

chat

लोड बैलेंसर के पीछे API की कई कॉपियाँ हों (api.<domain> पता, 1.62.0), तो जवाब और उसके इवेंट का बफ़र उस कॉपी की मेमोरी में रहते हैं, जो उसे बनाती है। Last-Event-ID के साथ स्ट्रीम फिर से शुरू करना सिर्फ़ उसी कॉपी पर काम करता है।

उसी request_id और बातचीत वाली दोहराई गई रिक्वेस्ट, जो जवाब पूरा होने के बाद दूसरी कॉपी तक पहुँचती है, सवाल दोबारा पूछे बिना सेव किया गया जवाब पाती है (token और done, इवेंट 1 से क्रमांकित)। जो दोहराई गई रिक्वेस्ट जवाब बनते समय दूसरी कॉपी तक पहुँचती है, वह उस बनने को रोकती है और जवाब नए सिरे से बनाती है; दूसरा सवाल भी नहीं बनता। नए सिरे से बनाए बिना स्ट्रीम फिर से शुरू करने के लिए उसी कॉपी से कनेक्शन बनाए रखें या done इवेंट के बाद रिक्वेस्ट दोहराएँ।

ऑथेंटिकेशन

Authorization हेडर में API कुंजी भेजें: Authorization: Bearer <कुंजी>।

हेडर पैरामीटर

  • X-View-Asstring

    सिर्फ़ admin रोल वाली API कुंजियों के लिए। रिक्वेस्ट को डेटा प्रोफ़ाइल <profile>[:viewer|verifier|editor] की ओर से चलाता है, जैसे employee:viewer। इंस्टॉलेशन कुंजी इस हेडर का इस्तेमाल नहीं कर सकती (403)।

कुकी पैरामीटर

  • kb_view_asstring

    सेशन के लिए “View as” मोड की कुकी। POST /auth/view-as इसे सेट करता है और DELETE /auth/view-as हटाता है।

रिक्वेस्ट बॉडी

application/json

ऑब्जेक्ट: ChatRequest

  • messagesarray of ChatMessageज़रूरी

    items ≥ 1

  • collectionstring

    डिफ़ॉल्ट: "default"

  • tagsarray of string | null
  • exportstring | null
  • card_idsarray of string | null

    items ≤ 50

  • streamboolean

    डिफ़ॉल्ट: false

  • conversation_idstring | null

    length ≤ 64

  • originstring | null
  • toolsboolean | null
  • bypass_cacheboolean

    जवाब, जवाबों के कैश से न लें (कैश किए गए जवाब के नीचे “Get a fresh answer” बटन)। नया जवाब कैश की एंट्री की जगह ले लेता है।

    डिफ़ॉल्ट: false

  • languagestring | null

    जवाब की भाषा: उस भाषा में जवाब पाने के लिए ISO 639-1 कोड (de, en, ru, …)। auto के साथ या फ़ील्ड के बिना भाषा सवाल से पहचानी जाती है। इंटरफ़ेस दूसरी भाषा वाले सुझाव की भाषा साफ़ तौर पर भेजता है (Starter.language)।

  • scopeChatScope | null

    सवाल का दायरा: कई कलेक्शन, एक स्रोत, टैग और एक अवधि। दायरे के कलेक्शन collection की जगह लेते हैं। स्रोत जवाब को अपने कलेक्शन (और अपने कार्ड) तक सीमित करता है। टैग tags में जोड़े जाते हैं। अवधि वित्तीय जवाबों को उसी अवधि तक सीमित करती है। आप सिर्फ़ वही चुन सकते हैं, जो यूज़र को दिखता है (कलेक्शन: collections.no_access/collections.not_found; स्रोत: sources.not_found)। conversation_id के साथ दायरा बातचीत में सेव होता है। फ़ील्ड के बिना बातचीत का दायरा लागू होता है; null या ख़ाली दायरा उसे साफ़ कर देता है।

  • request_idstring

    सवाल की आइडेम्पोटेंसी कुंजी। एक सवाल के लिए स्ट्रीम की हर रीट्राई में वही कुंजी भेजें (कनेक्शन टूटने के बाद रीट्राई; यहाँ Last-Event-ID स्ट्रीम को आगे नहीं बढ़ाता और सिर्फ़ लॉग होता है)। पहले से सेव हुए जवाब की कुंजी वाली रीट्राई दूसरा सवाल नहीं बनाती: सेव किया गया नतीजा एक done इवेंट के रूप में दोबारा भेजा जाता है (और टेक्स्ट के साथ एक token), भले ही सवालों या क्रेडिट की सीमा ख़त्म हो चुकी हो। अगर डिस्कनेक्ट हुए क्लाइंट के लिए पिछला जवाब अभी तैयार हो रहा है, तो उसकी तैयारी रुक जाती है और जवाब नए सिरे से तैयार होता है।

    length ≤ 64

  • version_ofinteger (int64)

    बातचीत में इस सवाल वाले संदेश का नया वर्शन बनाता है (फ़ीड से question_id): बदला हुआ सवाल (messages में नया टेक्स्ट), दोबारा तैयार किया गया जवाब (वही टेक्स्ट, आम तौर पर bypass_cache के साथ) या किसी दूसरे quality के साथ वही सवाल (उदाहरण के लिए, fast जवाब के बाद precise)। पिछला सवाल-जवाब का जोड़ा बना रहता है। उसके बाद के संदेश उसकी शाखा में रहते हैं और जब तक नया वर्शन चुना हुआ है, फ़ीड में छिपे रहते हैं (FeedItem.versions, POST /v1/conversations/{conv_id}/versions)। जवाब के लिए इस्तेमाल होने वाला इतिहास इस संदेश तक की चुनी हुई शाखा है। वर्शन का quality बातचीत की सेटिंग्स नहीं बदलता। conversation_id ज़रूरी है; किसी दूसरी बातचीत का सवाल 404 questions.not_found लौटाता है।

  • qualitystring

    नतीजे के पीछे की खोज में रफ़्तार और सटीकता का संतुलन: fast ज़्यादा तेज़ है, precise ज़्यादा सटीक। डिफ़ॉल्ट: precise।

    मान्य मान: fastprecise

रिस्पॉन्स

200`stream=true` के साथ: `text/event-stream`। हर इवेंट में `id: <number>` (स्ट्रीम में इवेंट का क्रम नंबर, 1 से शुरू) और `data: <JSON>` पंक्तियाँ होती हैं, और उसके बाद एक ख़ाली पंक्ति। `event:` और `retry:` फ़ील्ड इस्तेमाल नहीं होते; इवेंट टाइप `type` फ़ील्ड में होता है (`ChatEvent`)।

stream=true के साथ: text/event-stream। हर इवेंट में id: <number> (स्ट्रीम में इवेंट का क्रम नंबर, 1 से शुरू) और data: <JSON> पंक्तियाँ होती हैं, और उसके बाद एक ख़ाली पंक्ति। event: और retry: फ़ील्ड इस्तेमाल नहीं होते; इवेंट टाइप type फ़ील्ड में होता है (ChatEvent)।

request_id वाले सवाल का जवाब कनेक्शन से अलग दिया जाता है। कनेक्शन टूटने से जवाब नहीं रुकता: वह पूरा होता है और बातचीत में सेव होता है (10 मिनट तक)। वही रिक्वेस्ट दोहराने (वही request_id और बातचीत) पर वह चल रहे जवाब से जुड़ जाती है, और Last-Event-ID हेडर के साथ उस नंबर के बाद के इवेंट पाती है, इसलिए स्ट्रीम उन्हीं इवेंट नंबरों के साथ जारी रहती है। अगर स्ट्रीम उस नंबर से जारी नहीं रह सकती, तो दोहराई गई रिक्वेस्ट को शुरू से स्ट्रीम मिलती है: तब पहले इवेंट का नंबर Last-Event-ID से बड़ा नहीं होता, और क्लाइंट जवाब शुरू से दिखाता है। अगर जवाब पहले ही पूरा हो चुका है और उसके इवेंट का बफ़र छोड़ दिया गया है (3 मिनट बाद), तो सेव किया गया नतीजा सवाल दोबारा पूछे बिना फिर से भेजा जाता है (token और done, 1 से क्रमांकित); वरना जवाब नए सिरे से बनता है। ऐसे जवाब को रोकने के लिए POST /v1/chat/cancel कॉल करें। request_id के बिना क्लाइंट का कनेक्शन टूटने पर जवाब रद्द हो जाता है।

पहले इवेंट के बाद, जब तक जवाब बन रहा है, सर्वर हर 15 सेकंड में : ping कमेंट भेजता है; इसे छोड़ दें। इवेंट का क्रम: stage इवेंट (प्रगति), meta, sources, data, फिर token इवेंट में जवाब का टेक्स्ट, फिर done। जवाब के टेक्स्ट से पहले sources और data दोहराए जा सकते हैं और tool इवेंट आ सकते हैं; टेक्स्ट एक token में या हिस्सों में आ सकता है। कैश से जवाब: meta (cached के साथ), sources, data, token, done। स्ट्रीम शुरू होने के बाद की एरर error इवेंट के रूप में आती है, और स्ट्रीम done के बिना बंद हो जाती है; स्ट्रीम का HTTP स्टेटस हमेशा 200 होता है। done के बाद अगले सुझाए गए सवालों के साथ followups इवेंट आ सकता है। जिन इवेंट टाइप को आप हैंडल नहीं करते, उन्हें अनदेखा करें।

stream=false के साथ: AnswerResponse बॉडी वाला application/json (साथ में conversation_id)।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

text/event-stream

ऑब्जेक्ट: ChatEvent

इनमें से एक

application/json

ऑब्जेक्ट: AnswerResponse

  • answerstringज़रूरी
  • question_idintegerज़रूरी
  • querystring
  • collectionstringज़रूरी
  • sourcesarray of Sourceज़रूरी
  • table_queriesarray of TableQueryज़रूरी
  • datasetsarray of Datasetज़रूरी
  • chartsarray of ChartSpecज़रूरी
  • warningsarray of AnswerWarningज़रूरी
  • timingsTimingsज़रूरी
  • provenancearray of NumberProvenance
  • emptystring

    मान्य मान: no_hitsrestrictedguardrailno_data_for_period

  • basisAnswerBasis
  • verificationAnswerVerification
  • alt_periodsarray of AnswerAltPeriod

    items ≤ 6

  • drilldownarray of AnswerDrilldown

    items ≤ 20

  • restrictedRestrictedInfo
  • guardrailGuardrailVerdict
  • verified_onlyboolean
  • cachedboolean
  • cache_hitAnswerCacheHit
  • out_of_scopeAnswerOutOfScope
  • attachmentsarray of Attachment
  • export_errorstring
  • toolsstring | null

    इस जवाब के लिए टूल क्यों इस्तेमाल हुए: request (साफ़ तौर पर माँगा गया); compare, compute, action (सवाल के आधार पर); needs_calc (टेबल पर गणना ज़रूरी है); summary (कलेक्शन या दस्तावेज़ों का सार); mcp (संगठन ने बाहरी MCP सर्वर कनेक्ट किए हैं)।

    मान्य मान: requestcomparecomputeactionneeds_calcsummarymcpnull

  • tool_callsarray of ToolCallInfo
  • calculationsarray of Calculation
  • pending_actionsarray of PendingAction
  • entitiesarray of AnswerEntityज़रूरी
  • followupsarray of Followupज़रूरी
  • conversation_idstring

    सिर्फ़ बातचीत वाले POST /v1/chat के लिए।

  • answer_idstring

    जवाब के ऑब्जेक्ट का ID।

400रिक्वेस्ट अमान्य है: पैरामीटर का मान या ऑब्जेक्ट की स्थिति यह कार्रवाई करने नहीं देती (`detail` एक संदेश है)।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

401कोई क्रेडेंशियल नहीं भेजा गया (न सेशन कुकी, न API कुंजी), या कुंजी नहीं मिली।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

403कार्रवाई की अनुमति नहीं है: रोल काफ़ी नहीं है, कलेक्शन या कार्ड तक ऐक्सेस नहीं है, रिक्वेस्ट “View as” मोड में चल रही है, या संगठन निलंबित है या हटा दिया गया है (`detail` एक ऑब्जेक्ट है, जिसमें `code: org_suspended | org_deleted` है)।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

404ऑब्जेक्ट मौजूद नहीं है या आपके लिए उपलब्ध नहीं है। API यह पुष्टि नहीं करता कि प्रतिबंधित ऑब्जेक्ट मौजूद है।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

422वैलिडेशन एरर: बॉडी या पैरामीटर स्कीमा से मेल नहीं खाते (`detail` वैलिडेशन एरर की सूची है), या पैरामीटर का मान सीमा से बाहर है (`detail` एक संदेश है)।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

429बहुत ज़्यादा रिक्वेस्ट (`api.rate_limited`), संगठन का मिनट, दिन या महीने का कोटा ख़त्म हो गया है (`api.quota_exceeded`; `error.details` में `quota`, `limit` और `reset_at` होते हैं), संगठन की सीमा पूरी हो गई है, या जवाब देने वाली सर्विस व्यस्त है (`answers.engine_busy`)। `Retry-After` हेडर में दिए गए समय तक इंतज़ार करें।

रिस्पॉन्स हेडर

  • Retry-After

    रिक्वेस्ट का रीट्राई करने से पहले कितने सेकंड इंतज़ार करना है।

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

एरर कोड

हर रिक्वेस्ट के सामान्य कोड के अलावा वे कोड, जो यह एंडपॉइंट एरर होने पर error.code में लौटा सकता है।

सुरक्षित रीट्राई

हर POST और PATCH के साथ Idempotency-Key हेडर भेजें (उदाहरण के लिए, UUID)। 24 घंटे के अंदर उसी कुंजी के साथ रीट्राई करने पर रिक्वेस्ट दोबारा नहीं चलती, बल्कि सेव किया गया रिस्पॉन्स लौटता है।

रेट लिमिट

रिस्पॉन्स में RateLimit और RateLimit-Policy हेडर होते हैं, और पहले वाले X-RateLimit-Limit, X-RateLimit-Remaining और X-RateLimit-Reset भी। 429 रिस्पॉन्स में Retry-After सेकंड में होता है: उतना इंतज़ार करें और रीट्राई करें।

← answers · API रेफ़रेंस