API

हर Nessie क्लाइंट के पीछे का HTTP API, और उससे प्रमाणीकरण कैसे करें।

API क्या है

Nessie के पास एक ही HTTP API है। एडमिन वेब ऐप, macOS और iOS क्लाइंट, और रिमोट एक्ज़ीक्यूटर डेमन, ये सभी इसके सामान्य क्लाइंट हैं, और ये जो कुछ भी कर सकते हैं, वह किसी और तरीके से उपलब्ध नहीं है। यह Fastify सर्वर पर चलने वाला JSON API है, GraphQL नहीं है, और इसका कोई अलग “सार्वजनिक” हिस्सा नहीं है: आपकी अपनी स्क्रिप्ट जिस सतह को कॉल करती है, वही सतह प्रोडक्ट भी कॉल करता है।

पथ में कोई वर्शन सेगमेंट नहीं है। हर रूट /api के अंतर्गत है, सिवाय इनबाउंड MCP एंडपॉइंट POST /mcp के और /.well-known/ के अंतर्गत आने वाले कुछ डिस्कवरी दस्तावेज़ों के। संगतता इस तरह बनी रहती है कि केवल नए फ़ील्ड जोड़े जाते हैं, इसलिए जो क्लाइंट अपरिचित चीज़ों को अनदेखा करता है, वह काम करता रहता है।

बेस URL

Nessie सेल्फ़-होस्टेड है, इसलिए बेस URL वही होता है जिस ओरिजिन पर आपकी डिप्लॉयमेंट API उपलब्ध कराती है। ऑपरेटर इसे NESSIE_API_PUBLIC_URL के रूप में सेट करता है, और जब API को अपना पूरा URL बनाना होता है, तो वही मान इस्तेमाल होता है। जिस इंस्टेंस को हम चलाते हैं, उसका पता https://api.nessie.works है; pnpm dev से शुरू किया गया डेवलपमेंट इंस्टेंस http://localhost:5454 पर जवाब देता है।

एडमिन वेब ऐप API से अलग ओरिजिन पर होता है, इसलिए ब्राउज़र क्लाइंट CORS अनुमति-सूची (NESSIE_CORS_ORIGINS) के अधीन होते हैं। स्क्रिप्ट या सर्वर से आने वाले अनुरोधों का कोई ओरिजिन नहीं होता जिसकी जाँच हो, इसलिए वे प्रभावित नहीं होते।

प्रमाणीकरण

जान-बूझकर सार्वजनिक रखे गए कुछ रूट को छोड़कर हर अनुरोध मानक हेडर में एक एक्सेस टोकन लेकर आता है:

Authorization: Bearer <token>

यह टोकन API द्वारा जारी किया गया एक साइन किया हुआ JWT है। इसकी अवधि छोटी होती है — डिफ़ॉल्ट रूप से तीस मिनट (NESSIE_AUTH_TOKEN_TTL) — और यही वह अकेली क्रेडेंशियल है जो कोई सामान्य कॉलर कभी पेश करता है। Nessie में लंबी अवधि वाली निजी API कुंजियाँ नहीं होतीं। यदि आप चाहते हैं कि कोई स्क्रिप्ट API को कॉल करे, तो वह उसी तरह साइन-इन करती है जैसे किसी व्यक्ति का ब्राउज़र करता है, और चलते-चलते अपना टोकन नवीनीकृत करती है।

टोकन कैसे प्राप्त करें

POST /api/auth/session एक सेशन बनाता है। यह एक्सेस टोकन और कॉलर की पहचान के साथ जवाब देता है, और नवीनीकरण टोकन को एक अलग HTTP-only कुकी में सेट करता है।

आप अपनी पहचान कैसे साबित करते हैं, यह इस पर निर्भर है कि इंस्टेंस कैसे डिप्लॉय हुआ है। local मोड में चल रहा इंस्टेंस ईमेल और पासवर्ड स्वीकार करता है। hosted या selfHosted इंस्टेंस पर पासवर्ड से साइन-इन पूरी तरह अस्वीकार कर दिया जाता है, 403 PASSWORD_AUTH_DISABLED के साथ, और प्रवेश का एकमात्र तरीका कॉन्फ़िगर किया गया पहचान प्रोवाइडर है — ताकि खाते के बगल में कभी दूसरा, कमज़ोर पहचान मार्ग न जुड़ सके।

