साइन-इन ज़रूरी नहीं: अनाम दर सीमा मुफ़्त टूल को मुफ़्त कैसे रखती है

PDF123 एक अपलोड-और-डाउनलोड पथ बनाए रखता है जिसमें खाता नहीं चाहिए। वही प्रचालन /api/v1/ के अंतर्गत भी हैं ताकि कोई स्क्रिप्ट प्रोसेस बटन पर किसी व्यक्ति के क्लिक के बिना उन्हें कॉल कर सके। अनाम उपयोग के लिए API की नहीं चाहिए। दर-सीमाएँ इस सतह को अनबँधा मुफ़्त होस्ट बनने से रोकती हैं।

अनाम ही डिफ़ॉल्ट पथ है

Compress या Merge जैसे टूल पेज पर फ़ाइल गिराएँ और चलाएँ। कैटलॉग टूल के लिए /api/v1/ के अंतर्गत अनाम REST भी वैसे ही काम करता है। /api/v1/general/, /api/v1/misc/, /api/v1/security/, /api/v1/convert/ और /api/v1/filter/ के अंतर्गत एंडपॉइंट अनाम टूल उपसर्ग हैं; पोर्टल का हर कैटलॉग टूल इन्हीं पथों पर मैप होता है।

साइन इन इसलिए है ताकि आप स्वचालन के लिए निजी API की बना सकें, इसलिए नहीं कि प्रोसेस कोई पेवॉल बन जाए। ब्राउज़र फ़ॉर्म और HTTP अनुबंध एक साथ रहते हैं: हर टूल पेज का “Call this from code” खंड उन्हीं फ़ील्ड से curl बनाता है जो फ़ॉर्म भेजता है।

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

शीर्षलेख क्या बताते हैं

हर होस्टेड API प्रतिक्रिया बजट बताती है (pdfx-server पर लागू):

• X-RateLimit-Limit: इस प्रतिक्रिया के लिए घोषित अवधि सीमा
• X-RateLimit-Remaining: मौजूदा अवधि में बचा बजट
• X-RateLimit-Reset: खिड़की का रीसेट संकेत (मान पढ़ें; कैलेंडर दिन न मानें)

HTTP 429 पर Retry-After बताता है कि शिष्ट क्लाइंट कब फिर कोशिश करे। कोटा विफलताएँ Developers errors के अंतर्गत संरचित rate_limited समस्या कोड इस्तेमाल करती हैं, बाक़ी API विफलताओं जैसी ही application/problem+json आकृति के साथ। स्क्रिप्ट HTML त्रुटि पेज स्क्रैप किए बिना कोड पर शाखा बना सकती है।

संख्यात्मक सीमाएँ डिप्लॉयमेंट सेटिंग के साथ बदल सकती हैं। किसी दी गई प्रतिक्रिया के शीर्षलेख ही सत्य हैं, इस लेख की कोई तस्वीर नहीं। जो क्लाइंट इस लेख से रोज़ का कोई नंबर हार्डकोड करेगा, वह अगली बार ग़लत होगा जब ऑपरेटर अवधि दोबारा तय करेंगे। हर कॉल के बाद X-RateLimit-Remaining पढ़ना और शून्य के पास पहुँचने पर पीछे हटना बेहतर है।

मुफ़्त टूल फिर भी कॉलर पर सीमा क्यों लगाता है

सीमाओं के बिना अनाम एंडपॉइंट किसी और का बैच-फ़ार्म बन जाते हैं। सीमाएँ एक-बारगी काम उपयोगी रखती हैं, जबकि भारी या निजी काम चाबियों या स्वयं-होस्टिंग की ओर बढ़ते हैं।

सीमाएँ उन प्रचालनों के लिए साझा CPU भी बचाती हैं जो सचमुच महँगे हैं: बड़े मर्ज, स्कैन से Markdown लौटाने वाला OCR (text/markdown, दोबारा-परत PDF नहीं), और बहु-चरणीय POST /api/v1/pipeline रन। उत्पाद का चुनाव “अनाम और सीमित” है, “अनाम और असीमित” नहीं।

अनाम पहुँच अब भी अस्थायी प्रसंस्करण है: अपलोड काम के लिए संभाले जाते हैं और नतीजा तैयार होने पर साफ़ कर दिए जाते हैं। दर-सीमा क्षमता की निष्पक्षता के बारे में है, मुफ़्त लॉगिन दीवार के पीछे दीर्घकालिक दस्तावेज़ भंडार गढ़ने के बारे में नहीं।

चाबियाँ पहचान बदलती हैं, कैटलॉग नहीं

जब स्थिर कॉलर पहचान, ऐसे Idempotency-Key पुनः प्रयास जो काम दोबारा न चलाएँ, या स्थिर वैश्विक की वाला स्वयं-होस्टेड सर्वर (आपके बॉक्स पर SECURITY_CUSTOMGLOBALAPIKEY) चाहिए, तब Developers से की बनाएँ। OpenAPI उसी बेस URL पर /v1/openapi.json रहता है जिसे आप हिट करते हैं।

/mcp पर MCP वही कैटलॉग और स्वचालन क्लाइंट के लिए वही की-कहानी अपनाता है। प्रचालन वही रहते हैं, चाहे कॉलर अनाम हो या की-युक्त। बदलती हैं प्रमाणीकरण और कोटा।

एक ही प्रचालन के चार हैंडल (ब्राउज़र, curl, MCP, CLI) के लिए वही प्रचालन, चार क्लाइंट देखें। जब सीमाएँ या प्रतिधारण काफ़ी न हों और पूरी सतह अपने नेटवर्क पर लानी हो, तो स्वयं-होस्टिंग असल में क्या देती है देखें।