वही प्रचालन, चार क्लाइंट: ब्राउज़र, curl, MCP, pdfx
वही PDF123 मर्ज चार क्लाइंट से: ब्राउज़र फ़ॉर्म, /api/v1/general/merge-pdfs पर curl, /mcp पर MCP, और स्थानीय या --cloud pdfx आपके API बेस के ख़िलाफ़।
चार क्लाइंट चार उत्पाद जैसे लगते हैं। वे एक ही कैटलॉग साझा करते हैं। Merge को ठोस काम मानें: पेजों को इमेज में बदले बिना अपलोड क्रम में PDF जोड़ें। यही ढाँचा हर दूसरे कैटलॉग टूल (compress, OCR, रूपांतरण और बाक़ी) पर लागू होता है: एक प्रचालन-आईडी, चार तरह से बुलाने के।
ब्राउज़र
/merge खोलें, फ़ाइलें मनचाहे क्रम में जोड़ें, प्रोसेस, डाउनलोड। कैटलॉग टूल के लिए खाता नहीं। पेज का “Call this from code” खंड उन्हीं फ़ील्ड से curl बनाता है जो फ़ॉर्म भेजता है, इसलिए इंटरफ़ेस और HTTP अनुबंध एक साथ रहते हैं।
वह खंड विपणन पाठ नहीं है। यह उसी टूल परिभाषा से बनता है जो पोर्टल फ़ॉर्म के लिए पहले से इस्तेमाल करता है, इसीलिए कोई पैरामीटर-नाम बदलाव दोनों जगह साथ दिखता है। अगर फ़ॉर्म वैकल्पिक sortType=byFileName लेता है, तो curl उदाहरण वही फ़ील्ड रख सकता है।
curl / REST
curl -fsS -X POST "$API_BASE/api/v1/general/merge-pdfs" \
-F "[email protected]" \
-F "[email protected]" \
-o merged.pdf
अनाम कैटलॉग कॉल के लिए की नहीं चाहिए। Developers से मिली चाबियाँ स्वचालन को स्थिर पहचान देती हैं (और स्वयं-होस्टेड सर्वर को द्वार)। OpenAPI /v1/openapi.json पर है।
बहु-चरणीय कामों के लिए POST /api/v1/pipeline क्रमबद्ध प्रचालन steps फ़ील्ड में लेता है (जैसे मर्ज, फिर वॉटरमार्क, फिर संपीड़न)। जब पुनः प्रयासों से काम दोबारा न चलना हो तो Idempotency-Key भेजें; सफल पुनरावृत्ति Idempotency-Replayed के साथ लौट सकती है। विफलताएँ application/problem+json इस्तेमाल करती हैं, rate_limited और bad_request जैसे स्थिर कोड के साथ (Developers errors)।
होस्टेड प्रतिक्रियाएँ X-RateLimit-Limit, X-RateLimit-Remaining और X-RateLimit-Reset भी बताती हैं; HTTP 429 में Retry-After होता है। उन शीर्षलेखों को जीवित बजट मानें, किसी ब्लॉग पोस्ट से याद किया नंबर नहीं (अनाम दर सीमा)।
MCP
जो एजेंट Model Context Protocol बोलते हैं, वे /mcp से जुड़ते हैं, merge को टूल की तरह खोजते हैं, और REST जैसी ही API-की कहानी के साथ उसे बुलाते हैं। दस्तावेज़: Developers MCP।
MCP दूसरा कैटलॉग नहीं है। यह उन्हीं प्रचालनों पर खोज और आह्वान प्रोटोकॉल है जो OpenAPI सूचीबद्ध करता है। अगर कोई प्रचालन MCP से गायब है, तो वह सर्वर की गड़बड़ है, अलग उत्पाद-रोडमैप नहीं। क्लाइंट जुड़ने से पहले टूल का गद्य-सूचकांक चाहिए तो MCP के साथ /llms.txt रखें।
pdfx CLI
स्थानीय pdf-core:
pdfx merge a.pdf b.pdf -o merged.pdf
या वही सर्वर जो पोर्टल इस्तेमाल करता है:
pdfx --cloud --api-base "$API_BASE" --api-key "$KEY" merge a.pdf b.pdf -o merged.pdf
स्थानीय मोड कभी अपलोड नहीं करता; क्लाउड मोड आपके बेस URL पर curl जैसी ही मल्टीपार्ट आकृति से पहुँचता है। dist/skills/pdf-toolbox/SKILL.md के अंतर्गत कोडिंग-एजेंट स्किल वही मर्ज और पाइपलाइन आकृतियाँ दर्ज करती है ताकि एजेंट दूसरा OpenAPI न गढ़ें।
इनमें से किसी भी क्लाइंट से OCR अब भी /api/v1/misc/ocr-pdf से Markdown लौटाता है, छिपी टेक्स्ट परत नहीं। यह तथ्य साझा अनुबंध का हिस्सा है: बाक़ी क्लाइंट बदले बिना एक क्लाइंट में लौटाव-प्रकार बदलना “वही प्रचालन” का वादा तोड़ देगा। Compress /api/v1/misc/compress-pdf पर स्ट्रीम पुनःसंपीड़न के लिए रहता है; यह merge से अलग प्रचालन है, उन्हीं चार तरीक़ों से पहुँचता हुआ।
समानता क्यों मायने रखती है
अगर ब्राउज़र मर्ज और API मर्ज कभी अलग हो जाएँ, तो स्वचालन चुपचाप पीछे जाते रहेंगे जबकि डेमो पेज ठीक दिखता रहेगा। एक प्रचालन, चार हैंडल, यही मुद्दा है। पोर्टल सुविधा का क्लाइंट है, merge, compress या OCR का दूसरा कार्यान्वयन नहीं।
इसीलिए डेस्कटॉप फ़ोर्क भी नहीं है: पाँचवाँ इंटरफ़ेस वृक्ष उसी ड्रिफ़्ट समस्या को दूसरे बाइनरी नाम के नीचे दोहरा देता। व्यापक ढाँचा: AI एजेंट के लिए बनाया गया, सिर्फ़ ब्राउज़र के लिए नहीं। डेस्कटॉप फ़ैसले के लिए हमने डेस्कटॉप ऐप क्यों छोड़ा देखें। API अपने नेटवर्क पर खड़ा करने के लिए Self-host देखें।