पहचान प्रोवाइडर के ज़रिए साइन-इन

सिंगल साइन-ऑन PKCE के साथ OAuth ऑथराइज़ेशन-कोड विनिमय है, जो तीन चरणों में होता है। Nessie का अपना पहचान प्रोवाइडर UnlikeOtherAI है, जो उस संगठन और टीम की संरचना का भी मालिक है जिसे कोई इंस्टेंस दर्शाता है; नीचे दिया गया विनिमय किसी भी कॉन्फ़िगर किए गए प्रोवाइडर के लिए इसी ढाँचे का होता है।

GET /api/auth/providers उन प्रोवाइडरों की सूची देता है जिन्हें यह इंस्टेंस स्वीकार करता है, हर एक के साथ providerId, एक लेबल, और यह कि साइन-इन पेज अपने-आप उसी पर रीडायरेक्ट करे या नहीं।
GET /api/auth/providers/:providerId/authorize, क्वेरी पैरामीटर codeChallenge, redirectUri और state के साथ, { data: { authorizeUrl } } से जवाब देता है। व्यक्ति को वहीं भेजिए।
प्रोवाइडर उन्हें कोड के साथ आपके redirectUri पर लौटाता है। उस कोड को { providerId, code, codeVerifier, redirectUri } के साथ POST /api/auth/session पर वापस भेजिए — चारों मान एक साथ ज़रूरी हैं, और अधूरा सेट 400 EXTERNAL_AUTH_INCOMPLETE देता है।

सेशन नवीनीकृत करना

नवीनीकरण टोकन कभी रिस्पॉन्स बॉडी में नहीं होता। इसे nessie_refresh नाम की HTTP-only कुकी में सेट किया जाता है, जो /api/auth पथ तक सीमित है, और डिफ़ॉल्ट रूप से तीस दिन की अवधि रखती है (NESSIE_AUTH_REFRESH_TOKEN_TTL)। उस कुकी के साथ POST /api/auth/refresh कॉल करने पर वह उपयोग हो जाती है, एक नया एक्सेस टोकन जारी होता है और उसकी जगह नई कुकी सेट होती है। टोकन घूमते रहते हैं, इसलिए चुराया गया टोकन केवल तब तक काम करता है जब तक असली क्लाइंट अगली बार नवीनीकरण नहीं करता।

कई खातों में साइन-इन किया हुआ ब्राउज़र हर साइन-इन के लिए ऐसी एक कुकी रखता है, जिसका नाम nessie_refresh_<slot> है, और x-nessie-account-slot हेडर से बताता है कि अनुरोध किस कुकी से जुड़ा है। जो क्लाइंट ऐसा हेडर नहीं भेजता, उसका अनुरोध nessie_refresh से जुड़ा माना जाता है, और कमांड-लाइन क्लाइंट को बस इतना ही चाहिए।

इसलिए कमांड-लाइन क्लाइंट को एक कुकी जार चाहिए। curl के साथ यह साइन-इन कॉल पर --cookie-jar और नवीनीकरण पर --cookie है, जैसा नीचे दिए गए उदाहरण में है।

हर अनुरोध पर क्या जाँचा जाता है

प्रमाणीकरण केवल सिग्नेचर जाँच नहीं है। हैंडलर चलने से पहले API टोकन का सिग्नेचर और समाप्ति-तिथि जाँचता है, पुष्टि करता है कि सेशन रद्द नहीं हुआ है (उपयोगकर्ता-स्तर के टोकन वर्शन और अलग-अलग सेशन ID, दोनों से), और उस संगठन में कॉलर की सदस्यता लोड करता है जिसका नाम टोकन में है। निष्क्रिय की गई सदस्यता पर 403 मिलता है। जब संगठन किसी बाहरी पहचान प्रोवाइडर पर आधारित होता है, तो कॉलर की मौजूदा स्थिति हर अनुरोध पर उस प्रोवाइडर से दोबारा जाँची जाती है, न कि टोकन से पढ़ी जाती है — इसलिए ऊपर से हटाई गई पहुँच अगली समाप्ति-तिथि का इंतज़ार किए बिना तुरंत बंद हो जाती है।

