त्रुटियाँ

त्रुटियाँ आपके द्वारा कॉल किए गए endpoint के लिए एनवेलप का उपयोग करती हैं। /v1/responses और /v1/chat/completions OpenAI-आकार की त्रुटियाँ लौटाते हैं। /v1/messages Anthropic-आकार की त्रुटियाँ लौटाते हैं। /v1/interactions Google-आकार की त्रुटियाँ लौटाते हैं। FlexInference त्रुटियाँ और अपस्ट्रीम प्रदाता त्रुटियाँ एक ही नियम का पालन करती हैं, इसलिए प्रत्येक endpoint का एक ही त्रुटि आकार होता है। 5xx त्रुटियाँ या timeouts दिख रहे हैं? सबसे पहले status.flexinference.com देखें। यह API, वेबसाइट, docs और MCP सर्वर के लिए लाइव अपटाइम, साथ ही किसी भी खुली घटना को दिखाता है। /v1/responses और /v1/chat/completions पर, त्रुटियाँ OpenAI एनवेलप का उपयोग करती हैं:

{
  "error": {
    "message": "The API key on this request was rejected - either it does not match FlexInference's key format (`flex_live_` followed by 24 hex characters and a 6-hex checksum), or it is well-formed but does not match any key on record. Copy the exact, current key from the FlexInference dashboard under Settings -> API keys, then send it as `Authorization: Bearer <key>`.",
    "type": "authentication_error",
    "code": "invalid_api_key",
    "param": null,
    "doc_url": "https://docs.flexinference.com/errors#invalid_api_key"
  }
}

/v1/messages पर वही त्रुटि Anthropic के आकार का उपयोग करती है। /v1/interactions पर, यह Google के आकार का उपयोग करती है:

{
  "type": "error",
  "error": { "type": "authentication_error", "message": "..." }
}

{ "error": { "code": 401, "message": "...", "status": "UNAUTHENTICATED" } }

HTTP status और message सभी सतहों पर समान रहते हैं; केवल wrapper बदलता है। OpenAI एनवेलप में पूरी जानकारी होती है। type OpenAI श्रेणियों (invalid_request_error, authentication_error, rate_limit_error) का उपयोग करता है, साथ ही आंतरिक दोषों के लिए flexinference_error और जब बिलिंग स्थिति बिल योग्य अनुरोधों को रोकती है तो billing_error का उपयोग करता है। code मशीन-पठनीय कारण है। param उस आपत्तिजनक field का नाम बताता है जब कोई लागू होता है। doc_url नीचे उस code की पंक्ति से लिंक करता है, या अज्ञात होने पर null होता है। Anthropic आकार में status से मैप किया गया एक Anthropic type और message होता है। Google आकार में संख्यात्मक code, message और एक canonical status होता है। FlexInference-विशिष्ट code और doc_url केवल OpenAI एनवेलप पर दिखाई देते हैं।

FlexInference कोड

ये कोड FlexInference से आते हैं। error.code पर ब्रांच करें; error.message डेवलपर्स के लिए लिखा गया है और इसमें समाधान भी शामिल है, यदि कोई मौजूद है। कई त्रुटियों में start_within शामिल है। flex-सक्षम मॉडल पर अवधि मानों के लिए, FlexInference पहले सस्ते flex tier को आज़माता है। यदि flex उस विंडो के भीतर शुरू नहीं हो पाता है, तो FlexInference उसी अनुरोध को standard tier पर भेजता है। Standard एक बैकअप पथ है, न कि पहला प्रयास।

