सामान्य Chat Completions

model पैरामीटर से टेक्स्ट मॉडल बदलने वाला एकीकृत चैट API। अनुरोध प्रारूप OpenAI Chat Completions के संगत है।

अपस्ट्रीम प्रदाता Claude Sonnet 4.6 (claude-sonnet-4-6) समर्थित करता है, लेकिन यह फिलहाल API Hop पर प्रकाशित नहीं है। यह सक्रिय एकीकरण डिफ़ॉल्ट नहीं है। कोई भी मॉडल कॉल करने से पहले अपने GET https://api.apihop.ai/v1/models उत्तर से पहुँच पुष्टि करें।

यह एंडपॉइंट डिफ़ॉल्ट रूप से एक पूरा JSON उत्तर देता है। SSE स्ट्रीमिंग चाहिए तो स्पष्ट रूप से stream: true सेट करें।

POST https://api.apihop.ai/v1/chat-completions

प्रमाणीकरण

सभी अनुरोधों में Bearer Token प्रमाणीकरण आवश्यक है।

Authorization: Bearer YOUR_API_KEY

प्रमाणीकरण विफल हो तो जाँचें:

• API कुंजी सही है या नहीं
• कुंजी इस API Base URL के लिए वैध है या नहीं
• अनुरोध हेडर की वर्तनी सही है या नहीं
• प्रॉक्सी authorization हेडर बदलती है या नहीं

अनुरोध बॉडी

  [
    {"role": "system", "content": "You are a helpful Python tutor."},
    {"role": "user", "content": "How should I learn programming?"}
  ]

मॉडल-विशिष्ट सैंपलिंग सीमाएँ: gpt-6-astra पुराने temperature, top_p या top_logprobs स्वीकार नहीं करता; पुराना क्लाइंट उन्हें जोड़ता हो तब भी हटाएँ। API Hop का GPT-6 Astra Playground पुराने सैंपलिंग और पेनल्टी नियंत्रण भी छिपाता है। दर्ज एकीकरण पुनःजाँच में claude-sonnet-5 ने top_p अस्वीकार किया, इसलिए उस मॉडल में भी उसे छोड़ें। प्रॉक्सी से वैकल्पिक फ़ील्ड भेजना चुने अपस्ट्रीम मॉडल के समर्थन की पुष्टि नहीं करता।

मॉडल पैरामीटर में अंतर

वर्तमान टेक्स्ट मॉडल न्यूनतम स्ट्रीमिंग और नॉन-स्ट्रीमिंग Chat अनुरोध समर्थित करते हैं, लेकिन वैकल्पिक पैरामीटर की स्वीकृति और प्रभाव चुने मॉडल तथा उसके संगतता कार्यान्वयन के अनुसार बदलते हैं।

2026-09-26 की नवीनतम पुनःजाँच में claude-fable-5 ने temperature: 0 स्वीकार किया और पाठ लौटाया। उसी जाँच में claude-sonnet-5 ने top_p: 0.9 को HTTP 400 और top_p is deprecated के साथ अस्वीकार किया। उस मॉडल में top_p छोड़ें। स्वीकृति न सैंपलिंग प्रभाव सिद्ध करती है, न दूसरे मॉडल या बाद के अनुरोध की गारंटी; सभी सैंपलिंग पैरामीटर समर्थित न मानें।

2026-09-26 की OpenAI जाँचों में gpt-5.6-sol और gpt-5.6-terra के लिए stop स्वीकार हुआ। अपस्ट्रीम के साथ पैरामीटर स्वीकृति बदल सकती है और इससे रुकने का क्रम प्रभावी होना सिद्ध नहीं होता।

मूल OpenAI-संगत Chat फ़ॉरवर्डिंग अपस्ट्रीम अनुरोध में top_p और stop रखती है। Chat को Responses में बदलने वाला रूट top_p रखता है लेकिन stop आगे नहीं भेजता। फ़ील्ड आगे भेजना अपस्ट्रीम समर्थन या प्रभाव स्थापित नहीं करता; किसी भी फ़ील्ड के लिए सभी रूट पर प्लेटफ़ॉर्म-व्यापी गारंटी नहीं है।

मॉडल बदलते समय न्यूनतम अनुरोध से शुरू करें, फिर सैंपलिंग, रुकने के क्रम और उन्नत टूल पैरामीटर अलग सत्यापित करें। रुकने के क्रम में केवल HTTP स्थिति नहीं, वास्तविक पाठ और रुकने का कारण देखें। HTTP 200 सैंपलिंग प्रभाव सिद्ध नहीं करता। आउटपुट बजट में मॉडल का सोच-विचार और अंतिम पाठ दोनों समाने चाहिए।

अनुरोध उदाहरण

{
  "model": "gpt-5.4",
  "messages": [
    {
      "role": "user",
      "content": "Hello, introduce yourself briefly."
    }
  ],
  "stream": false
}

उत्तर

सफलता उदाहरण

{
  "id": "chatcmpl-9876543210",
  "object": "chat.completion",
  "created": 1677652288,
  "model": "gpt-5.4",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "I am an AI assistant that can help with writing, coding, and analysis."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 28,
    "completion_tokens": 42,
    "total_tokens": 70
  }
}

त्रुटि उत्तर

पूरी कोड सूची, प्रोटोकॉल अंतर और निदान चरणों के लिए त्रुटि कोड और निदान देखें।

Chat Completions की HTTP त्रुटियाँ समतल JSON बॉडी इस्तेमाल करती हैं, जिसमें SSE स्ट्रीम शुरू होने से पहले लौटी अपस्ट्रीम HTTP त्रुटियाँ भी हैं। उदाहरण के लिए HTTP 402 लौटाता है:

{
  "code": 40000,
  "message": "Insufficient credit. Required: 30000, Available: 20000",
  "type": "api_error"
}

• code: संख्यात्मक प्लेटफ़ॉर्म त्रुटि कोड, HTTP स्थिति से अलग और स्ट्रिंग नहीं
• message: पढ़ने योग्य त्रुटि विवरण
• type: api_error
• requestId: निदान के लिए वैकल्पिक अनुरोध पहचान

अनुरोध सफल हुआ या नहीं जानने के लिए पहले HTTP स्थिति जाँचें, फिर ऐप-विशिष्ट प्रबंधन के लिए संख्यात्मक code तुलना करें। code को "400" जैसी स्ट्रिंग से न मिलाएँ, उसे HTTP स्थिति के बराबर न मानें और message को स्थिर त्रुटि पहचान की तरह पार्स न करें। अनुपस्थित या गलत प्रकार के messages, प्रदाता कॉल से पहले HTTP 400 और code: 10000 के साथ अस्वीकार होते हैं।

यह त्रुटि प्रारूप Chat Completions HTTP उत्तरों पर लागू है, शुरू हो चुकी SSE स्ट्रीम की त्रुटियों या दूसरे API प्रोटोकॉल पर नहीं। मॉडल कैटलॉग और मूल प्रोटोकॉल एंडपॉइंट के अपने दस्तावेज़ीकृत त्रुटि प्रारूप हैं।