वे क्रेडेंशियल जो सेशन टोकन नहीं हैं

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

रिस्पॉन्स का ढाँचा

हर सफल रिस्पॉन्स एक ऑब्जेक्ट है जिसमें data कुंजी होती है। जड़ में कोई खुला ऐरे या ऊपरी-स्तर का पेलोड नहीं होता, इसलिए क्लाइंट को कभी आकार के आधार पर भेद नहीं करना पड़ता:

{
  "data": { "id": "3f1c…", "label": "engineering" }
}

सूची वाले एंडपॉइंट उसके साथ एक meta ऑब्जेक्ट जोड़ते हैं। ऊपरी स्तर पर और कुछ नहीं जोड़ा जाता।

विफलताएँ भी एक ही ढाँचे में आती हैं, चाहे उनका कारण कुछ भी हो:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "A message needs content or at least one attachment",
    "field": "body",
    "details": { "formErrors": [], "fieldErrors": {} }
  }
}

code वह भाग है जो मशीन पढ़ती है, और उसी के आधार पर आपका कोड फ़ैसला करे; message व्यक्ति के लिए है। field और details तब मौजूद होते हैं जब विफलता इतनी विशिष्ट हो कि उसे खोजा जा सके। जिस सर्वर त्रुटि को संभाला नहीं गया, वह हमेशा तय संदेश के साथ 500 INTERNAL_ERROR होती है — मूल त्रुटि-पाठ लॉग होता है, कभी लौटाया नहीं जाता, क्योंकि उसमें बाहर जाते समय अनुरोध का डेटा आ सकता है।

सबसे पहले मिलने वाले त्रुटि कोड

स्थिति	कोड	अर्थ
400	`VALIDATION_ERROR`	बॉडी या क्वेरी स्कीमा से मेल नहीं खाती।
401	`AUTH_REQUIRED`	बेयरर टोकन नहीं है, या हेडर गलत बना है।
401	`TOKEN_EXPIRED`	एक्सेस टोकन की समय-सीमा निकल चुकी है। नवीनीकरण करके फिर कोशिश कीजिए।
401	`TOKEN_REVOKED`	सेशन से साइन-आउट किया गया है, या हर सेशन ज़बरदस्ती बंद कर दिया गया है।
403	`ACCOUNT_DEACTIVATED`	इस संगठन की सदस्यता निष्क्रिय की जा चुकी है।
404	`NOT_FOUND`	ऐसा कोई रूट नहीं है, या इस कॉलर को दिखने वाला ऐसा कोई रिकॉर्ड नहीं है।
429	`RATE_LIMITED`	बकेट भर चुकी है। `Retry-After` पढ़िए।
500	`INTERNAL_ERROR`	एक ऐसी सर्वर त्रुटि जो संभाली नहीं गई; जानबूझकर अस्पष्ट रखी गई है।

पेजिनेशन

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

तीन क्वेरी पैरामीटर स्वीकार होते हैं: cursor, limit और direction (forward या backward)। डिफ़ॉल्ट पेज 25 का है और अधिकतम सीमा 100 है; इससे बड़ा मान अस्वीकार नहीं होता, बल्कि सीमा तक घटा दिया जाता है। जो एंडपॉइंट सॉर्ट या फ़िल्टर भी करते हैं, वे sort, order और मुक्त-पाठ वाला q जोड़ते हैं।

पेज का meta बताता है कि आप कहाँ हैं:

{
  "data": [ … ],
  "meta": {
    "hasMore": true,
    "nextCursor": "2026-09-12T08:31:44.005Z|8b2f…",
    "prevCursor": null,
    "total": 134
  }
}