स्थिति	कोड	अर्थ
`401`	`missing_api_key`	कोई `Authorization` header नहीं है, या मान `Bearer <key>` नहीं है। `Authorization: Bearer <your key>` भेजें।
`401`	`invalid_api_key`	key FlexInference के format (`flex_live_` + 24 hex chars + 6-hex checksum) से मेल नहीं खाती है, या यह format से मेल खाती है लेकिन अज्ञात है क्योंकि इसे रद्द कर दिया गया था, पुनर्जीवित किया गया था, या गलत टाइप किया गया था। dashboard से वर्तमान key कॉपी करें।
`429`	`rate_limit_exceeded`	अनुरोध इनमें से किसी एक सीमा तक पहुँच गया: आपके client IP से विफल-प्रमाणीकरण प्रयास, एक key या client IP से अनुरोध, आपके संगठन से अनुरोध, या बिल योग्य-flex concurrency leases। बिल योग्य-flex concurrency limiter डिफ़ॉल्ट रूप से 20 इन-फ़्लाइट अनुरोधों पर सेट होता है। `Retry-After` में सेकंड के लिए प्रतीक्षा करें, आमतौर पर auth-flood limiter के लिए 60s और अन्य अनुरोध limiters के लिए 5s।
`402`	`payment_required`	इस संगठन का बकाया शेष है या कोई payment method फ़ाइल में नहीं है, इसलिए बिल योग्य flex अनुरोध रोक दिए गए हैं। Free routing (`default`, `priority`, `auto`) और सभी Anthropic tier अनुरोध काम करते रहते हैं। dashboard के Billing पेज पर एक कार्ड जोड़ें या अपडेट करें, फिर पुनः प्रयास करें। यह `type: billing_error` वाला एकमात्र कोड है।
`413`	`request_too_large`	अनुरोध body FlexInference की 1,000,000-byte सीमा से अधिक है, जिसकी जाँच घोषित `Content-Length` और वास्तव में streamed bytes दोनों के विरुद्ध की जाती है। बड़ी inline base64 फ़ाइलें इसका सामान्य कारण हैं। payload को छोटा करें, या इसके बजाय एक hosted URL पर इंगित करें।
`400`	`no_byok_key`	आपके संगठन के लिए कोई OpenAI key कॉन्फ़िगर नहीं की गई है। dashboard में Settings -> API keys के तहत एक जोड़ें। BYOK keys एन्क्रिप्टेड संग्रहीत की जाती हैं; यदि एक संग्रहीत key मौजूद है लेकिन decrypt नहीं हो सकती है, तो अनुरोध `500 internal_error` के रूप में विफल हो जाता है, न कि इस कोड के रूप में। `provider` chain में आपके द्वारा नामित प्रत्येक route को अपनी key की आवश्यकता होती है: एक गुम key एक कॉन्फ़िगरेशन त्रुटि है, न कि एक क्षणिक विफलता, इसलिए इसे किसी भी upstream कॉल से पहले अस्वीकार कर दिया जाता है और यह कभी भी अगले route पर नहीं जाता है।
`400`	`no_gemini_key`	`no_byok_key` के समान, `gemini-*` मॉडल के लिए: आपके संगठन के लिए कोई Gemini key कॉन्फ़िगर नहीं की गई है। dashboard में एक जोड़ें।
`400`	`no_anthropic_key`	`no_byok_key` के समान, `claude-*` मॉडल के लिए: आपके संगठन के लिए कोई Anthropic key कॉन्फ़िगर नहीं की गई है। dashboard में एक जोड़ें।
`400`	`no_bedrock_key`	`no_byok_key` के समान, `provider` chain में `bedrock` route के लिए: आपके संगठन के लिए कोई Bedrock key कॉन्फ़िगर नहीं की गई है। Bedrock आपके स्वयं के key का उपयोग करके Amazon Bedrock के माध्यम से `claude-*` मॉडल प्रदान करता है; dashboard में Settings -> API keys के तहत एक जोड़ें। chain में कहीं भी एक `bedrock` प्रविष्टि को key की आवश्यकता होती है, इसलिए किसी भी upstream कॉल से पहले एक गुम key को अस्वीकार कर दिया जाता है।
`400`	`no_vertex_key`	`no_byok_key` के समान, `provider` chain में `vertex` route के लिए: आपके संगठन के लिए कोई Vertex key कॉन्फ़िगर नहीं की गई है। Vertex आपके स्वयं के express key (`AQ.` prefix) का उपयोग करके Google Vertex AI के माध्यम से `gemini-*` मॉडल प्रदान करता है; dashboard में Settings -> API keys के तहत एक जोड़ें। chain में कहीं भी एक `vertex` प्रविष्टि को key की आवश्यकता होती है, इसलिए किसी भी upstream कॉल से पहले एक गुम key को अस्वीकार कर दिया जाता है।
`400`	`missing_model`	`model` field गुम है, खाली है, या एक string नहीं है। एक गैर-खाली string जोड़ें, उदाहरण के लिए `"model": "gpt-5.5"`।
`400`	`missing_start_within`	आवश्यक `start_within` field गुम है, और कोई default लागू नहीं किया गया है। `start_within` यह निर्धारित करता है कि आप अनुरोध के शुरू होने के लिए कितनी देर प्रतीक्षा करने को तैयार हैं। `default`, `priority`, `auto`, या `HHh-MMm-SSs` जैसी अवधि का उपयोग करें, उदाहरण के लिए तीस सेकंड तक प्रतीक्षा करने के लिए `00h-00m-30s`।
`400`	`invalid_start_within`	`start_within` एक string नहीं है, चार स्वीकृत रूपों में से किसी एक से मेल नहीं खाता है, या अवधि के लिए 5-सेकंड से 600-सेकंड (10 मिनट) की अनुमत विंडो के बाहर हल होता है। सटीक आकार से मेल खाएं और अवधि को 5s-600s के भीतर रखें। उदाहरण के लिए, तीस-सेकंड की विंडो के लिए `"start_within": "00h-00m-30s"` का उपयोग करें, या flex race को छोड़ने के लिए `"start_within": "default"` का उपयोग करें।
`400`	`auto_unsupported_for_gemini`	Gemini मॉडल पर `start_within: "auto"` का उपयोग किया गया था। Gemini के tiers केवल `flex`, `standard`, और `priority` हैं; हल करने के लिए कोई `auto` नहीं है। इसके बजाय `default`, `priority`, या एक अवधि का उपयोग करें।
`400`	`flex_unsupported_for_anthropic`	एक अवधि `start_within` (flex race) को `claude-*` मॉडल पर भेजा गया था, लेकिन Anthropic के पास प्रतिस्पर्धा करने के लिए कोई flex tier नहीं है। FlexInference अब अनुपयुक्त flex race के लिए चुपचाप standard प्रदान नहीं करता है। एक tier `start_within` (`default`, `priority`, `auto`) का उपयोग करें या इसे छोड़ दें।
`400`	`flex_model_not_capable`	एक अवधि `start_within` को एक OpenAI या Gemini मॉडल पर भेजा गया था जो flex allow-list पर नहीं है। एक tier `start_within` का उपयोग करें या एक flex-सक्षम मॉडल चुनें।
`400`	`service_tier_not_allowed`	अनुरोध में `service_tier` शामिल था। FlexInference `start_within` से tier प्राप्त करता है; caller-supplied `service_tier` को स्वीकार करने के लिए इसे overwrite करने की आवश्यकता होगी, इसलिए router field को अस्वीकार कर देता है। `service_tier` को हटा दें और `start_within` के माध्यम से वही इरादा व्यक्त करें। यह `/v1/interactions` और `/v1/messages` पर भी लागू होता है।
`400`	`unsupported_parameter`	एक provider-native parameter को एक अलग provider पर भेजा गया था, या एक canonical Responses field का लक्ष्य provider के लिए कोई mapping नहीं है। Chat-native parameters OpenAI मॉडल पर पास होते हैं लेकिन Gemini या Claude मॉडल पर विफल होते हैं। Anthropic-native parameters Claude मॉडल पर पास होते हैं लेकिन OpenAI या Gemini मॉडल पर विफल होते हैं, सिवाय `document` और `file` content blocks के base64 स्रोतों के साथ, जो हर provider में translate होते हैं। `cache_control`, citations, और अन्य provider-native params अभी भी cross-provider विफल होते हैं। नामित field को हटा दें या एक ऐसा मॉडल चुनें जिसका provider उसका मालिक हो; `error.param` ठीक उसी का नाम बताता है। SDKs देखें।
`400`	`unsupported_generation_config`	`/v1/interactions` पर, एक गैर-mapped `generation_config.*` field को एक गैर-Gemini मॉडल को लक्षित करते समय सेट किया गया था। Gemini-native अतिरिक्त keys Gemini मॉडल पर पास होती हैं। नामित field को हटा दें या एक Gemini मॉडल को लक्षित करें।
`400`	`unsupported_tool`	`tools` array में एक built-in tool शामिल है जो मॉडल को गैर-text आउटपुट उत्सर्जित करता है, वर्तमान में `image_generation`। FlexInference हर endpoint पर केवल text आउटपुट प्रदान करता है। उस tool प्रविष्टि को हटा दें; function tools और `web_search` समर्थित रहते हैं।
`400`	`unsupported_value`	Chat Completions `n` को `1` के अलावा कुछ और पर सेट किया गया था। अंतर्निहित Responses API हमेशा एक एकल generation उत्पन्न करता है, इसलिए `n` `1` होना चाहिए या छोड़ा जाना चाहिए। उदाहरण के लिए, `"n": 1` भेजें या `n` को छोड़ दें।
`400`	`invalid_json`	body सिंटैक्टिक रूप से वैध JSON नहीं है (`JSON.parse` विफल रहा)। syntax को ठीक करें; एक trailing comma या unquoted key एक सामान्य कारण है।
`400`	`invalid_body`	body को JSON के रूप में parse किया गया, लेकिन top-level मान एक JSON object नहीं है। Arrays, strings, numbers, booleans, और null अमान्य हैं। अपने fields को एक एकल `{...}` object में लपेटें।
`400`	`invalid_stream`	`stream` field एक JSON boolean होना चाहिए। FlexInference एक गैर-boolean मान को coerce नहीं करेगा, जिसमें string `"true"` भी शामिल है, क्योंकि यह गलत response mode चुन सकता है। `stream` को एक वास्तविक boolean के रूप में भेजें, उदाहरण के लिए `"stream": true`, या गैर-streamed response के लिए इसे छोड़ दें।
`400`	`invalid_retry`	`retry` मान अमान्य है। `retry` एक object `{ count, backoff?, jitter? }` है जहाँ `count` 1 से 5 तक का एक पूर्णांक है (कितनी बार FlexInference एक क्षणिक 429 या 5xx पर upstream tier को पुनः हिट करता है), `backoff` `"exponential"` या `"linear"` है, और `jitter` एक boolean है। यह एक कोड एक गुम या out-of-range `count`, एक खराब `backoff` मान, एक गैर-boolean `jitter`, और किसी भी अज्ञात sub-key को कवर करता है। field को सही करें या हटा दें, उदाहरण के लिए `"retry": {"count": 2}`। Retry केवल response commit होने से पहले settled tier को पुनः हिट करता है; यह पहले byte, एक auth विफलता, या एक client 4xx के बाद कभी भी retry नहीं करता है।
`400`	`invalid_provider_chain`	वैकल्पिक `provider` array गलत तरीके से बना है: एक array नहीं, खाली, एक अज्ञात route नाम, एक duplicate, या तीन से अधिक प्रविष्टियाँ। प्रत्येक प्रविष्टि `google`, `openai`, `anthropic`, `vertex`, या `bedrock` में से एक होनी चाहिए; element 0 प्राथमिक route है और बाकी क्रमबद्ध same-model fallback chain हैं। मॉडल के native route का उपयोग करने के लिए `provider` को छोड़ दें, या array को सही करें, उदाहरण के लिए `["google", "vertex"]`। एक कोड हर गलत-श्रृंखला कारण को कवर करता है, जैसे `invalid_retry`; `error.message` विशिष्ट दोष का नाम बताता है।
`400`	`provider_model_mismatch`	`provider` chain में एक route अनुरोधित मॉडल को सेवा नहीं दे सकता है। प्रत्येक route एक मॉडल परिवार को सेवा देता है: `openai` GPT और o-series मॉडल को सेवा देता है, `google` और `vertex` Gemini को सेवा देते हैं, और `anthropic` और `bedrock` Claude को सेवा देते हैं। उस route को हटा दें जो इस मॉडल से मेल नहीं खाता है, या अनुरोध को एक ऐसे मॉडल पर भेजें जिसे वह route सेवा दे सकता है, उदाहरण के लिए `claude-*` मॉडल के लिए `["anthropic"]`।
`400`	`flex_unsupported_on_cloud`	एक अवधि `start_within` (एक flex race) को एक cloud route (`vertex` या `bedrock`) के साथ element 0 के रूप में भेजा गया था, लेकिन cloud routes के पास प्रतिस्पर्धा करने के लिए कोई flex tier नहीं है। FlexInference अनुपयुक्त flex race के लिए चुपचाप default tier प्रदान नहीं करता है। cloud route को एक साधारण standard कॉल के रूप में चलाने के लिए एक tier `start_within` (`default`, `priority`, या `auto`) का उपयोग करें, या `provider` में पहले एक flex-सक्षम direct route (`openai` या `google`) रखें।
`400`	`bedrock_model_unavailable`	एक `bedrock` route के पास इस slug के लिए कोई Amazon Bedrock मॉडल id नहीं है, इसलिए किसी भी upstream कॉल से पहले अनुरोध अस्वीकार कर दिया जाता है। आज इसका मतलब है `claude-opus-4-1` (इसे `bedrock` route से हटा दिया गया क्योंकि AWS इसे केवल US में प्रकाशित करता है; इसके बजाय इसे `anthropic` पर भेजें) या मनमाना unmapped `claude-` text। Bedrock अपने `global.` inference profile के माध्यम से हर mapped Claude मॉडल को सेवा देता है, इसलिए एक सेवा दिया गया मॉडल किसी भी क्षेत्र से पहुंच योग्य है; region-derived geo (`us-` -> `us.`, `eu-*` -> `eu.`, बाकी सब -> `global.`) केवल एक भविष्य के मॉडल के लिए एक निष्क्रिय fallback है जो कोई `global.` profile प्रकाशित नहीं करता है। यह उस slug के लिए स्थायी है, क्षणिक नहीं। `provider` में नामित प्रत्येक route अनुरोध को सेवा देने में सक्षम होना चाहिए, इसलिए `bedrock` का नामकरण अनुरोध को विफल कर देता है, भले ही chain में कोई अन्य route इस मॉडल को सेवा दे सकता हो। `provider` से `bedrock` को हटा दें, या मॉडल को एक ऐसे route पर भेजें जो उसे सेवा देता है।
`403`	`bedrock_model_access_denied`	Amazon Bedrock ने आपके संगठन के Bedrock key के पीछे AWS account के लिए मॉडल को अस्वीकार कर दिया, और FlexInference Bedrock की अपनी व्याख्या को पास करता है (`... is not available for this account`)। आपकी Bedrock key वैध और काम कर रही है: यह AWS account पर प्रति-मॉडल एक्सेस ग्रांट की कमी है, न कि key की समस्या, इसलिए key को बदलने से यह ठीक नहीं होगा। अधिकांश Claude मॉडल के लिए, Amazon Bedrock console में Model access के तहत मॉडल को ग्रांट करें। चार सबसे नए मॉडल (`claude-sonnet-5`, `claude-fable-5`, `claude-opus-4-8`, `claude-opus-4-7`) को अतिरिक्त रूप से एक बार के account setup की आवश्यकता होती है जिसे console ग्रांट कवर नहीं करता है - एक `provider_data_share` data-retention opt-in और एक मॉडल समझौता, admin AWS credentials के साथ चलाया जाता है; सबसे नए-मॉडल सेटअप देखें। अन्यथा मॉडल को इसके बजाय `anthropic` route पर भेजें, या एक ऐसा मॉडल चुनें जो account के पास पहले से है। यह एक स्थायी कॉन्फ़िगरेशन अंतर है, यही कारण है कि यह एक `403` है और एक retryable `502` नहीं है।
`404`	`unknown_url`	गलत path। `/v1/responses`, `/v1/chat/completions`, `/v1/interactions`, या `/v1/messages` का उपयोग करें।
`405`	`method_not_allowed`	path मौजूद है, लेकिन FlexInference endpoints केवल `POST` स्वीकार करते हैं। JSON body के साथ एक `POST` भेजें।
`499`	`client_closed_request`	FlexInference के जवाब देने से पहले client डिस्कनेक्ट हो गया, आमतौर पर एक बंद tab, रद्द किए गए fetch, या client-side timeout के कारण। इसे सेवा विफलता के रूप में नहीं गिना जाता है। यदि आपका रद्द करने का इरादा नहीं था, तो अपने client timeout को बढ़ाएँ और अनुरोध को पूरा होने दें। एक flex अनुरोध वैध रूप से 10 मिनट तक ले सकता है।
`500`	`internal_error`	FlexInference इनपुट validation के बाहर विफल रहा। एक बार पुनः प्रयास करें; यदि यह बना रहता है, तो अनुमानित timestamp और अपने संगठन के साथ support से संपर्क करें।
`500`	`server_misconfigured`	एक आवश्यक binding या secret अनुपस्थित या गलत तरीके से बना है, इसलिए FlexInference callers को authenticate नहीं कर सकता है या BYOK keys को decrypt नहीं कर सकता है। यह `internal_error` से अलग एक server-side deployment दोष है, आपके अनुरोध के साथ कोई समस्या नहीं है। थोड़ी देर बाद पुनः प्रयास करें और यदि यह बना रहता है तो support से संपर्क करें।
`502`	`upstream_stream_failed`	upstream provider ने एक response commit किया, फिर उसकी stream बिना किसी completion event के समाप्त हो गई या बिना किसी provider error के mid-stream में विफल हो गई। यह FlexInference और provider के बीच एक क्षणिक upstream या network दोष है, न कि आपका अनुरोध। एक बार पुनः प्रयास करें। यदि यह एक मॉडल के लिए बना रहता है, तो provider या मॉडल degraded हो सकता है; एक और मॉडल आज़माएँ, या एक छोटी `start_within` विंडो सेट करें ताकि एक धीमा प्रयास आपके standard tier पर जल्दी बढ़ जाए। एक upstream `5xx` से अलग जिसे provider ने स्वयं लौटाया, जिसे provider के message के साथ आपकी सतह पर reshape किया जाता है।
`502`	`upstream_unavailable`	FlexInference किसी भी response के commit होने से पहले upstream provider से कनेक्शन नहीं खोल सका (कनेक्शन अस्वीकार कर दिया गया था, या DNS, TLS, या नेटवर्क विफल हो गया था)। यह एक upstream या network दोष है, न कि आपका अनुरोध। एक बार पुनः प्रयास करें; यदि यह एक मॉडल के लिए विफल होता रहता है तो provider डाउन हो सकता है, इसलिए एक और मॉडल आज़माएँ। `upstream_stream_failed` से अलग, जहाँ एक response पहले ही शुरू हो चुका था।
`502`	`upstream_auth_failed`	upstream provider ने आपके संगठन द्वारा उसके लिए संलग्न API key को अस्वीकार कर दिया (HTTP 401 या 403, किसी भी response के commit होने से पहले)। यह आपकी FlexInference key की विफलता नहीं है; संग्रहीत provider credential में एक्सेस गुम है, रद्द कर दिया गया था, समाप्त हो गया था, या अन्यथा अमान्य है। एक org admin से dashboard में Settings -> API keys के तहत संलग्न provider key को अपडेट करने के लिए कहें, फिर पुनः प्रयास करें।
`502`	`all_routes_failed`	`provider` chain में हर route किसी भी response के commit होने से पहले क्षणिक रूप से विफल हो गया (प्रत्येक प्रयास किए गए upstream ने एक `429`, एक `5xx`, एक कनेक्शन त्रुटि, या एक timeout लौटाया), इसलिए वापस लौटने के लिए कोई route नहीं बचा था। यह एक upstream या network स्थिति है, न कि आपका अनुरोध, इसलिए इसे `502` के रूप में रिपोर्ट किया जाता है, भले ही chain स्वयं समाप्त हो गई हो। एक बार पुनः प्रयास करें; संक्षिप्त upstream hiccups आमतौर पर ठीक हो जाते हैं। यदि यह बना रहता है, तो एक अलग मॉडल आज़माएँ या chain को उन routes तक कम करें जो वर्तमान में स्वस्थ हैं।
`503`	`usage_persistence_unavailable`	FlexInference एक बिल योग्य अनुरोध के लिए उपयोग को स्थायी रूप से रिकॉर्ड नहीं कर सका। एक बार उपयोग persistence ठीक होने पर पुनः प्रयास करें।
`504`	`upstream_timeout`	upstream provider ने FlexInference के upstream timeout से पहले जवाब देना शुरू नहीं किया, इसलिए FlexInference और provider के बीच अनुरोध रद्द कर दिया गया। यह लगभग हमेशा एक क्षणिक provider धीमापन या आउटेज होता है, न कि आपका अनुरोध, और इसे आंतरिक त्रुटि के बजाय `504` के रूप में रिपोर्ट किया जाता है। एक बार पुनः प्रयास करें; यदि यह एक मॉडल के लिए समय समाप्त होता रहता है तो provider degraded हो सकता है, इसलिए एक और मॉडल आज़माएँ, या एक अवधि `start_within` के लिए `00h-00m-30s` जैसी छोटी समय सीमा निर्धारित करें।

