pjandro/OmniRoute
1
0
Fork 0
mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-17 20:32:25 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
bc27bbb0fda9afdf75176923ad1c3373ed8eae45
OmniRoute/docs/i18n/mr/docs/reference/API_REFERENCE.md
Diego Rodrigues de Sa e Souza b637350680 fix(docs): re-sync the 65 documentation mirror sets; section-level docs pipeline; drift gate blocking (#13940) 
1,104 mirrors rewritten over five passes of run-translation on the 22-source core set: the 14 sources edited since their translation, the 322 mirrors that were still English copies, and the frontmatter the old extractor leaked into the newer locales' bodies. The pipeline now caches per-`## `-section hashes and retranslates only changed sections, never reuses a section that is still English, rebuilds English-copy / leaked mirrors even when the source is unchanged, merges the state on save (parallel runs), and the drift gate (scoped to the core set) is blocking. Final audit: 0 stale, 0 English copies, 0 leaked frontmatter across 1,430 core mirrors.

⚠️ base-red inherited: #12732
2026-09-17 02:55:31 -03:00

176 KiB
Raw Blame History

API Reference (मराठी)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

🌐 भाषा: 🇺🇸 English | 🇪🇹 አማርኛ | 🇸🇦 العربية | 🇦🇿 Azərbaycan dili | 🇧🇬 Български | 🇧🇩 বাংলা | 🇨🇿 Čeština | 🇩🇰 Dansk | 🇩🇪 Deutsch | 🇬🇷 Ελληνικά | 🇪🇸 Español | 🇪🇪 Eesti | 🇮🇷 فارسی | 🇫🇮 Suomi | 🇫🇷 Français | 🇮🇪 Gaeilge | 🇮🇳 ગુજરાતી | 🇳🇬 Hausa | 🇮🇱 עברית | 🇮🇳 हिन्दी | 🇭🇷 Hrvatski | 🇭🇺 Magyar | 🇦🇲 Հայերեն | 🇮🇩 Bahasa Indonesia | 🇳🇬 Igbo | 🇮🇹 Italiano | 🇯🇵 日本語 | 🇬🇪 ქართული | 🇰🇭 ខ្មែរ | 🇮🇳 ಕನ್ನಡ | 🇰🇷 한국어 | 🇱🇹 Lietuvių | 🇱🇻 Latviešu | 🇮🇳 മലയാളം | 🇮🇳 मराठी | 🇲🇾 Bahasa Melayu | 🇲🇹 Malti | 🇲🇲 မြန်မာ | 🇳🇵 नेपाली | 🇳🇱 Nederlands | 🇳🇴 Norsk | 🇮🇳 ଓଡ଼ିଆ | 🇮🇳 ਪੰਜਾਬੀ | 🇵🇭 Filipino | 🇵🇱 Polski | 🇵🇹 Português (Portugal) | 🇧🇷 Português (Brasil) | 🇷🇴 Română | 🇷🇺 Русский | 🇱🇰 සිංහල | 🇸🇰 Slovenčina | 🇸🇮 Slovenščina | 🇷🇸 Српски | 🇸🇪 Svenska | 🇰🇪 Kiswahili | 🇮🇳 தமிழ் | 🇮🇳 తెలుగు | 🇹🇭 ไทย | 🇹🇷 Türkçe | 🇺🇦 Українська | 🇵🇰 اردو | 🇺🇿 Oʻzbekcha | 🇻🇳 Tiếng Việt | 🇳🇬 Yorùbá | 🇨🇳 中文 (简体) | 🇹🇼 中文 (繁體)

OmniRoute API साठी मुख्य संदर्भ. यात सार्वजनिक /v1 पृष्ठभाग आणि सर्वाधिक वापरले जाणारे व्यवस्थापन एंडपॉइंट्स समाविष्ट आहेत; मशीन-वाचनीय docs/openapi.yaml आणि src/app/api/ अंतर्गत असलेले रूट ट्री हे सर्वसमावेशक स्रोत आहेत.

अनुक्रमणिका

चॅट पूर्णता

POST /v1/chat/completions
Authorization: Bearer your-api-key
Content-Type: application/json

{
  "model": "cc/claude-opus-4-6",
  "messages": [
    {"role": "user", "content": "Write a function to..."}
  ],
  "stream": true
}

सानुकूल हेडर्स

हेडर दिशा वर्णन
X-OmniRoute-No-Cache विनंती कॅशे टाळण्यासाठी true वर सेट करा
x-omniroute-no-memory विनंती या विनंतीसाठी मेमरी + कौशल्य अंतःक्षेप वगळण्यासाठी true वर सेट करा (नो-कॅशेप्रमाणे; प्रत्येक कॉलसाठीचा टोकन/खर्च ओव्हरहेड टाळते)
X-OmniRoute-Progress विनंती प्रगती इव्हेंट्ससाठी true वर सेट करा
X-Session-Id विनंती बाह्य सत्र संलग्नतेसाठी स्टिकी सत्र की
x_session_id विनंती अंडरस्कोर प्रकारही स्वीकारला जातो (थेट HTTP)
X-OmniRoute-Session-Id विनंती कॉलरने दिलेला सत्र/संभाषण टॅग (मेमरीलाही पुरवला जातो). उपस्थित असल्यास, प्रत्येक सत्राच्या खर्चाच्या श्रेयांकनासाठी call_logs.session_tag मध्ये जसाच्या तसा कायम ठेवला जातो (#8249) — अनुपस्थित असल्यास कधीही तयार केला जात नाही
Idempotency-Key विनंती डीडुप्लिकेशन की (5 सेकंदांची विंडो)
X-Request-Id विनंती पर्यायी डीडुप्लिकेशन की
X-OmniRoute-Cache प्रतिसाद HIT किंवा MISS (नॉन-स्ट्रीमिंग)
X-OmniRoute-Idempotent प्रतिसाद डीडुप्लिकेट केले असल्यास true
X-OmniRoute-Progress प्रतिसाद प्रगती ट्रॅकिंग सुरू असल्यास enabled
X-OmniRoute-Session-Id प्रतिसाद OmniRoute द्वारे वापरलेला प्रभावी सत्र ID
X-OmniRoute-Request-Id प्रतिसाद विनंती परस्परसंबंध ID (माहित असल्यास)
X-OmniRoute-Version प्रतिसाद OmniRoute बिल्ड आवृत्ती (नेहमी उपस्थित)
X-OmniRoute-Cost-Saved प्रतिसाद HIT मुळे कॅशेने वाचवलेली USD रक्कम (फक्त कॅशे हिट्ससाठी)
X-OmniRoute-Decision प्रतिसाद राउटिंग ट्रेस: strategy=<name>; provider=<alias>; latency_ms=<n> (<name> ही कॉम्बो रणनीती असते किंवा नॉन-कॉम्बो विनंतीसाठी single) — पूर्णता प्रतिसादांमध्ये नेहमी उपस्थित

Nginx टीप: तुम्ही अंडरस्कोर हेडर्सवर अवलंबून असल्यास (उदाहरणार्थ x_session_id), underscores_in_headers on; सक्षम करा.

खर्च टेलिमेट्री हेडर्स: नॉन-स्ट्रीमिंग यशस्वी प्रतिसादांमध्ये X-OmniRoute-* खर्च-टेलिमेट्री संचही असतो — X-OmniRoute-Response-Cost (USD, निश्चित 10 दशांश स्थाने; विनामूल्य/किंमत नसलेल्यांसाठी 0.0000000000), X-OmniRoute-Tokens-In / X-OmniRoute-Tokens-Out, X-OmniRoute-Model, X-OmniRoute-Provider, X-OmniRoute-Latency-Ms, X-OmniRoute-Cache-Hit, आणि X-OmniRoute-Fallback-Attempts (फक्त > 0 असताना), तसेच X-OmniRoute-Request-Id आणि X-OmniRoute-Version. हे चॅट पूर्णता, /v1/responses, /v1/messages, आणि मीडिया एंडपॉइंट्सद्वारेही उत्सर्जित केले जातात — /v1/embeddings, /v1/images/generations, /v1/audio/speech, /v1/audio/transcriptions, /v1/rerank, /v1/videos/generations, /v1/music/generations, आणि /v1/moderations (खर्च नेहमी 0). किंमत उपलब्ध असताना मीडिया खर्च प्रत्येक मोडॅलिटीनुसार (प्रति-प्रतिमा, प्रति-सेकंद, प्रति-अक्षर, प्रति शोध-युनिट) मोजला जातो; अन्यथा तो 0 असतो (फेल-ओपन).

कॅश-हिट खर्चाचे अर्थशास्त्र: सिमॅंटिक-कॅश HIT (X-OmniRoute-Cache-Hit: true) झाल्यावर कोणताही अपस्ट्रीम कॉल केला जात नाही, त्यामुळे X-OmniRoute-Response-Cost हा 0.0000000000 असतो (हिट पुरवण्याचा वाढीव खर्च). मूळ/अन्यथा झाला असता असा खर्च X-OmniRoute-Cost-Saved मध्ये स्वतंत्रपणे नोंदवला जातो. बिलिंग वापरकर्त्यांनी X-OmniRoute-Response-Cost ची बेरीज करावी (हिट्सचा कोणताही खर्च नसतो); कॅश विश्लेषणासाठी X-OmniRoute-Cost-Saved एकत्रित करता येतो.

विशेष व्यवस्थापित सत्र लीझ

विशेष व्यवस्थापित सत्र लीझिंग हा ऐच्छिक, क्लायंट-निरपेक्ष राउटिंग करार आहे: एक सक्रिय मालक एक पात्र OmniRoute कनेक्शन धारण करतो. तो मॉडेल लीझ करत नाही, OAuth आवश्यक करत नाही, एखादा विशिष्ट क्लायंट ओळखत नाही किंवा विशिष्ट प्रदाता आवश्यक करत नाही.

प्रमाणीकरण करणाऱ्या API कीकडे lease:exclusive स्कोप आणि स्पष्टपणे नमूद केलेली रिक्त नसलेली allowedConnections सूची असणे आवश्यक आहे. की तयार करताना आणि आंशिक अद्यतने करताना डेटाबेस म्युटेशन सीमा ही दोन्ही फील्ड एकत्रितपणे लागू करते.

POST /api/v1/session-leases
Authorization: Bearer <managed-api-key>
Content-Type: application/json
X-OmniRoute-Lease-Owner: vlo_<43-base64url-characters>

{"action":"acquire","model":"glm/glm-4.6"}

यशस्वी acquire, renew आणि release प्रतिसाद टाइमस्टॅम्प, state आणि अचूक धन generation उघड करतात, परंतु निवडलेले कनेक्शन किंवा क्रेडेन्शियल्स कधीही उघड करत नाहीत. Renew आणि release JSON बॉडीमध्ये generation पुरवतात:

{ "action": "renew", "generation": 1 }

{ "action": "release", "generation": 1, "reason": "OWNER_EXIT" }

सक्रिय लीझ मालक त्याच्या सध्याच्या बाइंडिंगसाठी गोपनीयता-सुरक्षित प्रदर्शन मेटाडेटाची स्पष्टपणे विनंती करू शकतो:

{ "action": "status", "generation": 1 }

{
  "state": "ACTIVE",
  "generation": 1,
  "acquiredAt": "2026-08-28T12:00:00.000Z",
  "renewedAt": "2026-08-28T12:00:30.000Z",
  "expiresAt": "2026-08-28T12:02:30.000Z",
  "connection": {
    "displayName": "Primary Codex",
    "provider": "codex"
  }
}

ही ऐच्छिक status क्रिया अपारदर्शक मालक, प्रमाणीकृत व्यवस्थापित API की आणि अचूक सक्रिय generation यांद्वारे एका डेटाबेस व्यवहारात संरक्षित केली जाते. displayName हे केवळ ट्रिम केलेले कॉन्फिगर केलेले कनेक्शन नाव असते; कोणतेही सुरक्षित कॉन्फिगर केलेले नाव अस्तित्वात नसल्यास ते null असते. OmniRoute कधीही ईमेल किंवा व्युत्पन्न केलेली खाते ओळख त्याऐवजी वापरत नाही. provider मूल्य हे संवेदनशील नसलेले प्रदर्शन लेबल असते आणि कधीही व्युत्पन्न केलेला सुसंगत-प्रदाता अभिज्ञापक नसते. क्रेडेन्शियल्स, टोकन्स, कुकीज, कच्चे कनेक्शन किंवा API की ids, मालक हॅशेस, फेन्सिंग सीक्रेट्स आणि अंतर्गत राउटिंग डेटा वगळले जातात.

चुकीची की, चुकीचा मालक, कालबाह्य generation, गहाळ, मुदत संपलेले, रिलीज केलेले आणि अमान्य केलेले लुकअप हे सर्व कनेक्शन मेटाडेटाशिवाय समान 409 LEASE_FENCE_STALE त्रुटी परत करतात. क्षमता-प्रतीक्षा प्रतिसाद मिळालेल्या क्लायंटकडे तपासण्यासाठी कोणतेही सक्रिय बाइंडिंग नसते. जेव्हा राउटिंग सक्रिय लीझचे संक्रमण करते, तेव्हा समान generation वैध राहते आणि status जुन्या बाइंडिंगऐवजी नवीन बाइंडिंग अणुरूपपणे परत करतो. विद्यमान क्लायंट अपरिवर्तित राहतात कारण acquire, renew, release आणि waiting प्रतिसाद त्यांचे मागील स्वरूप कायम ठेवतात.

हा सर्व्हर करार स्टॉक OpenAI Codex /status बदलत नाही. स्टॉक Codex सध्या त्याचा मॉडेल प्रदाता आणि अंगभूत प्रमाणीकरण/खाते स्थिती नोंदवतो, परंतु मनमानी कस्टम प्रदाता खाते मेटाडेटा रेंडर करत नाही; भावी क्लायंट इंटिग्रेशनने ही क्रिया कॉल करून connection.displayName कसे प्रदर्शित करायचे हे ठरवले पाहिजे.

त्यानंतर प्रत्येक व्यवस्थापित इन्फरन्स विनंती दोन्ही नियंत्रण हेडर्स पुरवते:

X-OmniRoute-Lease-Owner: vlo_<43-base64url-characters>
X-OmniRoute-Lease-Generation: 1

प्रत्येक समर्थित अपस्ट्रीम प्रयत्नाच्या अगदी आधी अचूक मालक, generation, सक्रिय कनेक्शन आणि प्रमाणीकृत API की फेन्स केली जातात. दुसऱ्या कीसह मालक आणि generation पुन्हा वापरणे अयशस्वी होते, जरी ती की त्याच कनेक्शनला अनुमती देत असली तरीही. कच्चे मालक कायमस्वरूपी साठवले जात नाहीत, लॉग केले जात नाहीत, विनंती स्नॅपशॉटमध्ये राखले जात नाहीत किंवा अपस्ट्रीमकडे फॉरवर्ड केले जात नाहीत.

तात्पुरत्या स्पर्धेमुळे Retry-After सह HTTP 429 आणि पुढील प्रतिसाद मिळतो:

{
  "state": "WAITING_FOR_CAPACITY",
  "error": { "type": "lease_error", "code": "LEASE_CAPACITY_UNAVAILABLE" },
  "reason": "NO_FREE_ELIGIBLE_CONNECTION",
  "retryAfter": 30
}

या प्रतिसादाचा अर्थ केवळ इतकाच आहे की सामान्य पात्र संच रिक्त नव्हता आणि प्रत्येक मोकळा उमेदवार परकीय सक्रिय लीझने धारण केलेला होता. असमर्थित मॉडेल्स/प्रदाते, धोरण विसंगती, कूलडाउन, कोटा, आरोग्य आणि इतर सामान्य पात्रता अपयश त्यांचे विद्यमान OmniRoute प्रतिसाद कायम ठेवतात.

x-omniroute-compression

कॉम्प्रेशन योजनेचे प्रति-विनंती ओव्हरराइड. सर्वोच्च प्राधान्य — राउटिंग-कॉम्बो ओव्हरराइड, सक्रिय प्रोफाइल, auto-trigger आणि पॅनेल Default यांवर मात करते. मूल्ये:

मूल्य परिणाम
off या विनंतीसाठी कॉम्प्रेशन नाही.
default पॅनेलमधून मिळालेले Default प्रोफाइल (सक्रिय प्रोफाइलकडे दुर्लक्ष करते).
engine:<id> सक्षम असताना एकच इंजिन, उदा. engine:rtk.
<combo> नावाने ओळखला जाणारा कॉम्बो, प्रथम नावानुसार (केस-असंवेदनशील), त्यानंतर id नुसार.

टिपा:

  • अज्ञात मूल्यांकडे दुर्लक्ष केले जाते (विनंती कधीही नाकारली जात नाही); निराकरण सामान्य ऑपरेटर प्राधान्यक्रमाकडे जाते.
  • अनेक कॉम्बोंचे नाव समान असल्यास, निर्धारक जुळणीसाठी कॉम्बोचा id द्या.
  • off किंवा default नाव असलेला कॉम्बो नावाने निवडता येत नाही (त्या कीवर्ड्सचा अर्थ प्रथम लावला जातो); अशा कॉम्बोचा संदर्भ त्याच्या id द्वारे द्या.
  • मुख्य कॉम्प्रेशन स्विच हा कठोर गेट आहे: कॉम्प्रेशन जागतिक स्तरावर अक्षम असताना हा हेडर ते सक्षम करू शकत नाही.

लागू केलेली योजना प्रतिसाद हेडरमध्ये परत प्रतिध्वनित केली जाते:

X-OmniRoute-Compression: <mode>; source=<source>

येथे <source> हे request-header, routing-override, active-profile, auto-trigger, default किंवा off यांपैकी एक असते.

एम्बेडिंग्ज

POST /v1/embeddings
Authorization: Bearer your-api-key
Content-Type: application/json

{
  "model": "nebius/Qwen/Qwen3-Embedding-8B",
  "input": "The food was delicious"
}

उपलब्ध प्रदाते: Nebius, OpenAI, Mistral, Together AI, Fireworks, NVIDIA, OpenRouter, Jina AI.

कॅटलॉग आयडी provider/model स्वरूपात असतात (उदाहरण: jina-ai/jina-embeddings-v5-omni-small). रजिस्ट्रीमध्ये दिसणारे केवळ Jina मॉडेल आयडी (उदाहरणार्थ jina-embeddings-v5-text-small, jina-reranker-v3.5) देखील रिझॉल्व्ह होतात. Jina embed/rerank/classify/segment प्रथम डॅशबोर्डवरील jina-ai क्रेडेन्शियल्स वापरतात; डॅशबोर्ड की उपलब्ध नसल्यासच JINA_AI_API_KEY फॉलबॅक म्हणून वापरली जाते. jina-reader कार्ड केवळ Reader / r.jina.ai साठी आहे (POST /v1/web/fetch) आणि ते एम्बेडिंग्ज किंवा रीरँक कधीही पुरवत नाही.

मल्टिमोडल समर्थन दर्शवणारी रजिस्ट्री मॉडेल्स जास्तीत जास्त 32 प्रदाता-निरपेक्ष संरचित आयटम देखील स्वीकारतात. मीडिया आयटमचे प्रकार text, image, audio, video, आणि document आहेत. त्यांचा मीडिया source एकतर {"type":"url","url":"https://..."} किंवा {"type":"base64","data":"...","media_type":"..."} असतो.

Jina v5 Omni (jina-ai/jina-embeddings-v5-omni-small, jina-ai/jina-embeddings-v5-omni-nano, आणि फॅमिली उपनाव jina-ai/jina-embeddings-v5-omni → omni-small) Jina चे मूळ EmbeddingsV5Request दस्तऐवजही स्वीकारते आणि ते https://api.jina.ai/v1/embeddings कडे कोणताही बदल न करता फॉरवर्ड करते:

{
  "model": "jina-ai/jina-embeddings-v5-omni-small",
  "task": "retrieval.query",
  "normalized": true,
  "input": [
    { "text": "a red bicycle" },
    { "image": "https://example.com/bike.png" },
    {
      "content": [{ "text": "caption" }, { "image": "data:image/png;base64,..." }]
    }
  ]
}

मूळ { image | audio | video | pdf } मूल्ये सार्वजनिक HTTPS URL, data: URI किंवा रॉ base64 असू शकतात. OmniRoute त्या ऑब्जेक्ट्सना स्ट्रिंगमध्ये रूपांतरित करत नाही किंवा मूळ इमेज URL फेच करत नाही — Jina स्वतः सार्वजनिक मीडिया प्राप्त करते. अतिरिक्त Jina फील्ड्स (task, normalized, truncate, embedding_type) फॉरवर्ड केली जातात. केवळ मजकुरासाठी असलेली Jina SKUs अजूनही मजकूर नसलेले दस्तऐवज नाकारतात.

सुरक्षा आणि ट्रान्सपोर्ट मर्यादा:

  • रिमोट मीडिया URL सार्वजनिक HTTPS असणे आवश्यक आहे. कॅनॉनिकल {type,source:url} आयटम सर्व्हर-साइड फेच केले जातात (रीडायरेक्ट पुनर्पडताळणी, टाइमआउट, आकारमर्यादा, सार्वजनिक DNS, कनेक्शन पिनिंग) आणि प्रदाता कॉलपूर्वी इनलाइन केले जातात. Jina-मूळ {image:"https://..."} आयटम समान सार्वजनिक-HTTPS तपासणीनंतर जसेच्या तसे फॉरवर्ड केले जातात; Jina URL फेच करते.
  • इनलाइन base64 मीडिया प्रत्येक आयटमसाठी डीकोड केल्यानंतर 8 MiB आणि संपूर्ण विनंतीसाठी डीकोड केल्यानंतर 16 MiB पर्यंत मर्यादित आहे.

प्रदाता रूपांतरण (कॅनॉनिकल आयटम कधीही बदल न करता फॉरवर्ड केले जात नाहीत):

  • Jina मल्टिमोडल मॉडेल्स: प्रत्येक टॉप-लेव्हल आयटम इनलाइन मीडियासाठी डेटा URI वापरून एका मोडॅलिटी-की असलेल्या ऑब्जेक्टमध्ये (text / image / audio / video / pdf) रूपांतरित होतो; प्रत्येक टॉप-लेव्हल आयटमसाठी एक व्हेक्टर.
  • Gemini Embedding 2 फॅमिली: एक टॉप-लेव्हल अॅरे content.parts (text किंवा inline_data) असलेल्या एका मूळ models/{model}:embedContent विनंतीमध्ये रूपांतरित होतो.
  • स्पष्ट मोडॅलिटी मेटाडेटा नसलेली अज्ञात/डायनॅमिक मॉडेल्स HTTP 400 सह संरचित इनपुट नाकारतात.
{
  "model": "jina-ai/jina-embeddings-v5-omni-small",
  "input": [
    { "type": "text", "text": "A red bicycle" },
    {
      "type": "image",
      "source": { "type": "url", "url": "https://example.com/bicycle.png" }
    }
  ],
  "dimensions": 512,
  "encoding_format": "float"
}

असमर्थित मॉडेल/मोडॅलिटी संयोजन आयटमचे सक्तीने रूपांतरण करण्याऐवजी HTTP 400 परत करतात. जुन्या स्ट्रिंग/टोकन विनंत्यांमधील इनपुट नसलेली एक्स्टेन्शन फील्ड्स कोणताही बदल न करता पुढे पाठवली जातात.

# सर्व एम्बेडिंग मॉडेल्सची यादी दाखवा
GET /v1/embeddings

प्रतिमा निर्मिती

POST /v1/images/generations
Authorization: Bearer your-api-key
Content-Type: application/json

{
  "model": "openai/gpt-image-2",
  "prompt": "डोंगरांवरील सुंदर सूर्यास्त",
  "size": "1024x1024"
}

उपलब्ध प्रदाते: OpenAI (GPT Image 2), xAI (Grok Image), Together AI (FLUX), Fireworks AI, Nebius (FLUX), Hyperbolic, NanoBanana, OpenRouter, SD WebUI (स्थानिक), ComfyUI (स्थानिक).

# सर्व प्रतिमा मॉडेल्सची सूची दाखवा
GET /v1/images/generations

दस्तऐवज OCR

POST /v1/ocr
Authorization: Bearer your-api-key
Content-Type: application/json

{
  "model": "mistral/mistral-ocr-latest",
  "document": {
    "type": "document_url",
    "document_url": "https://example.com/invoice.pdf"
  }
}

model, provider/model उपसर्गाद्वारे OCR प्रदाता निवडते; केवळ मॉडेल आयडी (उदा. mistral-ocr-latest) दिल्यास तो त्याच्या नोंदणीकृत प्रदात्याशी जुळवला जातो आणि model वगळल्यास डीफॉल्ट म्हणून Mistral (mistral-ocr-latest) वापरले जाते. नोंदणीकृत प्रदाते (open-sse/config/ocrRegistry.ts):

प्रदाता आयडी मॉडेल आयडी model मूल्य टिपा
mistral mistral-ocr-latest mistral/mistral-ocr-latest (किंवा केवळ mistral-ocr-latest) समकालिक — एकाच अपस्ट्रीम कॉलमधून प्रतिसाद थेट परत केला जातो.
azure-document-intelligence prebuilt-read azure-document-intelligence/prebuilt-read असमकालिक अपस्ट्रीम (analyze + पोलिंग) — खाली पहा.
vertex-deepseek-ocr deepseek-ocr-maas vertex-deepseek-ocr/deepseek-ocr-maas समकालिक, Vertex AI च्या openapi/chat/completions भागीदार एंडपॉइंटद्वारे — प्रमाणीकरण/URL साठी खाली पहा.

तिन्ही प्रदाते समान Mistral-स्वरूपाच्या बॉडीमध्ये प्रतिसाद देतात:

{
  "pages": [{ "index": 0, "markdown": "# काढलेला मजकूर..." }],
  "model": "mistral-ocr-latest",
  "usage_info": { "pages_processed": 1 }
}

Azure Document Intelligence पोलिंग प्रवाह

Azure Document Intelligence चे analyze API असमकालिक आहे: प्रारंभिक विनंती बॉडीऐवजी Operation-Location हेडर परत करते आणि निकालासाठी पोलिंग करावे लागते. हँडलर (open-sse/handlers/ocr.ts) त्या URL वर दर सेकंदाला, जास्तीत जास्त 30 प्रयत्नांपर्यंत पोलिंग करतो; ok नसलेला पोल प्रतिसाद किंवा "failed" स्थिती आल्यास तो त्वरित अयशस्वी होतो (पोलिंग सुरू ठेवत नाही) आणि प्रयत्नांची मर्यादा संपल्यानंतरही प्रक्रिया सुरू असल्यास 504 परत करतो. कॉलरला परत करण्यापूर्वी अंतिम Azure प्रतिसाद Mistral द्वारे वापरल्या जाणाऱ्या त्याच pages/markdown स्वरूपात सामान्यीकृत केला जातो, त्यामुळे क्लायंट कोडला प्रदात्यासाठी वेगळे प्रकरण हाताळण्याची आवश्यकता नसते.

Vertex AI DeepSeek OCR प्रमाणीकरण आणि एंडपॉइंट निराकरण

vertex-deepseek-ocr, चॅट/प्रतिमा ट्रॅफिकसाठी OmniRoute आधीपासून समर्थित करत असलेले तेच Vertex AI प्रमाणीकरण पुन्हा वापरते (open-sse/executors/vertex.ts): कनेक्शनची API की ही एकतर Service Account JSON क्रेडेन्शियल असते (JWT-bearer प्रवाहाद्वारे अल्पकालीन OAuth ॲक्सेस टोकनसाठी अदलाबदल केलेली) किंवा आधीच तयार केलेले OAuth ॲक्सेस टोकन असते, जे जसेच्या तसे वापरले जाते. अपस्ट्रीम एंडपॉइंट URL हा Vertex चा सर्वसाधारण openapi/chat/completions भागीदार एंडपॉइंट आहे, जो कनेक्शनच्या प्रकल्प आणि प्रदेशावरून तयार केला जातो — स्पष्टपणे दिलेले providerSpecificData.project/providerSpecificData.region नेहमी प्राधान्य घेते; अन्यथा प्रकल्प Service Account JSON मधील project_id वरून निर्धारित केला जातो आणि प्रदेशासाठी डीफॉल्ट मूल्य us-central1 असते. दोन्ही निराकरणे open-sse/handlers/ocr.ts (resolveVertexOcrAccessToken, resolveVertexOcrBaseUrl) मध्ये होतात आणि handleOcr कडे पाठवण्यापूर्वी src/app/api/v1/ocr/route.ts द्वारे वापरली जातात.

मॉडेल्सची सूची

GET /v1/models
Authorization: Bearer your-api-key

→ OpenAI स्वरूपात सर्व चॅट, एम्बेडिंग आणि इमेज मॉडेल्स + कॉम्बोज परत करते

मॉडेल आयडी उपसर्ग (?prefix=)

बहुतेक मॉडेल्स प्रोव्हायडर उपसर्गाअंतर्गत उपलब्ध केली जातात. तुम्हाला कोणता उपसर्ग मिळेल हे MODELS_CATALOG_PREFIX_MODE फीचर फ्लॅगद्वारे नियंत्रित केले जाते आणि क्वेरी पॅरामीटरद्वारे प्रत्येक विनंतीसाठी ओव्हरराइड केले जाऊ शकते — इतर सर्वांसाठी सर्व्हर-व्यापी सेटिंग न बदलता स्वच्छ सूची हवी असलेल्या क्लायंटसाठी हे उपयुक्त आहे:

GET /v1/models?prefix=alias        # प्रत्येक मॉडेलसाठी एक आयडी — संक्षिप्त उपनाव उपसर्ग
GET /v1/models?prefix=dual         # दोन्ही स्वरूपे (सर्व्हर डीफॉल्ट)
GET /v1/models?prefix=canonical    # केवळ संपूर्ण प्रोव्हायडर-आयडी उपसर्ग
मोड आउटपुट नोंदी
dual cc/claude-sonnet-4-6 आणि claude/claude-sonnet-4-6 डीफॉल्ट. दोन्ही आयडी एकाच मॉडेलकडे रूट होतात; दोन्हींपैकी कोणतेही स्वरूप हार्डकोड केलेली क्लायंट कॉन्फिगरेशन कार्यरत राहावीत म्हणून हे ठेवले आहे. यामुळे कॅटलॉगचा आकार साधारणपणे दुप्पट होतो.
alias cc/claude-sonnet-4-6 प्रत्येक मॉडेलसाठी एक नोंद. स्वतंत्र उपनाव नसलेले प्रोव्हायडर तरीही त्यांची नोंद देतात, त्यामुळे काहीही गमावले जात नाही.
canonical claude/claude-sonnet-4-6 संपूर्ण प्रोव्हायडर-आयडी उपसर्गाखाली प्रत्येक मॉडेलसाठी एक नोंद. स्वतंत्र उपनाव नसलेले प्रोव्हायडर (उदा. antigravity/…, agy/…) येथेही त्यांचा एकमेव आयडी देतात, त्यामुळे काहीही गमावले जात नाही.

क्वेरी पॅरामीटरशिवायही dual-मोड मिरर ओळखता येतो: त्यात प्राथमिक आयडीकडे निर्देश करणारे parent फील्ड असते.

मॉडेल पिकर दाखवणाऱ्या क्लायंटनी ?prefix=alias ची विनंती करावी — OmniCopilot VS Code एक्स्टेंशन हेच करते.

विचार-विरहित मॉडेल प्रकार

विचार करण्यास सक्षम Claude मॉडेल्ससाठी, /v1/models एक विचार-विरहित प्रकारही उपलब्ध करते, ज्याच्या आयडीला claude-3-omniroute-no-thinking/ हा उपसर्ग असतो:

claude-3-omniroute-no-thinking/<provider>/<model>

हा आयडी निवडल्यास (उदा. नेहमी thinking ब्लॉक जोडणाऱ्या Claude Code कॉन्फिगरेशनमध्ये), रीझनिंग दडपून तो पुन्हा वास्तविक <provider>/<model> मध्ये रिझॉल्व्ह होतो — /v1/messages पाथवर thinking:{type:"disabled"}, किंवा /v1/chat/completions पाथवर reasoning/reasoning_effort फील्ड्स वगळली जातात. हा प्रकार केवळ विचार करण्यास समर्थन देणाऱ्या आणि disabled चा आदर करणाऱ्या Claude-कुटुंबातील मॉडेल्ससाठी सूचीबद्ध केला जातो (म्हणून, उदा. disabled नाकारणारी केवळ-अॅडॅप्टिव्ह मॉडेल्स वगळली जातात). ऑपरेटर्स ModelSpec.noThinkingAlias द्वारे प्रत्येक मॉडेलनुसार हा प्रकार सक्तीने सुरू किंवा बंद करू शकतात.

प्रोव्हायडर प्लगइन मॅनिफेस्ट

GET /api/v1/provider-plugin-manifest

Bifrost, CLIProxyAPI आणि भविष्यातील साइडकार राउटर्सद्वारे वापरला जाणारा JSON-सुरक्षित प्रोव्हायडर प्लगइन मॅनिफेस्ट परत करतो. प्रतिसाद TypeScript प्रोव्हायडर रजिस्ट्रीमधून तयार केला जातो आणि त्यातून हेतुपुरस्सर OAuth क्लायंट सिक्रेट्स, रनटाइम एन्व्हायर्नमेंट रिझोल्यूशन, एक्झिक्युटर फंक्शन्स, रिक्वेस्ट हेडर्स आणि खाते डेटा वगळला जातो.

जेव्हा एखादा साइडकार स्वतंत्र प्रक्रियेत चालतो आणि थेट open-sse/config/providerPluginManifestRegistry.ts इम्पोर्ट करू शकत नाही, तेव्हा हा एंडपॉइंट वापरा.

सुसंगतता एंडपॉइंट्स

पद्धत पाथ स्वरूप
POST /v1/chat/completions OpenAI
POST /v1/messages Anthropic
POST /v1/responses OpenAI Responses
POST /v1/embeddings OpenAI
POST /v1/images/generations OpenAI Images
POST /v1/images/edits OpenAI Images (संपादन/इनपेंट)
POST /v1/videos/generations OpenAI-शैलीतील व्हिडिओ निर्मिती
POST /v1/music/generations OpenAI-शैलीतील संगीत निर्मिती
POST /v1/audio/transcriptions OpenAI Audio (STT)
POST /v1/audio/speech OpenAI TTS (ऑडिओ बॉडी परत करतो)
POST /v1/rerank Cohere/Voyage-शैलीतील रीरँक
POST /v1/classify Jina वर्गीकरण (api.jina.ai)
POST /v1/segment Jina सेगमेंटर (segment.jina.ai)
POST /v1/moderations OpenAI Moderations
GET /v1/models OpenAI
POST /v1/messages/count_tokens Anthropic
GET /v1beta/models Gemini
POST /v1beta/models/{...path} Gemini generateContent
POST /v1/api/chat Ollama
GET /api/v1/vscode/{token}/ OpenAI कॅटलॉग उपनाव
GET /api/v1/vscode/{token}/models OpenAI मॉडेल्स उपनाव
POST /api/v1/vscode/{token}/chat/completions OpenAI टोकनयुक्त उपनाव
POST /api/v1/vscode/{token}/responses OpenAI Responses टोकनयुक्त उपनाव
POST /api/v1/vscode/{token}/api/chat Ollama टोकनयुक्त उपनाव
GET /api/v1/vscode/{token}/api/tags Ollama टॅग्ज टोकनयुक्त उपनाव

सर्व POST रूट्स समान रचना वापरतात: Bearer your-api-key + Zod-द्वारे प्रमाणित JSON बॉडी (v1RerankSchema, v1ModerationSchema, v1AudioSpeechSchema इत्यादी; src/shared/validation/schemas.ts पहा). स्कीमा प्रमाणीकरण अयशस्वी झाल्यास 4xx परत केला जातो.

जे क्लायंट Authorization: Bearer ... जोडू शकत नाहीत त्यांच्यासाठी, OmniRoute क्वेरी-स्ट्रिंग सुसंगततेद्वारे (?token=..., ?apiKey=..., ?api_key=..., ?key=...) किंवा खाली दस्तऐवजीकरण केलेल्या समर्पित /api/v1/vscode/{token}/... एंडपॉइंट्सद्वारे URL मधील API की देखील स्वीकारतो.

# रीरँक
POST /v1/rerank      { "model": "jina-ai/jina-reranker-v3.5", "query": "...", "documents": ["..."] }

# Jina वर्गीकरण (Foundation API क्रेडेन्शियल्स)
POST /v1/classify    { "model": "jina-embeddings-v5-text-small", "input": ["..."], "labels": ["a", "b"] }

# Jina सेगमेंटर
POST /v1/segment     { "content": "...", "return_chunks": true }

# Jina शोध (s.jina.ai; प्रोव्हायडर उपनावे: jina-search, jina-ai, jina)
POST /v1/search      { "query": "...", "provider": "jina-search" }

# मॉडरेशन
POST /v1/moderations { "model": "omni-moderation-latest", "input": "..." }

# TTS — audio/mpeg (किंवा विनंती केलेल्या स्वरूपाची) बॉडी परत करतो
POST /v1/audio/speech { "model": "openai/tts-1", "input": "Hello", "voice": "alloy" }

# प्रतिमा संपादन (multipart)
POST /v1/images/edits  -F image=@input.png -F prompt="..." -F mask=@mask.png

# व्हिडिओ / संगीत निर्मिती (प्रोव्हायडर-उपसर्गयुक्त मॉडेल आयडी)
POST /v1/videos/generations { "model": "runway/gen-3", "prompt": "..." }
POST /v1/music/generations  { "model": "suno/v3.5",   "prompt": "..." }

समर्पित प्रोव्हायडर रूट्स

POST /v1/providers/{provider}/chat/completions
POST /v1/providers/{provider}/embeddings
POST /v1/providers/{provider}/images/generations

प्रोव्हायडर उपसर्ग नसल्यास तो आपोआप जोडला जातो. विसंगत मॉडेल्ससाठी 400 परत केला जातो.

Files API

बॅच इनपुट/आउटपुट आणि फाइल-उद्देश अपलोडसाठी OpenAI-सुसंगत फाइल्स एंडपॉइंट.

पद्धत पथ वर्णन
POST /v1/files फाइल अपलोड करा (multipart: file, purpose, expires_after[anchor], expires_after[seconds]) — कमाल 512 MiB
GET /v1/files प्रमाणीकृत API कीसाठी फाइल्सची सूची मिळवा
GET /v1/files/[id] फाइलचा मेटाडेटा मिळवा
DELETE /v1/files/[id] फाइल हटवा
GET /v1/files/[id]/content मूळ फाइल बॉडी परत स्ट्रीम करा

प्रमाणीकरण: Bearer API की — getApiKeyRequestScope द्वारे फाइल्स प्रत्येक API कीनुसार मर्यादित केल्या जातात. एखाद्या कीला फक्त स्वतःच्या फाइल्स पाहता, डाउनलोड करता आणि हटवता येतात; की नसलेले डॅशबोर्ड सत्र संपूर्ण इन्स्टन्स वाचू शकते; मालक नसलेली फाइल (अनामिक किंवा डॅशबोर्ड-सत्र अपलोड) प्रत्येक सत्रेतर कॉलरसाठी प्रतिबंधित असते. GET /v1/files अनामिक कॉलरला — आणि प्रदान केलेली पण निराकरण न होणारी की असल्यासही — REQUIRE_API_KEY=false असतानादेखील प्रत्येक टेनंटच्या फाइल्सची सूची दाखवण्याऐवजी 401 सह नाकारते (GHSA-m3hp-hq9g-fpmv, GHSA-2jm2-mpx8-6523).

Batches API

OpenAI-सुसंगत बॅच प्रक्रिया.

पद्धत पथ वर्णन
POST /v1/batches बॅच तयार करा — बॉडीची v1BatchCreateSchema द्वारे पडताळणी केली जाते (input_file_id, endpoint, completion_window)
GET /v1/batches बॅचेसची सूची मिळवा
GET /v1/batches/[id] बॅचची स्थिती + request_counts मिळवा
DELETE /v1/batches/[id] पूर्ण झालेली/अयशस्वी बॅच हटवा
POST /v1/batches/[id]/cancel प्रगतीपथावर असलेली बॅच रद्द करा

प्रमाणीकरण: Bearer API की. फाइल्सप्रमाणेच त्याच त्रिस्तरीय नियमानुसार बॅचेस प्रत्येक API कीनुसार मर्यादित केल्या जातात: केवळ स्वतःची की, संपूर्ण इन्स्टन्ससाठी डॅशबोर्ड सत्र, आणि मालक-नसलेल्या नोंदी प्रत्येक सत्रेतर कॉलरसाठी प्रतिबंधित (मिळवणे, हटवणे, रद्द करणे आणि तयार करताना input_file_id ची तपासणी). REQUIRE_API_KEY=false असतानादेखील GET /v1/batches अनामिक कॉलरला 401 सह नाकारते.

Search API

वेब/शोध प्रदाता अमूर्तीकरण (Tavily, Brave, Exa, Serper इत्यादी).

पद्धत पथ वर्णन
GET /v1/search कॉन्फिगर केलेल्या शोध प्रदात्यांची + क्षमतांची सूची
POST /v1/search शोध क्वेरी चालवा — body चे प्रमाणीकरण v1SearchSchema द्वारे केले जाते, caching/coalescing समर्थित
GET /v1/search/analytics प्रत्येक प्रदात्यासाठी hit/latency/cache आकडेवारी

प्रमाणीकरण: Bearer API key (extractApiKey + isValidApiKey). शोध धोरण enforceApiKeyPolicy द्वारे लागू केले जाते.

Web Fetch API

कॉन्फिगर केलेल्या web-fetch प्रदात्यामार्फत URL मधून सामग्री काढा (Firecrawl, Jina Reader, Tavily Extract, TinyFish Fetch, Nimble Extract).

पद्धत पथ वर्णन
POST /v1/web/fetch URL fetch/scrape करा — body चे प्रमाणीकरण v1WebFetchSchema द्वारे केले जाते

प्रमाणीकरण: Bearer API key (extractApiKey + isValidApiKey). धोरण enforceApiKeyPolicy द्वारे लागू केले जाते.

कोटा-जागरूक fallback (#8297): स्पष्ट provider दिलेला नसताना, pool मधील (firecrawl → jina-reader → tavily-search → tinyfish → nimble-search) प्रदाते निश्चित प्राधान्यक्रमाने (fill-first) वापरून पाहिले जातात — rate-limited असलेला पण कॉन्फिगर केलेला प्रदाता विनंती तिथेच थांबवण्याऐवजी वगळला जातो आणि retryable/quota upstream अपयश आल्यास (HTTP 429 नेहमी; Firecrawl/Tavily/TinyFish च्या quota-style free tiers साठी 402/403 — Jina Reader साठी नाही आणि साध्या 400 bad request साठी कधीही नाही) विनंतीच्या वेळी पुढील अद्याप न वापरलेल्या credentialed प्रदात्याकडे प्रक्रिया जाते. pool मधील प्रत्येक प्रदाता संपल्यानंतर, endpoint पूर्वीच्या सामान्य 400 ऐवजी एकच 429 (Retry-After header सह) परत करतो. स्पष्ट provider मागितला असल्यास, कोणताही मूक fallback नसतो — rate-limited किंवा अपयशी स्पष्ट प्रदात्याची स्वतःची त्रुटी दर्शवली जाते (rate-limited असल्यास 429, अन्यथा upstream status).

WebSocket Streaming

GET /v1/ws?handshake=1

WebSocket upgrade handshake चे प्रमाणीकरण करते आणि wire protocol ची उदाहरण संदेशे (request, cancel) परत करते. प्रत्यक्ष WS frames हे Next.js route table च्या बाहेर असलेल्या समाविष्ट WS server द्वारे हाताळले जातात.

प्रमाणीकरण: handshake दरम्यान Bearer API key.

WebSocket वर Responses API (केवळ codex)

# HTTP API सारखाच host:port (default 20128); connection upgrade करा:
wscat -c "ws://localhost:20128/v1/responses?api_key=<OMNIROUTE_API_KEY>"
# (किंवा: -H "Authorization: Bearer <OMNIROUTE_API_KEY>")

# पहिला frame response.create असलाच पाहिजे:
{ "type": "response.create", "model": "gpt-5.5", "input": [ { "role": "user", "content": "hi" } ] }

Responses-API-over-WebSocket proxy केवळ codex शी (ChatGPT backend) जोडलेला आहे. तो API/dashboard सारख्याच port वर /v1/responses, /responses आणि /api/v1/responses या paths वर ऐकतो. पहिल्या response.create frame वर तो अंतर्गत codex-responses-ws bridge द्वारे प्रमाणीकरण + तयारी करतो, एक codex OAuth connection निवडतो आणि wreq-js transport द्वारे wss://chatgpt.com/backend-api/codex/responses कडे tunnel करतो. codex व्यतिरिक्त इतर models नाकारले जातात (codex_ws_provider_required). quota-share routing साठी model: "qtSd/<group>/codex/<model>" वापरा. याची अंमलबजावणी app/server-ws.mjs + scripts/dev/responses-ws-proxy.mjs + src/app/api/internal/codex-responses-ws/route.ts मध्ये केली आहे.

प्रमाणीकरण: handshake दरम्यान Bearer API key. समाविष्ट HTTP server (server-ws.mjs) हा सक्रिय entrypoint असला पाहिजे (app/server-ws.mjs अस्तित्वात असताना तो default ने सक्रिय असतो).

Model id: मूळ ChatGPT id वापरा (codex/ prefix शिवाय)

OpenAI Codex CLI, supports_websockets = true असताना, client-side वर model name चे प्रमाणीकरण करते आणि codex/gpt-5.5 सारखे provider-prefixed ids नाकारते (The 'codex/gpt-5.5' model is not supported when using Codex with a ChatGPT account). मूळ id पाठवा (उदा. gpt-5.5). OmniRoute चा bridge केवळ codex साठी असल्यामुळे, upstream कडे tunnel करण्यापूर्वी तो मूळ id ला codex model म्हणून (resolveCodexWsModelInfo) पुन्हा resolve करतो — जरी मूळ gpt-5.5 अन्यथा HTTP वरून दुसऱ्या प्रदात्याकडे route झाले असते.

OpenAI Codex CLI कॉन्फिगर करणे

~/.codex/config.toml मध्ये WebSocket समर्थन असलेला custom provider जोडून Codex CLI ला OmniRoute कडे निर्देशित करा (विद्यमान config मध्ये बदल करणे टाळण्यासाठी स्वतंत्र CODEX_HOME वापरा):

model = "gpt-5.5"                 # मूळ id — "codex/gpt-5.5" नाही
model_provider = "omniroute"

[model_providers.omniroute]
name = "OmniRoute (WS)"
base_url = "http://localhost:20128/v1"   # शेवटी slash नाही; WS URL यावरून तयार होतो (production मध्ये https/wss वापरा)
wire_api = "responses"                    # Feb 2026 पासून समर्थित असलेले एकमेव value
supports_websockets = true                # Responses-over-WS transport सक्षम करते
env_key = "OMNIROUTE_API_KEY"             # OmniRoute API key (Bearer) ठेवते

export OMNIROUTE_API_KEY=sk-...           # एक OmniRoute API key (REQUIRE_API_KEY=false असल्यास कोणतीही key)
codex exec "Responda apenas: PONG"

CLI, base_url + /responses ला WebSocket मध्ये upgrade करते आणि OmniRoute त्याला निवडलेल्या codex OAuth connection कडे tunnel करते. स्थानिक server विरुद्ध end-to-end प्रमाणीकरण केले आहे: ChatGPT codex.rate_limits + response.created परत करते आणि completion stream करते.

कोटा आणि समस्या अहवाल

पद्धत पथ वर्णन
GET /v1/quotas/check नोंदणीकृत की जारी करण्यापूर्वी provider + accountId साठी कोट्याचे पूर्व-सत्यापन करा
POST /v1/issues/report कोटा/की जारी करण्यातील अपयशाचा GitHub वर अहवाल द्या (GITHUB_ISSUES_REPO + टोकन आवश्यक)

प्रमाणीकरण: Bearer API की (isAuthenticated).

स्वयं-सेवा वापर (/api/usage/om-usage)

कोणतीही API की स्वतःचा वापर आणि कोटे वाचू शकते — व्यवस्थापन प्रमाणीकरणाची आवश्यकता नाही. कीधारकाला त्याचा खर्च दाखवण्यासाठी क्लायंट (CLI, OmniCopilot पॅनेल) हा एंडपॉइंट वापरतो.

# मजकूर स्वरूप (ऐतिहासिक करार — टर्मिनलसाठी साधा मजकूर)
curl -H "Authorization: Bearer <your-api-key>" \
  http://localhost:20128/api/usage/om-usage

# संरचित स्वरूप — UI द्वारे वापरले जाणारे स्वरूप
curl -H "Authorization: Bearer <your-api-key>" \
  "http://localhost:20128/api/usage/om-usage?format=json"

कीसाठी allowUsageCommand सक्षम असणे आवश्यक आहे (डीफॉल्टनुसार बंद — डॅशबोर्डचा API-की व्यवस्थापक प्रत्येक कीसाठी ते टॉगल करतो). ते सक्षम नसल्यास एंडपॉइंट 403 प्रतिसाद देतो.

?format=json एक विभेदित रचना परत करते, त्यामुळे कॉलर नकाराच्या प्रतिसादातून कधीही डेटा फील्ड वाचत नाही. यशस्वी झाल्यास:

{
  "allowed": true,
  // कीने प्रत्येक-की वापर मर्यादा (दैनिक/साप्ताहिक USD) स्वीकारल्या असतील तेव्हाच उपस्थित:
  "personal": {
    "dailySpentUsd": 1.25,
    "dailyLimitUsd": 5,
    "dailyResetAtIso": "…",
    "weeklySpentUsd": 8,
    "weeklyLimitUsd": 20,
    "weeklyResetAtIso": "…" /* … */,
  },
  // निवडलेल्या प्रदात्याचा कोटा स्नॅपशॉट किंवा अद्याप काहीही कॅश केलेले नसल्यास null:
  "provider": {
    "connectionId": "…",
    "provider": "claude",
    "plan": "…",
    "quotas": {/* … */},
  },
  // प्रत्येक कनेक्शनचा स्नॅपशॉट, जेणेकरून UI अनेक प्रदाते शेजारी-शेजारी रेंडर करू शकेल:
  "providers": [
    { "connectionId": "…", "provider": "claude" /* … */ },
    { "provider": "codex" /* … */ },
  ],
}

नकार दिल्यास (401 चुकीची की / 403 परवानगी नाही), हाच रूट { "allowed": false, "error": { "message": "…" } } परत करतो — उपस्थित-पण-रिक्त personal/provider (कीला परवानगी आहे, अद्याप काहीही माहिती मिळालेली नाही) ही नकारापेक्षा वेगळी स्थिती आहे आणि केवळ JSON स्वरूप त्यांच्यातील फरक स्पष्ट करते.

प्रमाणीकरण: कॉलरची स्वतःची Bearer API की, isValidApiKey वापरून सत्यापित केली जाते — हे व्यवस्थापन पृष्ठभाग (/api/keys/…) नाही, जो requireManagementAuth द्वारे संरक्षित राहतो.

सिमॅंटिक कॅश

# कॅशची आकडेवारी मिळवा
GET /api/cache/stats

# सर्व कॅश साफ करा
DELETE /api/cache/stats

प्रतिसादाचे उदाहरण:

{
  "semanticCache": {
    "memorySize": 42,
    "memoryMaxSize": 500,
    "dbSize": 128,
    "hitRate": 0.65
  },
  "idempotency": {
    "activeKeys": 3,
    "windowMs": 5000
  }
}

विलंबावरील परिणाम

सिमॅंटिक कॅश HIT प्रतिसाद अपस्ट्रीम कॉलशिवाय कॅशमधून देते, त्यामुळे नोंदवलेला X-OmniRoute-Response-Latency जवळजवळ शून्य असतो (मूळ अपस्ट्रीम विलंब कितीही असला तरी). विलंबाबाबत संवेदनशील क्लायंटनी (बेंचमार्किंग, p50/p99 निरीक्षण) X-OmniRoute-Cache-Latency प्रतिसाद हेडर तपासावे:

मूल्य अर्थ
synthetic प्रतिसाद कॅशमधून दिला; हा विलंब वास्तविक अपस्ट्रीम वेळ नाही
(अनुपस्थित) वास्तविक अपस्ट्रीम कॉलमधून मिळालेला प्रतिसाद

प्रत्येक-की कॅश बायपास

API की cacheDefaultMode द्वारे सिमॅंटिक कॅश वाचनातून बाहेर पडण्याचा पर्याय निवडू शकतात:

मूल्य वर्तन
legacy सामान्य कॅश वर्तन (डीफॉल्ट)
bypass कॅश लुकअप पूर्णपणे वगळा; नेहमी अपस्ट्रीमवर कॉल करा

की तयार करताना (POST /api/keys) सेट करा किंवा (PATCH /api/keys/[id]) अद्ययावत करा:

{ "cacheDefaultMode": "bypass" }

प्रत्येक-विनंती बायपास

की सेटिंग्जची पर्वा न करता कोणतीही विनंती कॅश बायपास करू शकते:

X-OmniRoute-No-Cache: true

डॅशबोर्ड आणि व्यवस्थापन

व्यवस्थापन मार्ग (/api/*, सार्वजनिक प्रमाणीकरण/लॉगिन वगळता) सामान्य इन्फरन्स API कीद्वारे अधिकृत केले जात नाहीत. क्रेडेन्शियल प्रकार, स्कोप आणि curl उदाहरणे: व्यवस्थापन प्रमाणीकरण.

प्रमाणीकरण

एंडपॉइंट पद्धत वर्णन
/api/auth/login POST लॉगिन
/api/auth/logout POST लॉगआउट
/api/settings/require-login GET/PUT लॉगिन आवश्यक असणे टॉगल करा

प्रदाता व्यवस्थापन

एंडपॉइंट पद्धत वर्णन
/api/providers GET/POST प्रदात्यांची सूची / प्रदाते तयार करा
/api/providers/[id] GET/PUT/DELETE प्रदाता व्यवस्थापित करा
/api/providers/[id]/test POST प्रदाता कनेक्शनची चाचणी करा
/api/providers/[id]/models GET प्रदात्याच्या मॉडेलची सूची द्या
/api/providers/validate POST प्रदाता कॉन्फिगरेशन प्रमाणित करा
/api/providers/bulk POST एका प्रदात्यासाठी API की मोठ्या प्रमाणात जोडा
/api/providers/import POST पार्स केलेल्या CSV/JSON फाइलमधून विविध प्रदात्यांची सूची आयात करा (#6836); प्रत्येक ओळीसाठी आंशिक-अपयशाचे परिणाम
/api/provider-nodes* विविध प्रदाता नोड व्यवस्थापन
/api/provider-models GET/POST/PATCH/DELETE सानुकूल मॉडेल (जोडा, अद्ययावत करा, लपवा/दाखवा, हटवा)

OAuth प्रवाह

एंडपॉइंट पद्धत वर्णन
/api/oauth/[provider]/[action] विविध प्रदाता-विशिष्ट OAuth

रूटिंग आणि कॉन्फिगरेशन

एंडपॉइंट पद्धत वर्णन
/api/models/alias GET/POST मॉडेल उपनावे
/api/models/catalog GET प्रदाता + प्रकारानुसार सर्व मॉडेल
/api/combos* विविध कॉम्बो व्यवस्थापन
/api/keys* विविध API की व्यवस्थापन
/api/pricing GET मॉडेल किंमत

वापर आणि विश्लेषण

Endpoint पद्धत वर्णन
/api/usage/history GET वापराचा इतिहास
/api/usage/logs GET वापर नोंदी
/api/usage/request-logs GET विनंती-स्तरीय नोंदी
/api/usage/[connectionId] GET प्रत्येक कनेक्शनचा वापर
/api/usage/token-limits GET/POST/DELETE प्रत्येक API कीसाठी टोकन-मर्यादा बजेट
/api/usage/model-latency-stats GET प्रत्येक प्रदाता/मॉडेलसाठी रोलिंग विलंब एकत्रित आकडेवारी (सरासरी/p50/p95/p99, यशाचा दर); फिल्टर्स: windowHours/minSamples/maxRows/provider/model (#6873)
/api/usage/cache-health GET call_logs वरील प्रॉम्प्ट-कॅश आरोग्य सारांश — लेखन/वाचन गुणोत्तर, p50/p90/p99 लेखन-आकार वितरण, मोठ्या लेखनांचे केंद्रीकरण, प्रत्येक मॉडेलनुसार विभागणी आणि healthy/degraded/thrash/no-data निकाल; क्वेरी पॅरामीटर्स range (1h|24h|7d|30d, डीफॉल्ट 24h) आणि पर्यायी model (#8827)

सेटिंग्ज

Endpoint पद्धत वर्णन
/api/settings GET/PUT/PATCH सामान्य सेटिंग्ज
/api/settings/proxy GET/PUT नेटवर्क प्रॉक्सी कॉन्फिगरेशन
/api/settings/proxy/test POST प्रॉक्सी कनेक्शनची चाचणी करा
/api/settings/ip-filter GET/PUT IP अनुमतीसूची/अवरोधसूची
/api/settings/thinking-budget GET/PUT विचार/तर्क विनंती पुनर्लेखन मोड (जसेच्या तसे / स्वयंचलित-वगळणे / सानुकूल / अनुकूलनीय). संक्षेपणापासून स्वतंत्र. THINKING_BUDGET.md पहा.
/api/settings/system-prompt GET/PUT जागतिक सिस्टम प्रॉम्प्ट
/api/settings/compression GET/PUT जागतिक संक्षेपण कॉन्फिगरेशन
/api/settings/purge-request-history POST विनंती नोंद पंक्ती आणि स्थानिक कॉल-लॉग आर्टिफॅक्ट्स साफ करा

संदर्भ आणि संक्षेपण

Endpoint पद्धत वर्णन
/api/compression/preview POST off/lite/standard/aggressive/ultra/RTK/stacked संक्षेपणाचे पूर्वावलोकन
/api/compression/language-packs GET उपलब्ध Caveman भाषा पॅकची सूची
/api/compression/rules GET Caveman नियमांच्या मेटाडेटाची सूची
/api/context/caveman/config GET/PUT Caveman-विशिष्ट सेटिंग्जचे उपनाव
/api/context/rtk/config GET/PUT सानुकूल फिल्टर आणि कच्चे आउटपुट राखून ठेवण्यासह RTK-विशिष्ट सेटिंग्ज
/api/context/rtk/filters GET RTK फिल्टर कॅटलॉग आणि सानुकूल-फिल्टर निदान
/api/context/rtk/test POST मजकूर पेलोडवर RTK पूर्वावलोकन/चाचणी चालवा
/api/context/rtk/raw-output/[id] GET पॉइंटर id द्वारे राखून ठेवलेले संपादित कच्चे आउटपुट वाचा
/api/context/combos GET/POST संक्षेपण कॉम्बोची सूची/निर्मिती
/api/context/combos/[id] GET/PUT/DELETE संक्षेपण कॉम्बोचे तपशील/अद्यतन/हटवणे
/api/context/combos/[id]/assignments GET/PUT रूटिंग कॉम्बोंना संक्षेपण कॉम्बो नियुक्त करा
/api/context/analytics GET संक्षेपण विश्लेषणाचे उपनाव

निरीक्षण

Endpoint पद्धत वर्णन
/api/sessions GET सक्रिय सत्रांचा मागोवा
/api/rate-limits GET प्रत्येक खात्यासाठी दर मर्यादा
/api/monitoring/health GET आरोग्य तपासणी + प्रदाता सारांश (catalogCount, configuredCount, activeCount, monitoredCount). व्यवस्थापन दृश्यात credentialHealth समाविष्ट आहे: प्रोब-कॅशे स्केलर, failed>0 असताना failedConnections, आणि staleDbNonOkCount (SQLite स्टिकी test_status, गेज नव्हे). MONITORING_GUIDE.md पहा.
/api/cache/stats GET/DELETE कॅशे आकडेवारी / साफ करणे
/api/modality-bridge/stats GET इन-मेमरी attempts, यशस्वी प्रयत्न/bridged, अपयश, कॅशे हिट्स, totalLatencyMs, latencySamples, नमुना-भाजकाधारित averageLatencyMs, आणि शेवटच्या वापराची वेळ (रीस्टार्ट केल्यावर रीसेट होते; व्यवस्थापन प्रमाणीकरण)
/api/modality-bridge/video/runtime GET व्यवस्थापन प्रमाणीकरण/प्रोबपूर्वी कठोर विश्वसनीय-लूपबॅक तपासणी; स्वच्छ केलेली FFmpeg/ffprobe उपलब्धता आणि आवृत्त्या (no-store)
/api/modality-bridge/video/extract POST अंतर्गत प्रमाणीकृत विश्वसनीय-लूपबॅक बाइट ब्रोकर; 50 MiB इनपुट, मर्यादित रांग/32 MiB आउटपुट, 503 क्षमता, 499 डिस्कनेक्ट, 504 अंतिम मुदत; हे सार्वजनिक अपलोड API नाही

बॅकअप आणि निर्यात/आयात

एंडपॉइंट पद्धत वर्णन
/api/db-backups GET उपलब्ध बॅकअपची सूची
/api/db-backups PUT मॅन्युअल बॅकअप तयार करा
/api/db-backups POST विशिष्ट बॅकअपमधून पुनर्संचयित करा
/api/db-backups/export GET डेटाबेस .sqlite फाइल म्हणून डाउनलोड करा
/api/db-backups/import POST डेटाबेस बदलण्यासाठी .sqlite फाइल अपलोड करा
/api/db-backups/exportAll GET संपूर्ण बॅकअप .tar.gz संग्रहण म्हणून डाउनलोड करा

क्लाउड समक्रमण

एंडपॉइंट पद्धत वर्णन
/api/sync/cloud विविध क्लाउड समक्रमण क्रिया
/api/sync/initialize POST समक्रमण प्रारंभ करा
/api/cloud/* विविध क्लाउड व्यवस्थापन

टनेल

एंडपॉइंट पद्धत वर्णन
/api/tunnels/cloudflared GET डॅशबोर्डसाठी Cloudflare Quick Tunnel ची स्थापना/रनटाइम स्थिती वाचा
/api/tunnels/cloudflared POST Cloudflare Quick Tunnel सक्षम किंवा अक्षम करा (action=enable/disable)
/api/tunnels/ngrok GET डॅशबोर्डसाठी ngrok Tunnel ची रनटाइम स्थिती वाचा
/api/tunnels/ngrok POST ngrok Tunnel सक्षम किंवा अक्षम करा (action=enable/disable)

CLI साधने

एंडपॉइंट पद्धत वर्णन
/api/cli-tools/claude-settings GET Claude CLI स्थिती
/api/cli-tools/codex-settings GET Codex CLI स्थिती
/api/cli-tools/droid-settings GET Droid CLI स्थिती
/api/cli-tools/openclaw-settings GET OpenClaw CLI स्थिती
/api/cli-tools/runtime/[toolId] GET सामान्य CLI रनटाइम

CLI प्रतिसादांमध्ये यांचा समावेश असतो: installed, runnable, command, commandPath, runtimeMode, reason.

ACP एजंट

एंडपॉइंट पद्धत वर्णन
/api/acp/agents GET स्थितीसह शोधलेल्या सर्व एजंटची सूची (अंगभूत + सानुकूल)
/api/acp/agents POST सानुकूल एजंट जोडा किंवा शोध कॅशे रीफ्रेश करा
/api/acp/agents DELETE id क्वेरी पॅरामिटरद्वारे सानुकूल एजंट काढा

GET प्रतिसादामध्ये agents[] (id, name, binary, version, installed, protocol, isCustom) आणि summary (total, installed, notFound, builtIn, custom) यांचा समावेश असतो.

लवचिकता आणि दर मर्यादा

एंडपॉइंट पद्धत वर्णन
/api/resilience GET/PATCH विनंती रांग, कनेक्शन कूलडाउन, प्रदाता ब्रेकर आणि प्रतीक्षा सेटिंग्ज मिळवा/अपडेट करा
/api/resilience/reset POST प्रदाता सर्किट ब्रेकर रीसेट करा
/api/resilience/model-cooldowns GET उर्वरित वेळेनुसार क्रमबद्ध केलेले सक्रिय प्रति-(प्रदाता, कनेक्शन, मॉडेल) लॉकआउट सूचीबद्ध करा
/api/resilience/model-cooldowns DELETE मॉडेल लॉकआउट साफ करा — मुख्य भागात {provider, model} किंवा सर्वकाही पुसण्यासाठी {all: true}
/api/rate-limits GET प्रत्येक खात्याची दर मर्यादा स्थिती
/api/rate-limit GET जागतिक दर मर्यादा कॉन्फिगरेशन

सर्व चार /api/resilience/* मार्गांसाठी व्यवस्थापन प्रमाणीकरण (requireManagementAuth) आवश्यक आहे. प्रदाता ब्रेकर विरुद्ध कनेक्शन कूलडाउन विरुद्ध मॉडेल लॉकआउट यांच्या संपूर्ण तपशीलासाठी लवचिकता (विस्तारित) पहा.

मूल्यमापन

एंडपॉइंट पद्धत वर्णन
/api/evals GET/POST मूल्यमापन संच सूचीबद्ध करा / मूल्यमापन चालवा

धोरणे

एंडपॉइंट पद्धत वर्णन
/api/policies GET/POST/DELETE रूटिंग धोरणे व्यवस्थापित करा

अनुपालन

एंडपॉइंट पद्धत वर्णन
/api/compliance/audit-log GET अनुपालन ऑडिट लॉग (शेवटचे N)

v1beta (Gemini-सुसंगत)

एंडपॉइंट पद्धत वर्णन
/v1beta/models GET Gemini स्वरूपातील मॉडेलची सूची
/v1beta/models/{...path} POST Gemini generateContent एंडपॉइंट

मूळ Gemini SDK सुसंगततेची अपेक्षा करणाऱ्या क्लायंटसाठी हे एंडपॉइंट Gemini च्या API स्वरूपाचे प्रतिबिंब करतात.

अंतर्गत / प्रणाली API

एंडपॉइंट पद्धत वर्णन
/api/init GET ॲप्लिकेशन प्रारंभीकरण तपासणी (प्रथम वापरावेळी वापरली जाते)
/api/tags GET Ollama-सुसंगत मॉडेल टॅग्ज (Ollama क्लायंटसाठी)
/api/restart POST सर्व्हरचे सुरळीत रीस्टार्ट ट्रिगर करा
/api/shutdown POST सर्व्हरचे सुरळीत शटडाउन ट्रिगर करा
/api/system/env/repair POST OAuth प्रदात्याचे पर्यावरणीय चल दुरुस्त करा

टीप: हे एंडपॉइंट्स प्रणालीद्वारे अंतर्गतरीत्या किंवा Ollama क्लायंट सुसंगततेसाठी वापरले जातात. सामान्यतः अंतिम वापरकर्ते त्यांना कॉल करत नाहीत.

OAuth पर्यावरण दुरुस्ती (v3.6.1+)

POST /api/system/env/repair
Content-Type: application/json

{
  "provider": "claude-code"
}

विशिष्ट प्रदात्यासाठी गहाळ किंवा दूषित OAuth पर्यावरणीय चल दुरुस्त करते. पुढील प्रतिसाद देते:

{
  "success": true,
  "repaired": ["CLAUDE_CODE_OAUTH_CLIENT_ID", "CLAUDE_CODE_OAUTH_CLIENT_SECRET"],
  "backupPath": "/home/user/.omniroute/backups/env-repair-2026-04-11.bak"
}

ऑडिओ लिप्यंतरण

POST /v1/audio/transcriptions
Authorization: Bearer your-api-key
Content-Type: multipart/form-data

कॉन्फिगर केलेल्या कोणत्याही STT प्रदात्याचा वापर करून ऑडिओ फाइल्सचे लिप्यंतरण करा. पाथचा पहिला सेगमेंट मूळ प्रदाता निवडतो (openai/…, deepgram/…). दुसऱ्या विक्रेत्याचे मॉडेल पुन्हा निर्यात करणारे गेटवे पूर्णपणे पात्र id वापरतात (openrouter/deepgram/nova-3).

विनंती:

curl -X POST http://localhost:20128/v1/audio/transcriptions \
  -H "Authorization: Bearer your-api-key" \
  -F "file=@recording.mp3" \
  -F "model=openai/whisper-1"

प्रतिसाद:

{
  "text": "Hello, this is the transcribed audio content.",
  "task": "transcribe",
  "language": "en",
  "duration": 12.5
}

उदाहरणार्थ मॉडेल ids: openai/whisper-1 (OpenAI की आवश्यक आहे), openrouter/deepgram/nova-3 (OpenRouter की आवश्यक आहे), deepgram/nova-3 (मूळ Deepgram की आवश्यक आहे). केवळ deepgram/nova-3 विनंती OpenRouter वापरत नाही.

समर्थित स्वरूपे: mp3, wav, m4a, flac, ogg, webm.

Ollama सुसंगतता

Ollama चे API स्वरूप वापरणाऱ्या क्लायंटसाठी:

# चॅट एंडपॉइंट (Ollama स्वरूप)
POST /v1/api/chat

# मॉडेल सूची (Ollama स्वरूप)
GET /api/tags

विनंत्या Ollama आणि अंतर्गत स्वरूपांदरम्यान स्वयंचलितपणे रूपांतरित केल्या जातात.

टोकनयुक्त VS Code / हेडरविरहित उपनावे

जेव्हा एखादे इंटिग्रेशन Authorization हेडर अंतर्भूत करू शकत नाही आणि API की बेस URL मध्ये एम्बेड करणे आवश्यक असते, तेव्हा ही उपनावे वापरा.

# OpenAI-शैलीतील कॅटलॉग उपनाव
GET /api/v1/vscode/{token}/
GET /api/v1/vscode/{token}/models

# OpenAI-शैलीतील चॅट उपनावे
POST /api/v1/vscode/{token}/chat/completions
POST /api/v1/vscode/{token}/responses

# Ollama-शैलीतील उपनावे
POST /api/v1/vscode/{token}/api/chat
GET /api/v1/vscode/{token}/api/tags

उदाहरण:

curl https://your-host.example/api/v1/vscode/YOUR_API_KEY/models
curl -X POST https://your-host.example/api/v1/vscode/YOUR_API_KEY/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hello"}]}'

नोंदी:

  • टोकनयुक्त उपनावे /v1/* आणि /api/tags प्रमाणेच हँडलर्स पुन्हा वापरतात; प्रतिसादांची संरचना तशीच राहते.
  • क्लायंट कस्टम हेडर्सना समर्थन देत असेल, तेव्हा शक्यतो Authorization: Bearer ... वापरा.
  • URL-आधारित टोकन्स रिव्हर्स-प्रॉक्सी लॉग्स, ब्राउझर इतिहास आणि OmniRoute च्या बाहेरील टेलिमेट्रीमध्ये दिसू शकतात. त्यांना डीफॉल्ट प्रमाणीकरण पद्धत न मानता सुसंगतता पर्याय म्हणून वापरा.

टेलिमेट्री

# लेटन्सी टेलिमेट्रीचा सारांश मिळवा (प्रत्येक प्रदात्यासाठी p50/p95/p99)
GET /api/telemetry/summary

प्रतिसाद:

{
  "providers": {
    "claudeCode": { "p50": 245, "p95": 890, "p99": 1200, "count": 150 },
    "github": { "p50": 180, "p95": 620, "p99": 950, "count": 320 }
  }
}

बजेट

# सर्व API कीजसाठी बजेटची स्थिती मिळवा
GET /api/usage/budget

# बजेट सेट किंवा अपडेट करा
POST /api/usage/budget
Content-Type: application/json

{
  "apiKeyId": "key-123",
  "dailyLimitUsd": 5.00,
  "weeklyLimitUsd": 30.00,
  "monthlyLimitUsd": 100.00,
  "warningThreshold": 0.8,
  "resetInterval": "monthly"
}

स्कीमा नोंदी (setBudgetSchema): apiKeyId आवश्यक आहे; dailyLimitUsd, weeklyLimitUsd किंवा monthlyLimitUsd यांपैकी किमान एक शून्यापेक्षा जास्त असणे आवश्यक आहे. ऐच्छिक फील्ड्स: warningThreshold (0–1), resetInterval (daily | weekly | monthly), resetTime (HH:MM). जुनी {keyId, limit, period} संरचना 400 Bad Request परत करते.

टोकन मर्यादा

प्रत्येक API कीसाठी टोकन बजेट (वरील USD-आधारित बजेटपेक्षा वेगळे). विनंती मार्गावरच त्यांची अंमलबजावणी केली जाते: एखाद्या कीचा सध्याच्या कालावधीतील वापर तिच्या मर्यादेपर्यंत पोहोचल्यावर, विनंत्या 429 Too Many Requests सह नाकारल्या जातात. मर्यादा विशिष्ट model, provider यांच्यापुरत्या व्याप्त केल्या जाऊ शकतात किंवा संपूर्ण कीवर global पातळीवर लागू केल्या जाऊ शकतात; जेव्हा अनेक मर्यादा एखाद्या विनंतीशी जुळतात, तेव्हा सर्वाधिक प्रतिबंधात्मक मर्यादा लागू होते.

# कीच्या टोकन मर्यादांची यादी दाखवा (सध्याच्या कालावधीतील प्रत्यक्ष वापरासह)
GET /api/usage/token-limits?apiKeyId=key-123

# टोकन मर्यादा तयार करा किंवा अद्ययावत करा
POST /api/usage/token-limits
Content-Type: application/json

{
  "apiKeyId": "key-123",
  "scopeType": "model",
  "scopeValue": "openai/gpt-4o",
  "tokenLimit": 1000000,
  "resetInterval": "monthly",
  "enabled": true
}

# id नुसार टोकन मर्यादा हटवा
DELETE /api/usage/token-limits?id=tl-abc

स्कीमा नोंदी (setTokenLimitSchema): apiKeyId आणि scopeType (model | provider | global) आवश्यक आहेत. scopeType हे global नसल्यास scopeValue आवश्यक आहे (उदा. model व्याप्तीसाठी मॉडेल id, provider व्याप्तीसाठी प्रदाता id). tokenLimit हा धन पूर्णांक असणे आवश्यक आहे (स्ट्रिंगमधून रूपांतरित केला जातो). पर्यायी: id (तयार करण्यासाठी वगळा, अद्ययावत करण्यासाठी द्या), resetInterval (daily | weekly | monthly, डीफॉल्ट monthly), resetTime (HH:MM), enabled (डीफॉल्ट true). GET प्रतिसाद प्रत्येक मर्यादेला tokensUsed, remaining, windowStart, periodStartAt, आणि nextResetAt या माहितीसह समृद्ध करतात. हा व्यवस्थापन-वर्गातील एंडपॉइंट आहे (authz पाइपलाइनद्वारे प्रमाणीकरणाची अंमलबजावणी मध्यवर्ती पद्धतीने केली जाते).

विनंती प्रक्रिया

  1. क्लायंट /v1/* वर विनंती पाठवतो
  2. रूट हँडलर handleChat, handleEmbedding, handleAudioTranscription, किंवा handleImageGeneration कॉल करतो
  3. मॉडेलचे निराकरण केले जाते (थेट provider/model किंवा alias/combo)
  4. खात्याच्या उपलब्धतेनुसार फिल्टरिंग करून स्थानिक DB मधून क्रेडेन्शियल्स निवडली जातात
  5. चॅटसाठी: handleChatCore सिमॅंटिक/सिग्नेचर कॅश तपासतो आणि combo कॉम्प्रेशन सेटिंग्जचे निराकरण करतो
  6. सक्षम केलेले असताना प्रदाता रूपांतरणापूर्वी सक्रिय कॉम्प्रेशन चालते (lite, Caveman, RTK, किंवा त्यांचे एकत्रित स्टॅक)
  7. प्रदाता एक्झिक्युटर अपस्ट्रीम विनंती पाठवतो
  8. प्रतिसाद परत क्लायंटच्या स्वरूपात रूपांतरित केला जातो (चॅट) किंवा जसाच्या तसा परत केला जातो (एम्बेडिंग्ज/प्रतिमा/ऑडिओ)
  9. वापर, कॉम्प्रेशन विश्लेषण आणि विनंती लॉग नोंदवले जातात
  10. त्रुटी आल्यास combo नियमांनुसार फॉलबॅक लागू केला जातो

संपूर्ण आर्किटेक्चर संदर्भ: ARCHITECTURE.md

Combo व्यवस्थापन

उच्च-स्तरीय रूटिंग combos (/api/combos* अंतर्गत आधीच सारांशित केलेले) मॉडेल id पॅटर्नवरून 1:1 मॅपदेखील केले जाऊ शकतात, ज्यामुळे OpenAI-शैलीतील मॉडेल id चे combo कडे पारदर्शक पुनर्निर्देशन करता येते.

पद्धत पाथ वर्णन
GET /api/model-combo-mappings सर्व model→combo मॅपिंग्जची यादी दाखवा
POST /api/model-combo-mappings मॅपिंग तयार करा — बॉडी: {pattern, comboId, priority?, enabled?, description?}
GET /api/model-combo-mappings/[id] एक मॅपिंग मिळवा
PUT /api/model-combo-mappings/[id] विद्यमान मॅपिंगची फील्ड्स अद्ययावत करा
DELETE /api/model-combo-mappings/[id] मॅपिंग काढून टाका

प्रमाणीकरण: व्यवस्थापन सत्र/API की (requireManagementAuth).

वेबहुक्स

OmniRoute इव्हेंट्ससाठी आउटबाउंड वेबहुक सदस्यत्वे (विनंती पूर्ण होणे, कोटा संपणे, की रोटेशन इत्यादी).

पद्धत पाथ वर्णन
GET /api/webhooks वेबहुक्सची सूची दाखवा (सिक्रेट्स <prefix>... स्वरूपात मास्क केलेले असतात)
POST /api/webhooks वेबहुक तयार करा — बॉडी: {url, events?: ["*"], secret?, description?}
GET /api/webhooks/[id] वेबहुक मिळवा
PUT /api/webhooks/[id] url/events/secret/description अद्ययावत करा
DELETE /api/webhooks/[id] वेबहुक काढून टाका
POST /api/webhooks/[id]/test वेबहुक URL वर चाचणी पेलोड पाठवा आणि वितरण स्थिती परत करा

प्रमाणीकरण: व्यवस्थापन सत्र/API की (requireManagementAuth).

नोंदणीकृत कीज (स्वयं-व्यवस्थापन)

दैनंदिन/ताशी कोट्यांसह, बॅकिंग प्रदाता/खात्याच्या माध्यमातून API कीज जारी करण्यासाठी आणि रोटेट करण्यासाठी स्वयं-की व्यवस्थापन उपप्रणालीद्वारे वापरले जाते.

पद्धत पाथ वर्णन
GET /api/v1/registered-keys नोंदणीकृत कीजची सूची दाखवा (केवळ मास्क केलेला प्रिफिक्स)
POST /api/v1/registered-keys नवीन नोंदणीकृत की जारी करा — बॉडी: {name, provider?, accountId?, idempotencyKey?, expiresAt?, dailyBudget?, hourlyBudget?}. मूळ की फक्त एकदाच परत करते. कोटा नाकारल्यास 429 परत करते.
GET /api/v1/registered-keys/[id] नोंदणीकृत कीचा मेटाडेटा मिळवा (मूळ की सामग्री नाही)
DELETE /api/v1/registered-keys/[id] नोंदणीकृत की रद्द करा
POST /api/v1/registered-keys/[id]/revoke स्पष्ट रद्दीकरण एंडपॉइंट (DELETE प्रमाणेच परिणाम)

प्रमाणीकरण: Bearer API की (isAuthenticated). /v1/quotas/check आणि /v1/issues/report हे देखील पहा.

एजंट्स प्रोटोकॉल

OmniRoute वापरकर्त्यांच्या वतीने दूरस्थपणे कार्यान्वित केलेली क्लाउड एजंट कार्ये (Claude Code, Codex Cloud, OpenHands इ.).

पद्धत पथ वर्णन
GET /api/v1/agents/tasks कार्यांची यादी — पर्यायी ?provider=, ?status=, ?limit= (1–500, डीफॉल्ट 50)
POST /api/v1/agents/tasks कार्य तयार करा — CreateCloudAgentTaskSchema द्वारे मुख्य भागाचे प्रमाणीकरण (providerId, prompt, source, options?). कार्य आवरणासह 201 परत करते
DELETE /api/v1/agents/tasks?id=... कार्य हटवा
GET /api/v1/agents/tasks/[id] कार्य वाचा — external_id सेट केलेला असताना अपस्ट्रीम क्लाउड एजंटकडून स्थिती समकालिकपणे रिफ्रेश करते
POST /api/v1/agents/tasks/[id] विभेदित कृती: {action: "approve"}, {action: "message", message}, किंवा {action: "cancel"}
DELETE /api/v1/agents/tasks/[id] id नुसार विशिष्ट कार्य हटवा

प्रमाणीकरण: प्रत्येक पद्धतीसाठी व्यवस्थापन प्रमाणीकरण आवश्यक आहे (requireCloudAgentManagementAuth). v3.8.0 पूर्वी यांसाठी प्रमाणीकरण आवश्यक नव्हते — ब्रेकिंग बदलासाठी कमिट 588a0333 पहा.

# Claude Code क्लाउड कार्य तयार करा
curl -X POST http://localhost:20128/api/v1/agents/tasks \
  -H "Authorization: Bearer your-management-key" \
  -H "Content-Type: application/json" \
  -d '{"providerId":"claude-code-cloud","prompt":"Fix the failing test","source":{"repo":"...","branch":"..."}}'

व्यवस्थापन प्रॉक्सी

प्रदाता, खाती किंवा जागतिक स्तरावर नियुक्त करता येणारे आउटबाउंड HTTP(S)/SOCKS प्रॉक्सी.

पद्धत पथ वर्णन
GET /api/v1/management/proxies प्रॉक्सींची यादी (?id= सह एक प्रॉक्सी परत करते; ?id=&where_used=1 सह नियुक्ती आलेख परत करते)
POST /api/v1/management/proxies प्रॉक्सी तयार करा — createProxyRegistrySchema द्वारे मुख्य भागाचे प्रमाणीकरण
PATCH /api/v1/management/proxies प्रॉक्सी अद्ययावत करा — updateProxyRegistrySchema द्वारे मुख्य भागाचे प्रमाणीकरण (id आवश्यक)
DELETE /api/v1/management/proxies?id=...&force=1 प्रॉक्सी हटवा (नियुक्त्या विलग करण्यासाठी force=1 वापरा)
GET /api/v1/management/proxies/assignments नियुक्त्यांची यादी — proxy_id, scope, scope_id नुसार फिल्टर करता येते; कनेक्शनसाठी सक्रिय प्रॉक्सी शोधण्यासाठी resolve_connection_id=<id> पाठवा
PUT /api/v1/management/proxies/assignments नियुक्त करा — proxyAssignmentSchema द्वारे मुख्य भागाचे प्रमाणीकरण ({scope, scopeId?, proxyId?}). डिस्पॅचर कॅशे साफ करते
PUT /api/v1/management/proxies/bulk-assign मोठ्या प्रमाणात नियुक्त करा — bulkProxyAssignmentSchema द्वारे मुख्य भागाचे प्रमाणीकरण ({scope, scopeIds[], proxyId?})
GET /api/v1/management/proxies/health?hours=24 कालावधीत प्रॉक्सीची एकत्रित स्थिती (यशस्वी/अयशस्वी मोजणी, विलंब)

प्रमाणीकरण: प्रत्येक मार्गावर व्यवस्थापन सत्र/API की आवश्यक आहे (requireManagementAuth).

कार्याच्या वर्णनातील POST /api/v1/management/proxies/[id]/assignments आणि POST /api/v1/management/proxies/[id]/health हे वर दाखवलेल्या सपाट /assignments आणि /health मार्गांद्वारे हाताळले जातात — कोडबेसमध्ये प्रत्येक id साठी स्वतंत्र उपमार्ग नाहीत.

लवचिकता (विस्तारित)

OmniRoute तात्पुरत्या अपयशांसाठी तीन स्वतंत्र यंत्रणा उपलब्ध करून देते; खालील व्यवस्थापन एंडपॉइंट्स ऑपरेटर्सना त्यांची स्थिती वाचण्याची आणि ती अधिलिखित करण्याची सुविधा देतात:

व्याप्ती स्थिती संचयन वाचन रीसेट / साफ करणे
प्रदाता ब्रेकर domain_circuit_breakers + इन-मेमरी /api/monitoring/health POST /api/resilience/reset
कनेक्शन कूलडाउन प्रदाता कनेक्शन्सवरील rateLimitedUntil /api/rate-limits, /api/providers/[id] (आवश्यकतेनुसार पुन्हा सक्षम होते; प्रदात्याच्या PUT द्वारे साफ करा)
मॉडेल लॉकआउट इन-मेमरी मॉडेल-उपलब्धता रजिस्ट्री GET /api/resilience/model-cooldowns DELETE /api/resilience/model-cooldowns

PATCH /api/resilience, providerBreaker.oauth आणि providerBreaker.apikey अंतर्गत प्रदाता ब्रेकर अधिलिखने स्वीकारते. प्रत्येक प्रोफाइल degradationThreshold, failureThreshold, आणि resetTimeoutMs यांना समर्थन देते; हीच फील्ड्स Dashboard → Settings → Resilience मध्ये उपलब्ध आहेत.

# एका मॉडेलचा लॉकआउट साफ करा
curl -X DELETE http://localhost:20128/api/resilience/model-cooldowns \
  -H "Cookie: auth_token=..." \
  -H "Content-Type: application/json" \
  -d '{"provider":"openai","model":"gpt-4o-mini"}'

# सर्व लॉकआउट्स पूर्णपणे साफ करा
curl -X DELETE http://localhost:20128/api/resilience/model-cooldowns \
  -H "Cookie: auth_token=..." \
  -d '{"all":true}'

संपूर्ण संकल्पनात्मक संदर्भ आणि ब्रेकरची डीफॉल्ट मूल्ये: CLAUDE.md → "Resilience Runtime State" पहा.

कौशल्ये

सानुकूल एक्झिक्युटेबल हँडलर्सद्वारे OmniRoute चा विस्तार करण्यासाठी कौशल्य फ्रेमवर्क, तसेच मार्केटप्लेस इंटिग्रेशन्स.

पद्धत पथ वर्णन
GET /api/skills स्थापित कौशल्यांची यादी — ?q=, ?mode=on|off|auto, ?source=skillsmp|skillssh|local द्वारे फिल्टर करता येते, पृष्ठांकित
GET /api/skills/[id] एक कौशल्य मिळवा
PUT /api/skills/[id] कौशल्य अद्ययावत करा (नाव, वर्णन, मोड, स्कीमा, हँडलर, टॅग्स)
DELETE /api/skills/[id] कौशल्य विस्थापित करा
POST /api/skills/install रॉ मॅनिफेस्टमधून कौशल्य स्थापित करा — बॉडी: {name, version, description, schema:{input, output}, handlerCode, apiKeyId?}
GET /api/skills/executions अलीकडील कौशल्य एक्झिक्युशन्सची यादी (इनपुट्स/आउटपुट्स/कालावधीसह ऑडिट ट्रेल)
GET /api/skills/marketplace?q=... SkillsMP मार्केटप्लेसमधील शोध/लोकप्रिय यादी (skillsmpApiKey सेटिंग आवश्यक)
POST /api/skills/marketplace/install SkillsMP मधून id द्वारे कौशल्य स्थापित करा
GET /api/skills/skillssh?q=&limit= skills.sh रजिस्ट्रीमध्ये शोधा
POST /api/skills/skillssh/install skills.sh मधून id द्वारे कौशल्य स्थापित करा

प्रमाणीकरण: व्यवस्थापन सत्र/API की. मार्केटप्लेस शोध मार्ग व्यवस्थापन प्रमाणीकरण किंवा Bearer API की (isAuthenticated) स्वीकारतात.

मेमरी

API की / सत्रानुसार व्याप्ती असलेले कायमस्वरूपी संभाषणात्मक/तथ्यात्मक मेमरी स्टोअर.

पद्धत पथ वर्णन
GET /api/memory मेमरींची सूची — ?apiKeyId=, ?type=, ?sessionId=, ?q=, तसेच offset/limit किंवा page/limit पृष्ठांकन
POST /api/memory मेमरी तयार करा — Zod द्वारे प्रमाणित केलेली body: {content, key, type?, sessionId?, apiKeyId?, metadata?, expiresAt?}
GET /api/memory/[id] एक मेमरी मिळवा
DELETE /api/memory/[id] मेमरी हटवा
GET /api/memory/health मेमरी उपप्रणालीचे आरोग्य (DB कनेक्टिव्हिटी, embeddings backend, vector index स्थिती)

प्रमाणीकरण: व्यवस्थापन सत्र/API की (requireManagementAuth). type enum: FACTUAL, EPISODIC, SEMANTIC, PROCEDURAL (src/lib/memory/types.ts मधील MemoryType पाहा).

MCP सर्व्हर

OmniRoute मध्ये 3 transports (stdio, SSE, streamable-http) आणि व्याप्तीबद्ध साधनांसह अंतर्भूत Model Context Protocol सर्व्हर समाविष्ट आहे. खालील dashboard endpoints स्थिती/audit डेटा वाचतात आणि HTTP transports ना प्रॉक्सी करतात.

पद्धत पथ वर्णन
GET /api/mcp/status Heartbeat, transport, ऑनलाइन स्थिती, शेवटचा कॉल, प्रमुख साधने, 24 तासांचा यशाचा दर
GET /api/mcp/tools name, description, scopes, phase, auditLevel, sourceEndpoints सह MCP साधनांची सूची
GET /api/mcp/sse SSE transport साठी SSE stream उघडा (MCP अक्षम असल्यास किंवा transport जुळत नसल्यास 503 परत करतो)
POST /api/mcp/sse SSE transport वर JSON-RPC frame पाठवा
GET /api/mcp/stream Streamable HTTP transport ची SSE बाजू उघडा (सर्व्हरद्वारे सुरू केलेले संदेश)
POST /api/mcp/stream Streamable HTTP transport वर JSON-RPC frame पाठवा
DELETE /api/mcp/stream Streamable HTTP सत्र समाप्त करा
GET /api/mcp/audit audit log क्वेरी करा — ?limit=, ?offset=, ?tool=, `?success=true false, ?apiKeyId=`
GET /api/mcp/audit/stats एकत्रित audit आकडेवारी (एकूण संख्या, यशाचा दर, सरासरी कालावधी, प्रमुख साधने)

प्रमाणीकरण: sse/stream transports MCP-विशिष्ट प्रमाणीकरण पृष्ठभागाचा सन्मान करतात (mcp scope असलेली Bearer API की); status/tools/audit* routes dashboard वरून वाचता येतात (dashboard host पर्यंत पोहोचण्याव्यतिरिक्त कोणतेही अतिरिक्त प्रमाणीकरण आवश्यक नाही).

दोन्ही HTTP transports settings.mcpEnabled आणि settings.mcpTransport द्वारे नियंत्रित केले जातात — transport जुळत नसल्यास 400, तर MCP अक्षम स्थितीत 503 परत केले जाते.

A2A सर्व्हर

OmniRoute तपासणी/डॅशबोर्ड वापरासाठी REST रॅपरसह A2A (Agent-to-Agent) JSON-RPC 2.0 एंडपॉइंट उपलब्ध करून देते.

JSON-RPC

POST /a2a
Authorization: Bearer your-api-key   # OMNIROUTE_API_KEY सेट केलेले नसल्यास ऐच्छिक
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "message/send",
  "params": {
    "skill": "smart-routing",
    "messages": [{"role": "user", "content": "Route this coding task"}]
  }
}

समर्थित पद्धती (सर्व settings.a2aEnabled द्वारे नियंत्रित):

पद्धत वर्णन
message/send समकालिक कौशल्य अंमलबजावणी; {task, artifacts, metadata} परत करते
message/stream त्याच कौशल्य संचाची स्ट्रीमिंग SSE अंमलबजावणी
tasks/get taskId द्वारे कार्य मिळवा
tasks/cancel taskId द्वारे कार्य रद्द करा

अंगभूत कौशल्ये: smart-routing, quota-management, provider-discovery, cost-analysis, health-report.

एजंट कार्ड

GET /.well-known/agent.json

सार्वजनिक A2A एजंट कार्ड (नाव, वर्णन, क्षमता, कौशल्य कॅटलॉग, प्रमाणीकरण योजना) परत करते — 1 तासासाठी सार्वजनिकरीत्या कॅश केलेले. प्रमाणीकरण आवश्यक नाही.

REST सहाय्यक

पद्धत पथ वर्णन
GET /api/a2a/status A2A सक्षम स्थिती + कार्य आकडेवारी + कॅश केलेल्या एजंट कार्डचा सारांश
GET /api/a2a/tasks कार्यांची सूची — ?state=submitted|working|completed|failed|cancelled, ?skill=, ?limit= (≤200), ?offset=
POST /api/a2a/tasks (REST सहाय्यक म्हणून अंमलात आणलेले नाही — JSON-RPC message/send द्वारे तयार करा)
GET /api/a2a/tasks/[id] एक कार्य मिळवा
POST /api/a2a/tasks/[id]/cancel कार्य रद्द करा

प्रमाणीकरण: REST सहाय्यक व्यवस्थापन प्रमाणीकरणाशिवाय चालतात (डॅशबोर्डवर वाचण्यायोग्य); कॉन्फिगर केले असल्यास JSON-RPC /a2a मार्ग Bearer OMNIROUTE_API_KEY वापरतो.

क्लाउड, मूल्यमापन संच आणि मूल्यांकन

पद्धत पथ वर्णन
POST /api/cloud/auth Bearer की सत्यापित करा आणि क्लाउड सिंक क्लायंटसाठी मास्क केलेली प्रदाता कनेक्शने + मॉडेल उपनावे परत करा
POST /api/cloud/credentials/update क्लाउड-सिंक केलेल्या प्रदात्यासाठी एन्क्रिप्ट केलेली क्रेडेन्शियल्स अद्ययावत करा
POST /api/cloud/model/resolve स्थानिक रूटिंग तक्ता वापरून तार्किक मॉडेल आयडीचे ठोस प्रदाता/मॉडेलमध्ये निराकरण करा
GET /api/cloud/models/alias क्लाउड सिंकसमोर उपलब्ध केलेल्या मॉडेल उपनावांची सूची
GET /api/assess नवीनतम मूल्यांकन वर्गीकरणे वाचा (प्रति-प्रदाता/मॉडेल)
POST /api/assess मूल्यांकन चालवा — मुख्य भाग: `{scope: {type:"all"} {type:"provider", providerId} {type:"model", modelId}, trigger?}`
GET /api/evals अंगभूत मूल्यमापन संच + सर्वात अलीकडील रन यांची सूची
POST /api/evals मूल्यमापन रन सुरू करा
POST /api/evals/suites सानुकूल मूल्यमापन संच तयार करा — मुख्य भाग evalSuiteSaveSchema द्वारे सत्यापित केला जातो
GET /api/evals/suites/[id] सानुकूल मूल्यमापन संच मिळवा

प्रमाणीकरण: /api/cloud/auth थेट Bearer की सत्यापित करतो; इतर /api/cloud/*, /api/evals/*, आणि /api/assess मार्गांसाठी व्यवस्थापन सत्र/API की आवश्यक आहे. /api/assess POST भेदाधारित-युनियन व्याप्ती स्कीमासह validateBody वापरतो.

ACP (Agent Client Protocol) व्यवस्थापन

चाइल्ड प्रोसेसेस म्हणून. हे एंडपॉइंट्स ACP एजंट शोध आणि कस्टम एजंट नोंदणी व्यवस्थापित करतात.

पद्धत पाथ वर्णन
GET /api/acp/agents इंस्टॉलेशन स्थिती, आवृत्ती आणि बायनरीसह सर्व ज्ञात CLI एजंट्सची (अंगभूत + कस्टम) यादी
POST /api/acp/agents कस्टम ACP एजंटची नोंदणी करा किंवा कॅशे रिफ्रेश करा — बॉडी: {id, name, binary, versionCommand, providerAlias, spawnArgs, protocol} किंवा {action: "refresh"}
DELETE /api/acp/agents कस्टम ACP एजंट काढून टाका — क्वेरी पॅरामीटर: ?id=<agentId>

प्रतिसादाचे उदाहरण (GET /api/acp/agents):

{
  "agents": [
    {
      "id": "claude",
      "name": "Claude Code CLI",
      "binary": "claude",
      "version": "1.0.45",
      "installed": true,
      "protocol": "stdio",
      "providerAlias": "claude",
      "isCustom": false
    },
    {
      "id": "my-custom-cli",
      "name": "My Custom CLI",
      "installed": false,
      "protocol": "stdio",
      "providerAlias": "my-provider",
      "isCustom": true
    }
  ],
  "cacheTtlMs": 60000,
  "cacheAge": 1234
}

प्रमाणीकरण: व्यवस्थापन सत्र (डॅशबोर्ड auth_token कुकी) किंवा व्यवस्थापन-व्याप्ती असलेली API की आवश्यक आहे.

संपूर्ण तपशीलांसाठी ACP फ्रेमवर्क पहा.

विश्लेषण आणि निरीक्षणक्षमता

राउटिंग, कॉम्प्रेशन आणि प्रोव्हायडर विविधतेचे निरीक्षण करण्यासाठी रिअल-टाइम विश्लेषण एंडपॉइंट्स. हे /dashboard/analytics/* पृष्ठांना कार्यान्वित करतात.

स्वयंचलित-राउटिंग विश्लेषण

पद्धत पाथ वर्णन
GET /api/analytics/auto-routing एकत्रित स्वयंचलित-राउटिंग आकडेवारी: एकूण कॉल्स, धोरण वितरण, टियर वितरण, प्रमुख प्रोव्हायडर्स
GET /api/analytics/auto-routing?days=7 कालमर्यादित आकडेवारी (डीफॉल्ट 24h)

प्रतिसादाचे उदाहरण:

{
  "window": "24h",
  "totalCalls": 1234,
  "strategyBreakdown": {
    "rules": 800,
    "cost": 200,
    "latency": 150,
    "sla-aware": 50,
    "lkgp": 34
  },
  "tierBreakdown": {
    "ultra": 100,
    "pro": 500,
    "standard": 400,
    "free": 234
  },
  "topProviders": [
    { "provider": "openai", "calls": 500, "avgLatencyMs": 850 },
    { "provider": "anthropic", "calls": 300, "avgLatencyMs": 1200 }
  ]
}

कॉम्प्रेशन विश्लेषण

पद्धत पाथ वर्णन
GET /api/analytics/compression एकत्रित कॉम्प्रेशन आकडेवारी: वाचवलेले टोकन्स, बचत %, मोड वितरण, इंजिन वापर

प्रतिसादाचे उदाहरण:

{
  "window": "24h",
  "totalOriginalTokens": 5000000,
  "totalCompressedTokens": 3500000,
  "totalSavings": 1500000,
  "savingsPct": 30.0,
  "modeBreakdown": {
    "lite": 400,
    "standard": 600,
    "aggressive": 100,
    "ultra": 50,
    "rtk": 84
  },
  "engineBreakdown": {
    "caveman": 800,
    "rtk": 434
  }
}

प्रोव्हायडर विविधता ट्रॅकिंग

पद्धत पाथ वर्णन
GET /api/analytics/diversity Shannon entropy-आधारित विविधता ट्रॅकिंग: प्रोव्हायडर प्रसार मोजून एकल अपयशबिंदूंना प्रतिबंधित करते

प्रतिसादाचे उदाहरण:

{
  "window": "24h",
  "shannonEntropy": 2.45,
  "maxEntropy": 3.17,
  "diversityRatio": 0.77,
  "providerUsage": {
    "openai": 0.4,
    "anthropic": 0.25,
    "google": 0.2,
    "kiro": 0.15
  },
  "warnings": ["OpenAI accounts for 40% of traffic — consider diversifying"]
}

प्रमाणीकरण: व्यवस्थापन सत्र किंवा व्यवस्थापन-व्याप्ती असलेली API की आवश्यक आहे.

प्रशासकीय ऑपरेशन्स

ऑपरेशनल व्यवस्थापनासाठी केवळ प्रशासकांसाठी असलेले एंडपॉइंट्स.

पद्धत पथ वर्णन
GET /api/admin/concurrency सध्याच्या समकालिकता मर्यादा वाचा (जागतिक + प्रत्येक प्रदात्यानुसार)
POST /api/admin/concurrency समकालिकता मर्यादा अद्ययावत करा — बॉडी: {global?: number, perProvider?: Record<string, number>}

प्रमाणीकरण: प्रशासक व्याप्ती असलेले व्यवस्थापन सत्र आवश्यक आहे.

CLI साधनांचे व्यवस्थापन

OmniRoute सोबत एकात्मीकृत होणारी CLI साधने (antigravity, chipotle, commandCode, devin-cli इ.) व्यवस्थापित करा. संपूर्ण यादीसाठी प्रदाता संदर्भ पहा.

पद्धत पथ वर्णन
GET /api/cli-tools/all-statuses सर्व CLI साधनांची स्थिती (स्थापित, आवृत्ती, शेवटचे आढळले तेव्हाची वेळ)
GET /api/cli-tools/status एका CLI साधनासाठी स्थितीचा तपशील (?tool= क्वेरी)
POST /api/cli-tools/apply साधनाचे व्युत्पन्न केलेले कॉन्फिगरेशन लिहा (dryRun पूर्वावलोकन करते; कंटेनरमध्ये असल्यास 422 + containerEphemeralTarget; migration लेगसी Codex YAML ची नोंद करते)
GET /api/cli-tools/backups CLI साधनांच्या कॉन्फिगरेशन बॅकअपची यादी करा
POST /api/cli-tools/backups सर्व CLI साधनांच्या कॉन्फिगरेशनचा बॅकअप तयार करा
POST /api/cli-tools/backups पुनर्संचयित करा: बॉडीमध्ये {tool, backupId} देऊन त्याच एंडपॉइंटद्वारे तो बॅकअप पुनर्संचयित केला जातो
GET /api/cli-tools/antigravity-mitm Antigravity MITM प्रॉक्सीची स्थिती ("antigravity-mitm" CLI साधन)
POST /api/cli-tools/antigravity-mitm/alias antigravity-mitm उपनाम कॉन्फिगर करा

प्रमाणीकरण: व्यवस्थापन सत्र आवश्यक आहे.

एजंट कौशल्ये

AI एजंट कौशल्ये व्यवस्थापित करा (OpenAI च्या सानुकूल GPTs प्रमाणे, पण एजंटसाठी).

पद्धत पथ वर्णन
GET /api/agent-skills सर्व एजंट कौशल्यांची यादी करा (अंगभूत + सानुकूल)
GET /api/agent-skills/[id] विशिष्ट एजंट कौशल्य मिळवा
POST /api/agent-skills सानुकूल एजंट कौशल्य तयार करा — बॉडी: {name, description, prompt, model?, temperature?}
PUT /api/agent-skills/[id] सानुकूल एजंट कौशल्य अद्ययावत करा
DELETE /api/agent-skills/[id] सानुकूल एजंट कौशल्य हटवा
GET /api/agent-skills/[id]/raw मूळ प्रॉम्प्ट + मेटाडेटा मिळवा (अंमलबजावणीशिवाय)
POST /api/agent-skills/generate नैसर्गिक भाषेतील वर्णनावरून AI वापरून नवीन कौशल्य व्युत्पन्न करा

प्रमाणीकरण: व्यवस्थापन सत्र किंवा व्यवस्थापन-व्याप्त API की आवश्यक आहे.

कॅशे व्यवस्थापन

सिमॅंटिक कॅशे आणि रीझनिंग कॅशे व्यवस्थापित करा.

पद्धत पथ वर्णन
GET /api/cache कॅशेचा आढावा: एकूण नोंदी, हिट दर, डिस्कवरील आकार
GET /api/cache/entries कॅशे केलेल्या नोंदींची सूची (पृष्ठांकनासह)
DELETE /api/cache/entries कॅशे नोंदी हटवा (क्वेरी पॅरामीटर्सनुसार फिल्टर करा)
GET /api/cache/stats कॅशेची तपशीलवार आकडेवारी (प्रत्येक प्रदात्यानुसार, प्रत्येक मॉडेलनुसार)
GET /api/cache/reasoning रीझनिंग कॅशेची स्थिती (रीझनिंग रिप्लेसाठी)
DELETE /api/cache/reasoning रीझनिंग कॅशे साफ करा — क्वेरी पॅरामीटर्स: ?toolCallId=<id> (एकल) किंवा ?provider=<p> किंवा पॅरामीटर्स नाहीत (सर्व)

प्रमाणीकरण: व्यवस्थापन सत्र आवश्यक आहे.

मेमरी प्रणाली

सततची मेमरी (FTS5 + व्हेक्टर एम्बेडिंग्ज) व्यवस्थापित करा.

पद्धत पथ वर्णन
GET /api/memory मेमरी नोंदींची सूची (स्कोप, प्रकार, शोध क्वेरीनुसार फिल्टर करा)
POST /api/memory नवीन मेमरी नोंद तयार करा — बॉडी: {scope, type, content, metadata?}
GET /api/memory/[id] विशिष्ट मेमरी नोंद मिळवा
PUT /api/memory/[id] मेमरी नोंद अद्ययावत करा
DELETE /api/memory/[id] मेमरी नोंद हटवा
GET /api/memory?q= मेमरी शोधा (FTS5 + व्हेक्टर) — त्याच प्रतिसादामध्ये आकडेवारी समाविष्ट केली जाते

प्रमाणीकरण: व्यवस्थापन सत्र किंवा व्यवस्थापन-स्कोप असलेली API की आवश्यक आहे.

वेबहुक्स

इव्हेंट्ससाठी वेबहुक सदस्यत्वे व्यवस्थापित करा.

पद्धत पथ वर्णन
GET /api/webhooks सर्व वेबहुक सदस्यत्वांची सूची
POST /api/webhooks वेबहुक सदस्यत्व तयार करा — बॉडी: {url, events[], secret?, active?}
GET /api/webhooks/[id] विशिष्ट वेबहुक सदस्यत्व मिळवा
PUT /api/webhooks/[id] वेबहुक सदस्यत्व अद्ययावत करा
DELETE /api/webhooks/[id] वेबहुक सदस्यत्व हटवा
GET /api/webhooks/[id]/deliveries वेबहुकसाठी वितरण इतिहासाची सूची (यशस्वी/अयशस्वी लॉग)
POST /api/webhooks/[id]/test वेबहुकला चाचणी इव्हेंट पाठवा

प्रमाणीकरण: व्यवस्थापन सत्र आवश्यक आहे.

सर्व इव्हेंट प्रकारांसाठी वेबहुक्स फ्रेमवर्क पहा.

कौशल्य फ्रेमवर्क

कौशल्ये (एजंटिक विस्तार फ्रेमवर्क) व्यवस्थापित करा.

पद्धत पथ वर्णन
GET /api/skills स्थापित केलेल्या सर्व कौशल्यांची सूची (अंगभूत + सानुकूल)
POST /api/skills/install स्थानिक पथ किंवा URL वरून कौशल्य स्थापित करा
DELETE /api/skills/[id] कौशल्य विस्थापित करा
PUT /api/skills/[id] कौशल्य सक्षम किंवा अक्षम करा — मुख्य भाग: {enabled?: boolean, mode?: "on" | "off" | "auto"}
POST /api/skills/executions कौशल्य कार्यान्वित करा — मुख्य भाग: {skillName, apiKeyId, input?, sessionId?}
GET /api/skills/executions सर्व कौशल्यांचा कार्यान्वयन इतिहास सूचीबद्ध करा (?apiKeyId= नुसार फिल्टर करा)

प्रमाणीकरण: व्यवस्थापन सत्र किंवा व्यवस्थापन-व्याप्ती असलेली API की आवश्यक आहे.

संपूर्ण तपशीलांसाठी कौशल्य फ्रेमवर्क पहा.

प्लगइन

OmniRoute प्लगइन (तृतीय-पक्ष विस्तार) व्यवस्थापित करा.

पद्धत पथ वर्णन
GET /api/plugins स्थापित प्लगइनची सूची
POST /api/plugins/marketplace/install मार्केटप्लेसमधून प्लगइन स्थापित करा
DELETE /api/plugins/[name] प्लगइन विस्थापित करा
POST /api/plugins/[name]/activate प्लगइन सक्रिय करा
POST /api/plugins/[name]/deactivate प्लगइन निष्क्रिय करा
GET /api/plugins/[name]/config प्लगइन कॉन्फिगरेशन मिळवा
PUT /api/plugins/[name]/config प्लगइन कॉन्फिगरेशन अद्ययावत करा

प्रमाणीकरण: व्यवस्थापन सत्र आवश्यक आहे.

संपूर्ण तपशीलांसाठी प्लगइन फ्रेमवर्क पहा.

शॅडो राउटिंग

प्रदात्यांची शॅडो / A-B तुलना ही स्वतंत्र REST पृष्ठभाग नाही — ती कॉम्बो राउटिंगद्वारे कॉन्फिगर केली जाते (ऑटो-कॉम्बो पहा). प्रत्येक कॉम्बोसाठीची तुलना मेट्रिक्स GET /api/combos/metrics द्वारे उपलब्ध केली जातात.

गार्डरेल्स

रनटाइम गार्डरेल्सची (PII शोध, प्रॉम्प्ट इंजेक्शन शोध, व्हिजन ब्रिजिंग) तपासणी करा. गार्डरेल्स प्रत्येक विनंतीवर चालतात; प्रत्येक कॉलसाठी वगळण्याचा पर्याय x-omniroute-disabled-guardrails विनंती हेडरद्वारे उपलब्ध आहे — कायमस्वरूपी सक्षम/अक्षम करण्यासाठी कोणताही पृष्ठभाग नाही.

पद्धत पथ वर्णन
GET /api/guardrails नोंदणीकृत गार्डरेल्स आणि त्यांची स्थिती (नाव / सक्षम / प्राधान्य) सूचीबद्ध करा
POST /api/guardrails/test नमुना इनपुटवर प्री-कॉल पाइपलाइनची ड्राय-रन चाचणी करा — मुख्य भाग: {input, disabledGuardrails?}

प्रमाणीकरण: व्यवस्थापन सत्र आवश्यक आहे.

संपूर्ण तपशीलांसाठी सुरक्षा > गार्डरेल्स पहा.

प्रमाणीकरण

चार क्रेडेन्शियल प्रकारांसाठी (डॅशबोर्ड सत्र, स्थानिक CLI टोकन, oma_live_… Access Token, व्यवस्थापन-व्याप्ती असलेली API की) आणि ते इन्फरन्स कींपेक्षा कसे वेगळे आहेत हे जाणून घेण्यासाठी व्यवस्थापन प्रमाणीकरण पहा.

  • डॅशबोर्ड मार्ग (/dashboard/*) auth_token कुकी वापरतात
  • लॉगिन जतन केलेला पासवर्ड हॅश वापरते; उपलब्ध नसल्यास INITIAL_PASSWORD वापरला जातो
  • requireLogin हे /api/settings/require-login द्वारे बदलता येते
  • REQUIRE_API_KEY=true असताना /v1/* मार्गांना पर्यायाने Bearer API की आवश्यक असते
  • या संदर्भातील "व्यवस्थापन टोकन" / "व्यवस्थापन-व्याप्ती असलेली API की" म्हणजे त्या मार्गदर्शिकेतील प्रकारांपैकी एक — कोणताही अपरिभाषित अतिरिक्त गुप्त प्रकार नव्हे

ब्रेकिंग बदल (v3.8.0) — /api/v1/agents/tasks/* आणि कूलडाउन व्यवस्थापन एंडपॉइंट्सना आता व्यवस्थापन प्रमाणीकरण (डॅशबोर्ड auth_token कुकी किंवा व्यवस्थापन-व्याप्ती असलेली API की) आवश्यक आहे. पूर्वी प्रमाणीकरणाशिवाय हे मार्ग कॉल करणाऱ्या क्लायंटना 401 Unauthorized प्रतिसाद मिळेल. कमिट 588a0333 (fix(auth): require management auth for agent and cooldown APIs) पहा.

Reference in New Issue View Git Blame Copy Permalink