nextCursor और prevCursor दोनों असली हैं: पिछला और अगला, दोनों ऐसे नियंत्रण हैं जिनकी व्यक्ति उम्मीद करता है। वे अपारदर्शी हैं — सर्वर अपनी सॉर्ट कुंजी उनमें एन्कोड करता है, और जो क्लाइंट कोई कर्सर पार्स या बनाता है, वह उसी पल टूट जाएगा जब सूची अपना क्रम बदलेगी। total अधिकांश सूचियों में मौजूद होता है, और जहाँ गिनती का कोई अर्थ नहीं होता, जैसे रैंक किए गए खोज परिणाम, वहाँ छोड़ दिया जाता है।

दर सीमाएँ

सीमाएँ एक निश्चित विंडो के अनुसार लागू होती हैं और अनुरोध की बॉडी पढ़ने से पहले ही लागू कर दी जाती हैं। अस्वीकृत अनुरोध 429 होता है, कोड RATE_LIMITED के साथ, और सेकंड में एक Retry-After हेडर।

अधिकांश बकेट क्लाइंट IP पर आधारित होते हैं; क्रेडेंशियल-संवेदनशील बकेट — साइन-इन, नवीनीकरण, पासवर्ड की दोबारा पुष्टि, MCP क्रेडेंशियल लिखना — हर खाते के लिए एक अलग काउंटर भी रखते हैं, और इनमें से कोई भी सीमा पार होते ही अस्वीकार करते हैं; इससे एक पता जो कई खातों पर हमला करता है, और कई पतों से एक खाते पर हमला, दोनों एक दीवार से टकराते हैं। साइन-इन का डिफ़ॉल्ट प्रति IP 10 प्रयास और प्रति ईमेल पता दस मिनट में 5 है; संदेश भेजने का डिफ़ॉल्ट प्रति मिनट 60 है; /api/agents के तहत लिखने की सीमा प्रति मिनट 60 है। हर सीमा हर डिप्लॉयमेंट पर कॉन्फ़िगर की जा सकती है, इसलिए इन्हें अनुबंध नहीं, बल्कि भेजे गए डिफ़ॉल्ट मानिए। हेल्थ-चेक और रीयल-टाइम स्ट्रीम इससे मुक्त हैं।

रीयल-टाइम

किसी सूची को बार-बार पूछते रहना बातचीत को फ़ॉलो करने का गलत तरीका है। इसके बजाय तीन स्ट्रीमिंग एंडपॉइंट हैं:

GET /api/events/stream — साइन-इन व्यक्ति को दिखने वाली हर चीज़ के लिए सर्वर-सेंट इवेंट्स।
GET /api/threads/:threadId/stream — एक थ्रेड के लिए सर्वर-सेंट इवेंट्स। यह Last-Event-ID का पालन करता है, इसलिए दोबारा जुड़ने पर स्ट्रीम शुरू से नहीं, बल्कि वहीं से फिर चालू होती है।
GET /api/activity — एक WebSocket जो गतिविधि फ़ीड भेजता है।

ब्राउज़र WebSocket हैंडशेक पर हेडर सेट नहीं कर सकते, इसलिए WebSocket रूट एक्सेस टोकन को ?token= क्वेरी पैरामीटर के रूप में भी स्वीकार करता है। URL में टोकन केवल यहीं रखा जाता है; बाकी हर रूट हेडर लेता है।

संसाधन समूह

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