provider array आपके route को पिन करता है। google, openai, और anthropic direct routes हैं; vertex और bedrock cloud routes हैं जो क्रमशः Google Vertex AI और Amazon Bedrock पर gemini-* और claude-* को सेवा देते हैं। एक cloud route जिसकी key कॉन्फ़िगर नहीं की गई है, वह no_vertex_key या no_bedrock_key लौटाता है, जो ऊपर no_gemini_key और no_anthropic_key के समान गुम-key पैटर्न है। upstream_auth_failed किसी भी संलग्न provider credential को कवर करता है जिसे upstream अस्वीकार करता है, जिसमें cloud routes भी शामिल हैं। provider routing देखें।

Flex परिणाम headers

सफल 200 responses में हर endpoint पर Flex outcome headers शामिल होते हैं, streaming और non-streaming दोनों कॉलों के लिए। त्रुटि responses इसके बजाय error body का उपयोग करते हैं।

हेडर	अर्थ
`x-flexinference-flex-requested`	जब caller ने एक अवधि `start_within` भेजी तो `true`; जब caller ने `default`, `priority`, या `auto` भेजा तो `false`।
`x-flexinference-flex-applied`	केवल तभी `true` जब flex tier ने response प्रदान किया।
`x-flexinference-flex-reason`	मशीन-पठनीय flex परिणाम। नीचे दिए गए मान देखें।
`x-flexinference-provider-surface`	Provider execution surface। मान `openai.responses`, `openai.chat`, `gemini.interactions`, और `anthropic.messages` हैं। यह हमेशा caller endpoint नहीं होता है। एक OpenAI मॉडल के साथ `/v1/chat/completions` कॉल `openai.responses` रिपोर्ट करता है जब तक कि native Chat passthrough की आवश्यकता न हो, उस स्थिति में यह `openai.chat` रिपोर्ट करता है।

