मुख्य सामग्री पर जाएं
BetterToken API की त्रुटि समझने के लिए HTTP स्टेटस और उत्तर का मुख्य भाग साथ में देखें। error.message से अनुरोध ID लिख लें। फिर से भेजने से पहले प्रमाणीकरण या कॉन्फ़िगरेशन की त्रुटियाँ ठीक करें। केवल अस्थायी विफलता की पुष्टि होने पर पुनः प्रयास करें।

समस्या जाँचने से पहले

अपनी Model ID, Base URL और विफल उत्तर तैयार रखें। BetterToken Dashboard में Key की स्थिति और मौजूदा बैलेंस जाँचें। अभी तक मॉडल से सफल उत्तर नहीं मिला हो तो SDK के उदाहरणों या टूल सेटअप गाइड से शुरू करें।

त्रुटि का उत्तर पढ़ें

BetterToken API की त्रुटियाँ JSON के रूप में लौटाता है। उदाहरण के लिए, बिना Key का अनुरोध यह उत्तर दे सकता है:
error.code खाली हो तब भी error.message पढ़ें। संदेश में अनुरोध ID विफल कोशिश पहचानने में मदद करती है। बिना Key के /v1/models पर अनुरोध भेजने से 401 मिलता है। इससे यह नहीं जाँचा जाता कि मॉडल उत्तर बना सकता है या नहीं। सहायता से संपर्क करने से पहले यह जानकारी लिख लें: स्क्रीनशॉट, सहायता संदेश या साझा लॉग में अपनी BetterToken API Key शामिल न करें।

HTTP स्टेटस जाँचें

तालिका में HTTP/API के सामान्य अर्थ और संबंधित सेटअप गाइड दिए हैं। यह BetterToken के विशेष त्रुटि कोड की सूची नहीं है। समाधान चुनने से पहले वास्तविक उत्तर पढ़ें। प्रोटोकॉल और पथ के प्रत्यय की त्रुटियों के लिए Base URL से जुड़े प्रश्न देखें। कैश के लिए कैश बिलिंग से जुड़े प्रश्न देखें।

अस्थायी विफलताओं पर पुनः प्रयास करें

अस्थायी 429 या सर्वर विफलता की पुष्टि होने पर कुछ यादृच्छिक देरी जोड़कर, हर बार बढ़ता हुआ लेकिन सीमित इंतज़ार रखें। Retry-After मिले तो उसका पालन करें। वह तय प्रतीक्षा सीमा से अधिक हो तो लूप बंद करें और उसके बाहर इंतज़ार करें। SDK और अपने लूप के प्रयास एक ही कुल सीमा में गिनें। अपनी नीति लागू करते समय SDK के अपने पुनः प्रयास बंद करें। बिना बदलाव के 400, 401, 403, बैलेंस या कॉन्फ़िगरेशन की विफलता दोबारा न भेजें। क्लाइंट टाइमआउट या टूटी स्ट्रीम से यह साबित नहीं होता कि प्रोसेसिंग से पहले ही अनुरोध विफल हो गया। पहले Dashboard जाँचें, खासकर इमेज जनरेशन या ऐसी प्रक्रिया में जहाँ कोई कार्रवाई दोहराई जा सकती है। नीचे के उदाहरण बिना स्ट्रीमिंग वाला Chat Completions अनुरोध अधिकतम चार बार भेजते हैं। वे HTTP 500, 502 और 503 पर पुनः प्रयास करते हैं। जब तक उत्तर में अस्थायी अनुरोध दर सीमा की पुष्टि न हो, 429 पर पुनः प्रयास बंद रहता है। टाइमआउट, नेटवर्क अपवाद और 504 पर वे रुकते हैं, ताकि आप अनुरोध पूरा होने की जाँच कर सकें। हर प्रयास के लिए अधिकतम प्रतीक्षा 30 सेकंड है।

अनुरोध तैयार करें

model plaza से मौजूदा Model ID कॉपी करें और दोनों प्लेसहोल्डर बदलें। Chat Completions पर उपलब्ध टेक्स्ट मॉडल इस्तेमाल करें।
Python का उदाहरण मानक लाइब्रेरी इस्तेमाल करता है। JavaScript का उदाहरण .mjs फ़ाइल में सहेजें और ऐसे Node.js संस्करण से चलाएँ जिसमें fetch और AbortSignal.timeout उपलब्ध हों।
उत्तर के मुख्य भाग में लगातार बनी रहने वाली कॉन्फ़िगरेशन, बैलेंस या पहुँच की समस्या दिखे तो लूप रोककर उसे ठीक करें, भले ही स्टेटस के आधार पर पुनः प्रयास संभव लगे। इस छोटे टेक्स्ट उदाहरण को दूसरे कामों में इस्तेमाल करने से पहले ऐप के अनुसार पूरा होने की जाँच जोड़ें।

लक्षण के अनुसार गाइड चुनें

समाधान की पुष्टि करें

जिस क्लाइंट, Base URL और Model ID से विफलता हुई थी, उसी से छोटा, गैर-महत्वपूर्ण अनुरोध भेजें। सामान्य उत्तर मिलने के बाद Dashboard में उसका रिकॉर्ड खोजें। बड़ा वर्कफ़्लो फिर शुरू करने से पहले मॉडल, स्थिति, टोकन उपयोग और शुल्क जाँचें।

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

क्या हर 429 पर इंतज़ार करके फिर कोशिश करनी चाहिए?

उपयोग सीमा की जाँच वाले प्रश्न देखें और तय करें कि क्या जाँचना है तथा आपके उत्तर पर पुनः प्रयास करना उचित है या नहीं।

क्या एक विफलता के बाद टाइमआउट बढ़ा देना चाहिए?

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

संबंधित गाइड