समूह	प्रीफ़िक्स	इसमें क्या है
प्रमाणीकरण	`/api/auth`	साइन-इन, नवीनीकरण, साइन-आउट, वर्तमान पहचान, और व्यक्ति के अपने सेशन।
चैनल और थ्रेड	`/api/channels`, `/api/threads`	बातचीत का ढाँचा: चैनल थ्रेड रखते हैं, थ्रेड संदेश रखते हैं, और जवाब एक मूल संदेश के नीचे नेस्ट होते हैं।
एजेंट	`/api/agents`	एजेंट की परिभाषाएँ, उनके चैनल बाइंडिंग, बातचीत, करने वाले काम और स्थिति।
प्रोजेक्ट और बोर्ड	`/api/projects`, `/api/tasks`, `/api/iterations`	काम की ट्रैकिंग: किसी प्रोजेक्ट के तहत बोर्ड और कॉलम, उन पर कार्य, और उन पर इटरेशन।
ज्ञान-आधार	`/api/knowledge-base`	वर्शन वाले पन्नों और फ़ाइलों के स्पेस, टिप्पणियों, बैकलिंक और खोज के साथ।
मेल	`/api/mail`, `/api/mailbox-connections`	जुड़े हुए मेलबॉक्स, एजेंट मेलबॉक्स, और वे ड्राफ़्ट जो एजेंट ने किसी व्यक्ति की मंज़ूरी के लिए लिखे।
मंज़ूरियाँ	`/api/approvals`	उन कार्रवाइयों की कतार जिन्हें एजेंट अकेले नहीं ले सकता, और वह एक कॉल जो उन्हें सुलझाती है।
ऑडिट	`/api/audit-log`	संगठन का हैश-चेन वाला ऑडिट ट्रेल, सत्यापन एंडपॉइंट के साथ। ओनर और एडमिन के लिए।
लागत और उपयोग	`/api/ledger`, `/api/billing`	टोकन और लागत का हिसाब, बजट और रन का समय; अलग से, क्रेडिट और टॉप-अप। ओनर और एडमिन के लिए।
संगठन और टीमें	`/api/organizations`, `/api/teams`, `/api/users`	टेनेंट, टीम और सदस्यता का प्रशासन, आमंत्रणों सहित।
ट्रिगर	`/api/triggers`	शेड्यूल और वेबहुक जो एजेंट का काम शुरू करते हैं, उनके ट्रिगर होने के इतिहास के साथ।
कॉल और वॉइस	`/api/calls`, `/api/voice`	चैनल के भीतर कॉलिंग, और वॉइस असिस्टेंट का सेशन, ट्रांसक्रिप्ट और डिवाइस टोकन।
एक्ज़ीक्यूटर	`/api/executors`, `/api/execution-environment-templates`	वे मशीनें जिन पर एजेंट काम करते हैं, उनके वातावरण, और डेमन पेयरिंग चैनल।
रन	`/api/runs`	चल रहे एजेंट रन: रद्द करना, जारी रखना, फिर से शुरू करना, और किसी एक्ज़ीक्यूटर से बाँधना।
अपलोड	`/api/uploads`, `/api/attachments`	पहले फ़ाइल अपलोड कीजिए, फिर लौटे हुए ID को किसी संदेश से जोड़िए।
खोज	`/api/messages/search`	संदेश खोज, पूरे संगठन में या एक चैनल तक सीमित।
गोपनीय जानकारी और सेटिंग्स	`/api/secrets`, `/api/settings/scoped`	स्पष्ट अनुमतियों के साथ केवल-लिखने योग्य क्रेडेंशियल स्टोरेज, और स्तरित कॉन्फ़िगरेशन मान।
जुड़े टूल	`/api/mcp`	MCP सर्वर जिन्हें यह इंस्टेंस कॉल करता है। देखिए MCP और जुड़े टूल।
स्वास्थ्य	`/api/health`	लाइवनेस और रेडीनेस, दोनों सार्वजनिक। `/api/health/ready` डेटाबेस की भी जाँच करता है।

अधिकार हर रूट के लिए लागू होते हैं, समूह के लिए नहीं। मोटे तौर पर: ऑडिट लॉग, लागत लेजर, नीति नियम और इन्फ़रेंस कंट्रोल प्लेन संगठन के ओनर और एडमिन के लिए सतहें हैं, जबकि बातचीत, प्रोजेक्ट, ज्ञान और मंज़ूरियाँ हर सदस्य के लिए खुली हैं और उतने तक सीमित हैं जितना वह सदस्य वास्तव में देख सकता है।

व्यावहारिक उदाहरण

साइन-इन करें और नवीनीकरण कुकी सहेजें

local मोड वाले इंस्टेंस पर, पासवर्ड के साथ। एक्सेस टोकन बॉडी में वापस आता है; नवीनीकरण टोकन कुकी जार में पहुँचता है।