लाइव x-flexinference-flex-reason मान:

कारण	अर्थ
`not_requested`	अनुरोध ने `default`, `priority`, या `auto` का उपयोग किया, इसलिए कोई flex race का अनुरोध नहीं किया गया था।
`flex_committed`	flex race commit हो गया। response `service_tier: "flex"` और `x-flexinference-flex-applied: true` दिखाता है।
`flex_lost_race`	अनुरोध ने एक flex-सक्षम मॉडल पर एक अवधि का उपयोग किया, लेकिन flex विंडो के भीतर शुरू नहीं हुआ और अनुरोध standard पर वापस आ गया।

एक अवधि जो flex race नहीं चला सकती है, वह 400 लौटाती है (claude-* मॉडल पर flex_unsupported_for_anthropic, गैर-flex-सक्षम OpenAI/Gemini मॉडल पर flex_model_not_capable); header कारण केवल उन अनुरोधों का वर्णन करते हैं जिन्होंने flex चलाया या इसका अनुरोध नहीं किया।

प्रदाता त्रुटियाँ

upstream provider त्रुटियाँ FlexInference त्रुटियों के समान surface envelope का उपयोग करती हैं। FlexInference provider के status और message को रखता है, फिर उन्हें आपके द्वारा कॉल किए गए endpoint के लिए envelope में उत्सर्जित करता है। एक खराब parameter के लिए provider 400, एक अमान्य provider key के लिए 401, या standard प्रयास पर 429 rate limit उसी आकार में वापस आता है। आपको provider का raw body प्राप्त नहीं होता है। उदाहरण के लिए, /v1/messages को कॉल करें और एक OpenAI-मॉडल त्रुटि Anthropic-आकार में वापस आती है। FlexInference-विशिष्ट code और doc_url केवल OpenAI envelope पर दिखाई देते हैं; provider त्रुटियाँ surface के type या status के साथ provider का message ले जाती हैं।

