Script संसाधन और एंडपॉइंट

Script एक घोषणात्मक बैकएंड एंडपॉइंट है जिसे फ्रंटएंड HTTP के ज़रिए कॉल करता है (इसकी अवधारणा और शीर्ष-स्तरीय संरचना Script अवलोकन में दी गई है)। यह पेज Script संसाधन की sys संरचना और बॉडी प्रॉपर्टीज़, Script को रचने और निष्पादित करने वाले HTTP एंडपॉइंट के विनिर्देश, तथा निष्पादन के रिकॉर्ड ScriptLog को कवर करता है।

Script को बनाने और प्रबंधित करने का काम (सूची·पठन·निर्माण·संशोधन·विलोपन) CMA (https://cma.weegloo.com/v1) पर होता है। निष्पादन की ज़िम्मेदारी समर्पित Script होस्ट (https://script.weegloo.com/v1) के निष्पादन पथ की है, और यही एक निष्पादन पथ Weegloo User टोकन और उत्पाद में साइन अप कर चुके सदस्य (ServiceUser) के टोकन, दोनों को स्वीकार करता है। ACMA में Script API नहीं है, और केवल-पढ़ने वाली डिलीवरी API (CDA, ACDA) में भी नहीं है।

Script एक ऐसा संसाधन है जो version रखता है, और यह प्रति-प्लान गिनती सीमा के अधीन एक बिलिंग-योग्य संसाधन है। लेकिन Content या Media के विपरीत, इसमें कोई publish स्थिति नहीं होती। इसके sys में status या publish जैसी publish-संबंधी प्रॉपर्टीज़ नहीं होतीं; हर बदलाव पर केवल version बढ़ता है। publish और unpublish की कोई अवधारणा न होने के कारण, इसे हटाना भी बिना unpublish किए तुरंत हो जाता है।

संसाधन संरचना

नीचे Script "t6-http" की एकल-पठन प्रतिक्रिया है। sys (सिस्टम प्रॉपर्टीज़) के साथ-साथ इसमें name, definition, तथा कॉल के पाथ खोलने-बंद करने वाले directCallEnabled और anonymousCallEnabled बॉडी प्रॉपर्टीज़ के रूप में होते हैं।

{
  "sys": {
    "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK",
    "type": "Script",
    "space": { "sys": { "id": "6jSUUAWT", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQYJNvYTBJf2rYKr42xegQLJ", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-07-15T12:35:47.575Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQYJNvYTBJf2rYKr42xegQLJ", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-07-15T12:35:47.575Z",
    "version": 1
  },
  "name": "t6-http",
  "directCallEnabled": true,
  "anonymousCallEnabled": false,
  "definition": {
    "method": "Post",
    "statements": [
      {
        "name": "resp",
        "method": "POST",
        "url": "https://postman-echo.com/post",
        "headers": [ { "key": "Content-Type", "value": "application/json", "secret": false } ],
        "body": { "prompt": "{ /payload/prompt }" },
        "timeoutMs": 10000,
        "retry": 0,
        "type": "Http"
      },
      {
        "value": { "status": "{ /resp/status }", "prompt": "{ /resp/body/json/prompt }" },
        "isError": false,
        "statusCode": 200,
        "type": "Return"
      }
    ]
  }
}

मुख्य कीज़:

• sys.id: Script का यूनीक आइडेंटिफ़ायर। यह एकल-पठन, संशोधन, विलोपन और निष्पादन वाले पाथ के {scriptId} में जाता है।
• name: Script का नाम (1 से 64 अक्षर)। स्क्रीन पर दिखने वाली सूची और मैनेजमेंट-संबंधी पहचान के लिए उपयोग होता है।
• definition: यह ScriptDefinition है जो घोषित करता है कि यह Script क्या करता है। यह कॉल मेथड (method), statement (statements) ऐरे, और वैकल्पिक payload स्कीमा (payloadSchema) से मिलकर बनता है। इसकी विस्तृत संरचना नीचे परिभाषा और नाम में और Script अवलोकन में शीर्ष-स्तरीय संरचना में दी गई है।
• directCallEnabled: यह तय करता है कि इस Script को /execute से सीधे बुलाया जा सकता है या नहीं (बूलियन, छोड़ने पर true)। false होने पर सीधी कॉल अस्वीकृत हो जाती है। इस Script को निष्पादित करने के दूसरे रास्ते ज्यों-के-त्यों बने रहते हैं। Webhook की लिंक्ड ऐक्शन (script) और Scheduler इस एंडपॉइंट से नहीं गुज़रते, इसलिए वे उसे पहले की तरह निष्पादित करते हैं।
• anonymousCallEnabled: यह तय करता है कि इस Script को बिना प्रमाणीकरण /execute/anonymous से बुलाया जा सकता है या नहीं (बूलियन, छोड़ने पर false)। चालू करने पर वह तीसरा पक्ष भी, जो टोकन नहीं भेज सकता, उस पाथ से इस Script को चला सकता है, और निष्पादन लेखक की पहचान से होता है। शर्तें और सेव के नियम नीचे अनाम कॉल में दिए गए हैं।

ध्यान दें कि sys में status, publish या archive नहीं होते। Script कोई ऐसा संसाधन नहीं है जो डिलीवरी पाथ पर publish होता हो; यह वह संसाधन है जिसे आप मैनेजमेंट API में रचते और चलाते हैं।

सिस्टम प्रॉपर्टीज़ (sys)

हर Script सामान्य सिस्टम प्रॉपर्टीज़ को sys ऑब्जेक्ट में रखता है। space, createdBy और updatedBy Refer आकार ({ "sys": { "id", "type": "Refer", "targetType" } }) में आते हैं।

Content, Content Type और Media के sys में मौजूद status (publish स्थिति) और publish (publish इतिहास) Script में नहीं होते। ऐसा इसलिए है क्योंकि Script publish नहीं होता। archive प्रॉपर्टी भी नहीं होती। इसलिए Script का version बिना किसी publish के, केवल बनाने और संशोधन की संख्या के अनुसार बढ़ता है।

परिभाषा और नाम (name, definition)

Script की बॉडी प्रॉपर्टीज़ चार हैं: name, definition, directCallEnabled और anonymousCallEnabled।

definition (ScriptDefinition) की कीज़:

statements ऐरे में डाले जाने वाले हर statement के प्रकार और फ़ील्ड Statement कैटलॉग में दिए गए हैं, और मान को आगे भेजने वाली { /pointer } अभिव्यक्तियाँ मान अभिव्यक्ति में दी गई हैं।

ऊपर दिए उदाहरण "t6-http" के definition में method Post है; यह Http statement से एक बाहरी API को कॉल करता है और फिर Return statement से उसका परिणाम लौटाता है। Http की तरह बाहरी कॉल वाला statement अपने हिस्से का समय घोषित करता है, और उतना समय एक निष्पादन को मिलने वाले समय में जुड़ जाता है (एक निष्पादन को मिलने वाला समय देखें)।

बाधाएँ

ऊपर दी गई स्थैतिक बाधाएँ Script को सेव (बनाते/संशोधित करते) करते समय जाँची जाती हैं, और उल्लंघन होने पर सेव अस्वीकृत हो जाता है। बाहरी कॉल की संख्या और कुल statement संख्या कोई वैधता त्रुटि नहीं, बल्कि प्लान सीमा हैं, इसलिए वही परिभाषा किसी उच्च प्लान में स्वीकार्य होती है।

सेव के समय अनुमतियाँ और संसाधन के प्रकार भी साथ में जाँचे जाते हैं।

• यह जाँचा जाता है कि लेखक के पास वे संसाधन और ऐक्शन अनुमतियाँ वास्तव में हैं या नहीं जिनका उपयोग वे statement करते हैं (यदि कोई एक भी न हो, तो सेव अस्वीकृत हो जाता है। त्रुटियाँ देखें)। सदस्य (ServiceUser) को पढ़ने वाले statement की जाँच अनुमति map से नहीं, बल्कि SpaceRole के settings में मौजूद SETTING_SERVICE_LOGIN से होती है।
• सदस्य (ServiceUser) को बदलने वाला statement शामिल हो, तो सेव अस्वीकृत कर दिया जाता है। यह संसाधन Script में केवल पढ़ा जा सकता है, इसलिए इसे किसी भी भूमिका से सेव नहीं किया जा सकता।

विस्तृत नियम, समय बजट, और निष्पादन के दौरान जाँची जाने वाली मान की लंबाई की ऊपरी सीमा निष्पादन सिमेंटिक्स, बाधाएँ, सुरक्षा में दिए गए हैं।

Script एक बिलिंग-योग्य संसाधन है, और प्रति Organization इसकी संख्या प्लान के अनुसार सीमित होती है (Free 10 / Basic 30 / Pro 100 / Enterprise असीमित)। सीमा तक पहुँचने पर नया Script बनाना अस्वीकृत हो जाता है (प्रति प्लान संख्या सीमा देखें)।

अनाम कॉल (anonymousCallEnabled)

anonymousCallEnabled को true रखने पर वह Script बिना प्रमाणीकरण वाले एक समर्पित पाथ से भी निष्पादित होती है।

{method} https://script.weegloo.com/v1/spaces/{spaceId}/scripts/{scriptId}/execute/anonymous

इसकी आवश्यकता कम ही पड़ती है। यह उन तीसरे पक्षों के लिए बनी व्यवस्था है, जिन्हें भुगतान प्रदाता (PG·MoR) की तरह हमें कॉलबैक भेजना होता है, पर जो कस्टम हेडर का समर्थन न करने के कारण Access Token भेजने का कोई तरीका नहीं रखते। जो कॉलर टोकन भेज सकते हैं, वे सब प्रमाणीकरण वाला पाथ (/execute) उपयोग करते हैं।

• प्रमाणीकरण वाला पाथ ज्यों-का-त्यों है। /execute अब भी Bearer टोकन और Script की Execute अनुमति माँगता है। बिना प्रमाणीकरण होने वाला केवल /execute/anonymous यह एक पाथ है।
• यह टोकन नहीं लेता। टोकन भेजने पर भी वह अनदेखा कर दिया जाता है और निष्पादन हमेशा लेखक की पहचान से होता है। कॉलर की पहचान से चलाना हो, तो /execute उपयोग करें।
• दोनों गेट से गुज़रना ज़रूरी है। anonymousCallEnabled false हो तो कॉल अप्रमाणित पहुँच के रूप में अस्वीकृत हो जाती है, और directCallEnabled false हो तो सीधी कॉल रुकी होने के कारण अस्वीकृत हो जाती है। लौटने वाला कोड इस बात पर निर्भर करता है कि कॉल किस गेट पर अटकी है (त्रुटियाँ देखें)। अनाम की अनुमति है या नहीं, यह पहले देखा जाता है, इसलिए अनधिकृत कॉलर उस Script की सेटिंग की स्थिति पता नहीं कर सकता।
• इसके आगे सब कुछ /execute जैसा ही है। अनुरोध का HTTP मेथड definition.method से मेल खाना चाहिए, और यह Organization के Script निष्पादन कोटे को खर्च करता है तथा उपयोग के रूप में मापा जाता है।
• यह पाथ प्रमाणीकरण वाले निष्पादन पथ जैसे उसी Script होस्ट (https://script.weegloo.com/v1) पर है।

निष्पादन लेखक की पहचान से होता है

कॉलर न होने के कारण निष्पादन उस उपयोगकर्ता की पहचान से होता है जिसने वह Script बनाई थी (sys.createdBy)।

• Script के भीतर बनाए या बदले गए Content और Media का createdBy तथा updatedBy लेखक ही दर्ज होता है (अनाम कॉलर नहीं। श्रेय देने के लिए कोई दूसरी पहचान नहीं होती)।
• where का createdBy: ":self" भी कॉलर पर नहीं, बल्कि लेखक पर हल होता है। प्रमाणित कॉलर को मानकर लिखे गए स्वामित्व फ़िल्टर को ज्यों-का-त्यों छोड़कर अनाम चालू करने पर चुपचाप लेखक के संसाधन खुल जाते हैं, इसलिए ऐसी परिभाषा शुरू से ही सेव नहीं होती (नीचे देखें)।

सेव के समय अतिरिक्त जाँच

जिस Script में anonymousCallEnabled true है, उस पर एक नियम और लगता है।

ऐसा इसलिए है कि अनाम कॉल में कॉलर की कोई पहचान नहीं होती, और :self लेखक पर हल हो जाता है। प्रमाणित कॉलर को मानकर लिखे गए स्वामित्व फ़िल्टर के चुपचाप भिद जाने को सेव के समय ही रोक दिया जाता है।

वास्तविक प्रमाणीकरण Script स्वयं करती है

इस पाथ पर प्लेटफ़ॉर्म द्वारा लगाया गया कोई प्रमाणीकरण नहीं है। URL जानने वाला कोई भी इसे कॉल कर सकता है, और वह कॉल Organization के Script निष्पादन कोटे को खर्च करती है, तथा इस पर कोई अलग रेट-लिमिट नहीं है। इसीलिए अनाम Script को अपने प्राप्त अनुरोध का सत्यापन स्वयं करना होता है।

• सबसे आगे Signature रखकर { /rawPayload } पर हस्ताक्षर की पुष्टि करें, और पास न होने पर Return से उसी जगह रोक दें। पूर्ण उदाहरण कुकबुक में webhook हस्ताक्षर सत्यापन में है।
• /now से replay window तक जाँच लेने पर बीते हुए अनुरोध को दोबारा भेजना भी रुक जाता है (/now)।
• अनाम Script में केवल वही रखें जो उस कॉलबैक को वास्तव में करना है। Script लेखक की अनुमति प्रत्यायोजित रूप में पाकर निष्पादित होती है, इसलिए जितना उसमें रखा गया है उतना बिना प्रमाणीकरण खुल जाता है (सुरक्षा मॉडल)।

ScriptLog

Script जब भी एक बार निष्पादित होता है, तब एक रिकॉर्ड पीछे छूट जाता है। यही रिकॉर्ड ScriptLog है। यह केवल पठन के लिए है और इसमें बनाने, संशोधन या विलोपन के एंडपॉइंट नहीं हैं। इसका पाथ /spaces/{spaceId}/scripts/{scriptId}/logs है, और बेस URL निष्पादन होस्ट नहीं, बल्कि CMA का https://cma.weegloo.com/v1 है। पढ़ने के लिए उस Script की Read अनुमति आवश्यक है।

{
  "sys": {
    "id": "3trmXRM7pLdV5Rz8kWq2NcHfJt4bYs",
    "type": "ScriptLog",
    "space": { "sys": { "id": "6jSUUAWT", "type": "Refer", "targetType": "Space" } },
    "script": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } },
    "trigger": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } },
    "requestId": "3trmXRM9wTbK4Vz7hLp2QsNdRf6cYm",
    "returned": true,
    "value": { "status": 200, "prompt": "गर्मियों की ड्रेस का उत्पाद विवरण 3 पंक्तियों में" },
    "success": true,
    "statusCode": 200,
    "durationMs": 195,
    "createdBy": { "sys": { "id": "3p4tcFbQYJNvYTBJf2rYKr42xegQLJ", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-07-15T12:41:03.902Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQYJNvYTBJf2rYKr42xegQLJ", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-07-15T12:41:03.902Z"
  }
}

सभी मान sys के भीतर होते हैं और कोई बॉडी प्रॉपर्टी नहीं होती। जिन कीज़ का मान नहीं होता, वे प्रतिक्रिया से हट जाती हैं।

trigger उसकी ओर इशारा करता है जिसने यह निष्पादन कराया। सीधी कॉल हो तो वह Script स्वयं, Webhook की लिंक्ड ऐक्शन से निष्पादित हुई हो तो वह Webhook, और Scheduler ने चलाया हो तो वह Scheduler।

requestId निष्पादन की प्रतिक्रिया के envelope के requestId जैसा ही मान है। कॉलर को मिली प्रतिक्रिया से उस निष्पादन का रिकॉर्ड खोजते समय इसी मान को आधार बनाया जाता है।

रिकॉर्ड निष्पादन समाप्त होने के बाद एक बार लिखा जाता है और बदलता नहीं। सफल निष्पादन 1 घंटे बाद और विफल निष्पादन 3 दिन बाद मिट जाता है। उससे अधिक समय तक रखने योग्य मानों को Script के भीतर Content के रूप में सहेजें।

createdBy बताता है कि वह निष्पादन किस पहचान से किया गया। Weegloo User टोकन से बुलाए गए निष्पादन में वह उपयोगकर्ता होता है, और सदस्य (ServiceUser) टोकन से बुलाए गए निष्पादन में वह सदस्य। जिस निष्पादन में कोई कॉलर नहीं होता, उसकी पहचान ट्रिगर से आती है। अनाम निष्पादन में वह उस Script का लेखक होता है, Scheduler द्वारा चलाए गए निष्पादन में उस Scheduler को बनाने वाला उपयोगकर्ता (जो Script के लेखक से अलग हो सकता है), और Webhook द्वारा निष्पादित कराए जाने पर उस Webhook को बनाने वाला उपयोगकर्ता। Webhook का runAs केवल यह तय करता है कि Script के भीतर के काम किसके नाम से होते हैं, और इस लॉग का श्रेय नहीं बदलता।

त्रुटियाँ

ये कोड Script को कॉल करते या हटाते समय मिलते हैं। परिभाषा सेव करते समय मिलने वाले कोड निष्पादन सिमेंटिक्स, बाधाएँ, सुरक्षा की त्रुटियाँ में हैं, मान अभिव्यक्ति के नियम तोड़ने वाले कोड मान अभिव्यक्ति की त्रुटियाँ में हैं, और हर संसाधन में समान रूप से मिलने वाले कोड सामान्य त्रुटियाँ में हैं।

API

नीचे दिए गए पाँच एंडपॉइंट (सूची·पठन·निर्माण·संशोधन·विलोपन) का बेस URL CMA का https://cma.weegloo.com/v1 है, और Authorization हेडर में CMA को प्रमाणित करने वाला Bearer टोकन आवश्यक है। संशोधन के समय, ऑप्टिमिस्टिक कन्करेंसी कंट्रोल के लिए X-Weegloo-Version हेडर (वर्तमान संसाधन का sys.version) भी भेजना ज़रूरी है। सबसे नीचे दिए गए ScriptLog पढ़ने वाले दो एंडपॉइंट भी वही CMA बेस URL उपयोग करते हैं।

निष्पादन वाले दो एंडपॉइंट का बेस URL समर्पित Script होस्ट https://script.weegloo.com/v1 है। प्रमाणित निष्पादन (/execute) Weegloo User पहचान का Bearer टोकन और सदस्य (ServiceUser) पहचान का Bearer टोकन, दोनों स्वीकार करता है, और चाहे इनमें से कोई भी हो, कॉलर के पास उस Script की Execute अनुमति आवश्यक है।

केवल अनाम निष्पादन (/execute/anonymous) अपवाद है, जो प्रमाणीकरण हेडर नहीं माँगता। यह उसी Script होस्ट पर है, और उस तक तभी पहुँचा जा सकता है जब उस Script ने anonymousCallEnabled चालू रखा हो (ऊपर अनाम कॉल देखें)।

ऊपर दिए प्रमाणित निष्पादन के उदाहरण की प्रतिक्रिया में return नहीं है। ऐसा इसलिए कि लक्षित Script किसी मान को धारण करने वाले Return तक पहुँचे बिना ही समाप्त हो गया (ऐसी स्थिति में statusCode का डिफ़ॉल्ट मान 200 होता है)। अनाम निष्पादन के उदाहरण की तरह Return से कोई मान लौटाया जाए, तो प्रतिक्रिया में return (या Return.isError सत्य होने पर error) आता है। प्रतिक्रिया के पूरे नियम Script अवलोकन के अनुरोध और प्रतिक्रिया भाग में दिए गए हैं।

संबंधित दस्तावेज़

• Script अवलोकन: शीर्ष-स्तरीय ScriptDefinition संरचना, अनुरोध और प्रतिक्रिया, तथा एक निष्पादन को मिलने वाले समय को कवर करता है।
• Statement कैटलॉग: statements में डाले जाने वाले हर statement के फ़ील्ड और परिणाम को कवर करता है।
• मान अभिव्यक्ति: { /pointer } संदर्भ और JsonLogic संक्रियाओं को कवर करता है।
• निष्पादन सिमेंटिक्स, बाधाएँ, सुरक्षा: स्थैतिक बाधाएँ, प्रति प्लान संख्या सीमा, तथा अनुमति और सुरक्षा मॉडल को कवर करता है।
• SpaceRole और ServiceUserRole: किसी role को Script की ऐक्शन अनुमतियाँ (Execute सहित) देने का तरीका कवर करते हैं।