curl -sS https://api.example.com/api/auth/session \
  --cookie-jar nessie.cookies \
  -H 'Content-Type: application/json' \
  -d '{"email":"ada@example.com","password":"…"}'

{
  "data": {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…",
    "me": {
      "user": {
        "id": "1d4e…",
        "email": "ada@example.com",
        "displayName": "Ada Lovelace",
        "roleIds": ["owner"],
        "superAdmin": false
      },
      "session": {
        "sessionId": "9c07…",
        "issuedAt": "2026-09-16T09:00:00.000Z",
        "expiresAt": "2026-09-16T09:30:00.000Z"
      },
      "context": {
        "organizationId": "5a81…",
        "projectId": "7b12…",
        "teamId": "2e60…",
        "channelId": null,
        "bootstrapMode": false
      },
      "auth": {
        "providerId": "local",
        "providerType": "local-bootstrap",
        "autoRedirectToSso": false
      }
    }
  }
}

टोकन की समय-सीमा निकलने पर, कुकी के बदले नया टोकन लीजिए:

curl -sS -X POST https://api.example.com/api/auth/refresh \
  --cookie nessie.cookies --cookie-jar nessie.cookies

रिस्पॉन्स का वही { token, me } ढाँचा होता है, और कुकी जार में अब घुमाया गया नया नवीनीकरण टोकन होता है।

आपको दिखने वाले चैनल सूचीबद्ध करें

curl -sS https://api.example.com/api/channels \
  -H "Authorization: Bearer $TOKEN"

{
  "data": [
    {
      "id": "8b2f…",
      "label": "engineering",
      "type": "standard",
      "visibility": "public",
      "projectId": "…",
      "projectName": "Platform",
      "teamId": "…",
      "defaultThreadId": "c41a…",
      "unreadCount": 3,
      "lastMessageAt": "2026-09-15T18:22:07.441Z",
      "viewerCanManage": true
    }
  ]
}

एक टीम तक सीमित करने के लिए ?teamId=… जोड़िए, या आर्काइव किए गए चैनल शामिल करने के लिए ?includeArchived=true। defaultThreadId वह है जहाँ आप अगला संदेश भेजते हैं।

संदेश भेजें

संदेश में या तो कुछ content होना चाहिए, या कम से कम एक अपलोड किया गया अटैचमेंट। Idempotency-Key भेजिए, और दोबारा भेजा गया अनुरोध दूसरी प्रति पोस्ट करने के बजाय उसी संदेश तक पहुँचता है जो पहले प्रयास ने बनाया था।

curl -sS https://api.example.com/api/threads/c41a…/messages \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: 0f9c2d16-8f4a-4c1e-9a77-6b0d4f2e1a53' \
  -d '{"content":"Deploying the migration now."}'

नया संदेश 201 है:

{
  "data": {
    "message": {
      "id": "d70e…",
      "threadId": "c41a…",
      "role": "user",
      "content": "Deploying the migration now.",
      "createdAt": "2026-09-16T09:04:11.882Z"
    },
    "pendingAgentInvites": []
  }
}

उसी idempotency कुंजी का दोबारा भेजा गया अनुरोध 200 के साथ मूल संदेश और खाली pendingAgentInvites लौटाता है, क्योंकि पहला प्रयास वह अलर्ट और डिस्पैच पहले ही कर चुका है जिसका वर्णन यह ऐरे करता है।

इस रूट पर दो अस्वीकृतियों को स्पष्ट रूप से संभालना उचित है। चैट की लंबाई-सीमा से अधिक सामग्री 413 MESSAGE_TOO_LARGE देती है, और सही जवाब है कि टेक्स्ट को फ़ाइल के रूप में अपलोड करें। ऐसी सामग्री जिसकी बनावट क्रेडेंशियल जैसी हो, उस पर 422 SECRET_INTERCEPTED मिलता है — सर्वर संदेश को सहेजने, भेजने या लॉग करने से पहले ही मना कर देता है, और क्रेडेंशियल /api/secrets में होना चाहिए।