OpenAI surface पर, FlexInference-विशिष्ट हैंडलिंग के लिए error.code पर ब्रांच करें, जैसे कि no_byok_key पर उपयोगकर्ता को BYOK key जोड़ने के लिए प्रेरित करना। अज्ञात कोड को सामान्य OpenAI त्रुटियों के रूप में मानें।

कोड में त्रुटियों को संभालना

OpenAI SDKs गैर-2xx responses पर raise करते हैं और parsed body को संलग्न करते हैं।

from openai import APIStatusError

try:
    resp = client.responses.create(
        model="gpt-5.5",
        input="hi",
        extra_body={"start_within": "00h-00m-30s"},
    )
except APIStatusError as e:
    code = (e.body or {}).get("error", {}).get("code")
    if code == "no_byok_key":
        print("Add your OpenAI key in the dashboard.")
    else:
        raise

import OpenAI from "openai";

try {
  await client.responses.create({
    model: "gpt-5.5",
    input: "hi",
    start_within: "00h-00m-30s",
  } as any);
} catch (e) {
  if (e instanceof OpenAI.APIError && e.code === "no_byok_key") {
    console.log("Add your OpenAI key in the dashboard.");
  } else {
    throw e;
  }
}

शुरू करें

अवधारणाएँ

API का उपयोग

सामान्य प्रश्न

त्रुटियाँ

FlexInference कोड

Flex परिणाम headers

प्रदाता त्रुटियाँ

कोड में त्रुटियों को संभालना

​FlexInference कोड

​Flex परिणाम headers

​प्रदाता त्रुटियाँ

​कोड में त्रुटियों को संभालना

FlexInference कोड

Flex परिणाम headers

प्रदाता त्रुटियाँ

कोड में त्रुटियों को संभालना