API रेफ़रेंस

अंतिम अपडेट: 3 जुलाई 2026

यह रेफ़रेंस उन डेवलपर्स के लिए HTTP API स्पेसिफ़िकेशन है जो WEEGLOO को कोड से सीधे संचालित करते हैं। हर रिसोर्स पेज का एंडपॉइंट ब्लॉक एक ऐसे कंसोल के रूप में रेंडर होता है जिसमें आप path, header और body को सीधे भरकर वास्तव में कॉल कर सकते हैं। रिक्वेस्ट कैसी दिखती है और रिस्पॉन्स किस आकार में लौटता है, यह आप वहीं उसी जगह देख सकते हैं।

AI एजेंट इस HTTP API को सीधे कॉल नहीं करते, बल्कि WEEGLOO MCP टूल का उपयोग करते हैं। नीचे दिया गया स्पेसिफ़िकेशन उन स्थितियों के लिए है जब frontend, backend या script जैसे application कोड से API को सीधे कॉल किया जाता है।

API और Base URL

WEEGLOO उपयोग के अनुसार विभाजित कई API प्रदान करता है। जिस API को कॉल करना है उसके अनुरूप Base URL चुनकर उपयोग करें। होस्ट का अनुमान न लगाएँ और न ही उसमें बदलाव करें।

APIउपयोगBase URL
CMAकंटेंट प्रबंधन (Weegloo User द्वारा निर्माण, संशोधन, विलोपन)https://cma.weegloo.com
CDAप्रकाशित कंटेंट की डिलीवरी (केवल पढ़ने के लिए, कैश आधारित)https://cda.weegloo.com
Uploadफ़ाइल अपलोडhttps://upload.weegloo.com
ACMAऐप सदस्य (ServiceUser) कंटेंट प्रबंधनhttps://acma.weegloo.com
ACDAऐप सदस्य (ServiceUser) डिलीवरी (केवल पढ़ने के लिए)https://acda.weegloo.com
AuthServiceUser OAuth लॉगिन एवं टोकनhttps://auth.weegloo.com

path /v1/... को आधार मानते हैं। उदाहरण के लिए, किसी Space के भीतर Content की सूची https://cma.weegloo.com/v1/spaces/{spaceId}/contents है।

पहचान और टोकन

WEEGLOO में दो परस्पर पूर्णतः अलग पहचान प्रणालियाँ हैं। किस पहचान ने टोकन जारी किया है, उसी के अनुसार यह तय होता है कि कौन-सा API कॉल किया जा सकता है।

Weegloo User एक WEEGLOO प्लेटफ़ॉर्म अकाउंट है। सोशल लॉगिन आदि से जब आप पहली बार लॉगिन करते हैं, तभी उसी जगह अकाउंट बन जाता है (पहला लॉगिन ही साइन-अप है)। लेकिन किसी विशिष्ट Space की कंटेंट को संचालित करने के लिए आपको उस Space का सदस्य होना ज़रूरी है, और सदस्यता पहले से जुड़े किसी व्यक्ति के आमंत्रण तथा SpaceRole प्रदान करने से तय होती है। यानी अकाउंट तो आप स्वतंत्र रूप से बना सकते हैं, पर किस Space में प्रवेश करके क्या कर सकते हैं, यह सदस्यता और भूमिका द्वारा नियंत्रित होता है। इस पहचान का Bearer टोकन (server/CI के लिए PersonalAccessToken या कंटेंट स्टूडियो लॉगिन से प्राप्त टोकन) CMA, Upload और CDA को प्रमाणित करता है। ब्राउज़र में उजागर होने वाली सार्वजनिक डिलीवरी के लिए टोकन के बजाय न्यूनतम तक सीमित अनुमति वाले DeliveryAccessToken (CDA) का उपयोग करें।

ServiceUser उत्पाद में साइन-अप किया हुआ end-user है (ServiceLogin के माध्यम से साइन-अप)। साइन-अप किसके लिए खुला हो और नए साइन-अप पर एडमिन की स्वीकृति रखनी हो या नहीं, यह ServiceLogin सेटिंग से तय होता है। इस पहचान का Bearer टोकन (auth.weegloo.com से जारी) ACMA, ACDA और Upload को प्रमाणित करता है। इसे CMA, CDA के लिए उपयोग नहीं किया जा सकता।

टोकन पहचान की सीमाओं को पार नहीं करते। ServiceUser टोकन को CMA, CDA पर नहीं भेजा जा सकता, और Weegloo User टोकन ACMA, ACDA के लिए वैध कॉलर नहीं है। दोनों पहचानें केवल एक ही सतह साझा करती हैं, और वह है Upload। अपलोड के बाद Media का निर्माण कहाँ होता है, यह पहचान के अनुसार CMA (Weegloo User) या ACMA (ServiceUser) में विभाजित होता है।

सामान्य नियम

नीचे दिए गए चार नियम किसी विशिष्ट रिसोर्स तक सीमित नहीं हैं, बल्कि सभी कॉल पर समान रूप से लागू होते हैं। प्रत्येक रिसोर्स पेज यह मानकर चलता है कि ये नियम लागू हैं और केवल अपनी विशिष्ट सामग्री को ही संबोधित करता है।

रिसोर्स रेफ़रेंस

प्रत्येक API के अनुसार रिसोर्स स्पेसिफ़िकेशन नीचे दिए गए हब में संबोधित किए जाते हैं।

  • CMA: कंटेंट मॉडल एवं प्रबंधन: Content Type, Content, Media, Tag, Locale तथा टोकन, संगठन, Space, भूमिका, Webhook, WebHosting, ServiceLogin आदि प्रबंधन रिसोर्स।
  • CDA: डिलीवरी: प्रकाशित कंटेंट को केवल पढ़ने के लिए डिलीवर करना।
  • Upload: फ़ाइल अपलोड करके Media, WebHosting निर्माण में उपयोग होने वाला Upload प्राप्त करना।
  • Auth: ServiceUser OAuth लॉगिन एवं टोकन एक्सचेंज।
  • ACMA: ऐप सदस्य (ServiceUser) का कंटेंट प्रबंधन।
  • ACDA: ऐप सदस्य (ServiceUser) को प्रकाशित कंटेंट की डिलीवरी।