Script-Ressource und Endpunkte

Ein Script ist ein deklarativer Backend-Endpunkt, den das Frontend über HTTP aufruft (Konzept und oberste Struktur werden in der Script-Übersicht behandelt). Diese Seite behandelt die sys-Struktur und die Body-Eigenschaften der Script-Ressource, die Spezifikation der HTTP-Endpunkte, die ein Script verfassen und ausführen, sowie das Ausführungsprotokoll ScriptLog.

Das Erstellen und Verwalten eines Script (auflisten, abfragen, erstellen, ändern, löschen) erfolgt auf der CMA (https://cma.weegloo.com/v1). Für die Ausführung ist der Ausführungsweg auf dem eigenen Script-Host (https://script.weegloo.com/v1) zuständig, und dieser eine Ausführungsweg nimmt beide Token an: das eines Weegloo User und das eines Mitglieds, das sich für das Produkt registriert hat (ServiceUser). Auf der ACMA gibt es keine Script-API, und in den nur lesenden Auslieferungs-APIs (CDA, ACDA) ebenfalls nicht.

Ein Script ist eine Ressource mit einer version und zugleich eine abrechenbare Ressource, die einer plangebundenen Mengenbegrenzung unterliegt. Anders als Content oder Media hat es jedoch keinen Veröffentlichungsstatus. In sys gibt es keine veröffentlichungsbezogenen Eigenschaften wie status oder publish; bei jeder Änderung steigt lediglich die version. Da es kein Konzept von Veröffentlichung oder Zurücknahme der Veröffentlichung gibt, erfolgt auch das Löschen sofort, ohne vorher die Veröffentlichung zurückzunehmen.

Ressourcenstruktur

Im Folgenden sehen Sie die Antwort der Einzelabfrage des Script "t6-http". Neben sys (Systemeigenschaften) besitzt es als Body-Eigenschaften name, definition sowie directCallEnabled und anonymousCallEnabled, die die Aufrufwege öffnen und schließen.

{
  "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"
      }
    ]
  }
}

Wichtige Schlüssel:

• sys.id: Eindeutige Kennung des Script. Wird in den Pfaden für Einzelabfrage, Änderung, Löschung und Ausführung als {scriptId} eingesetzt.
• name: Name des Script (1-64 Zeichen). Wird in der Bildschirmliste und zur Identifikation bei der Verwaltung verwendet.
• definition: Die ScriptDefinition, die deklariert, was dieses Script tut. Sie besteht aus der Aufrufmethode (method), dem Statement-Array (statements) und einem optionalen Payload-Schema (payloadSchema). Die detaillierte Struktur wird unten unter Definition und Name sowie in der obersten Struktur der Script-Übersicht behandelt.
• directCallEnabled: Ob dieses Script direkt über /execute aufgerufen werden kann (boolean, bei Weglassen true). Ist es false, wird der direkte Aufruf abgelehnt. Die anderen Wege, dieses Script auszuführen, bleiben erhalten. Die Anbindungsaktion (script) eines Webhook und ein Scheduler passieren diesen Endpunkt nicht und führen es daher unverändert aus.
• anonymousCallEnabled: Ob dieses Script ohne Authentifizierung über /execute/anonymous aufgerufen werden kann (boolean, bei Weglassen false). Schalten Sie es ein, kann auch ein Dritter, der kein Token mitsenden kann, dieses Script über diesen Weg ausführen, und die Ausführung erfolgt unter der Identität des Autors. Die Bedingungen und die Speicherregeln werden unten unter Anonymer Aufruf behandelt.

Beachten Sie, dass sys kein status, publish oder archive enthält. Ein Script ist keine Ressource, die auf einen Auslieferungspfad veröffentlicht wird, sondern eine Ressource, die Sie über die Management-API verfassen und ausführen.

Systemeigenschaften (sys)

Jedes Script führt gemeinsame Systemeigenschaften im sys-Objekt. space, createdBy und updatedBy werden in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) angegeben.

Das status (Veröffentlichungsstatus) und das publish (Veröffentlichungsverlauf), die im sys von Content, Content Type und Media vorhanden sind, gibt es bei einem Script nicht, da ein Script nicht veröffentlicht wird. Auch eine archive-Eigenschaft gibt es nicht. Daher steigt die version eines Script rein mit der Anzahl der Erstellungen und Änderungen, ganz ohne Veröffentlichung.

Definition und Name (name, definition)

Ein Script hat vier Body-Eigenschaften: name, definition, directCallEnabled und anonymousCallEnabled.

Schlüssel von definition (ScriptDefinition):

Die Arten und Felder der einzelnen Statements, die Sie in das statements-Array einfügen, werden im Statement-Katalog behandelt, und die { /pointer }-Ausdrücke, die Werte weiterreichen, werden in den Wertausdrücken behandelt.

Im Beispiel "t6-http" oben hat definition das method Post; es ruft mit einem Http-Statement eine externe API auf und gibt anschließend mit einem Return-Statement das Ergebnis zurück. Ein Statement mit einem externen Aufruf wie Http deklariert seinen eigenen Zeitanteil, und genau dieser wird zu der Zeit addiert, die einer einzelnen Ausführung zur Verfügung steht (siehe Die Zeit für eine einzelne Ausführung).

Einschränkungen

Die statischen Einschränkungen oben werden zum Speicherzeitpunkt (Erstellen/Ändern) geprüft, und bei einem Verstoß wird das Speichern abgelehnt. Die Anzahl der externen Aufrufe und die Gesamtzahl der Statements sind keine Validierungsfehler, sondern Tariflimits, daher ist dieselbe Definition in einem höheren Tarif erlaubt.

Beim Speichern werden außerdem die Berechtigungen und die Ressourcenarten geprüft.

• Es wird geprüft, ob der Autor die Ressourcen- und Aktionsberechtigungen, die diese Statements nutzen, tatsächlich besitzt (fehlt auch nur eine, wird das Speichern abgelehnt; siehe Fehler). Ein Statement, das ein Mitglied (ServiceUser) liest, wird nicht über die Berechtigungs-Map, sondern über SETTING_SERVICE_LOGIN in den settings der SpaceRole geprüft.
• Enthält die Definition ein Statement, das ein Mitglied (ServiceUser) ändert, wird das Speichern abgelehnt. Diese Ressource ist in einem Script nur lesbar und lässt sich daher mit keiner Rolle speichern.

Die detaillierten Regeln, das Zeitbudget und die während der Ausführung geprüften Obergrenzen für Wertlängen werden unter Ausführungssemantik, Einschränkungen und Sicherheit behandelt.

Ein Script ist eine abrechenbare Ressource, und die Anzahl pro Organization ist je nach Plan begrenzt (Free 10 / Basic 30 / Pro 100 / Enterprise unbegrenzt). Sobald das Limit erreicht ist, wird das Erstellen eines neuen Script abgelehnt (siehe Anzahllimits pro Plan).

Anonymer Aufruf (anonymousCallEnabled)

Setzen Sie anonymousCallEnabled auf true, wird dieses Script auch über einen eigenen Weg ohne Authentifizierung ausgeführt.

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

Der Fall, dass Sie das brauchen, ist selten. Es ist eine Vorrichtung für Dritte, die uns einen Callback senden müssen, aber keine benutzerdefinierten Header unterstützen und daher kein Access Token mitsenden können, etwa Zahlungsdienstleister (PG, MoR). Jeder Aufrufer, der ein Token mitsenden kann, verwendet den authentifizierten Weg (/execute).

• Der authentifizierte Weg bleibt unverändert. /execute verlangt weiterhin ein Bearer-Token und die Execute-Berechtigung auf das Script. Ohne Authentifizierung ist einzig dieser eine Weg, /execute/anonymous.
• Es nimmt kein Token an. Auch ein mitgesendetes Token wird ignoriert, und die Ausführung erfolgt stets unter der Identität des Autors. Um unter der Identität des Aufrufers auszuführen, verwenden Sie /execute.
• Es müssen beide Gates passiert werden. Ist anonymousCallEnabled false, wird der Aufruf als nicht authentifizierter Zugriff abgelehnt; ist directCallEnabled false, wird er abgelehnt, weil der direkte Aufruf gesperrt ist. Der zurückgegebene Code richtet sich danach, an welchem Gate der Aufruf hängen bleibt (siehe Fehler). Da zuerst geprüft wird, ob anonyme Aufrufe erlaubt sind, kann ein unberechtigter Aufrufer den Konfigurationszustand dieses Script nicht herausfinden.
• Danach ist es dasselbe wie /execute. Die HTTP-Methode der Anfrage muss mit definition.method übereinstimmen, und der Aufruf verbraucht das Script-Ausführungskontingent der Organization und wird als Nutzung gemessen.
• Diesen Weg gibt es auf demselben Script-Host wie den authentifizierten Ausführungsweg (https://script.weegloo.com/v1).

Es läuft unter der Identität des Autors

Da es keinen Aufrufer gibt, erfolgt die Ausführung unter der Identität des Benutzers, der dieses Script erstellt hat (sys.createdBy).

• Das createdBy und updatedBy von Content und Media, die innerhalb des Script erstellt oder geändert werden, wird auf den Autor gesetzt (nicht auf den anonymen Aufrufer; es gibt keine andere Identität, der man es zuschreiben könnte).
• Auch createdBy: ":self" in where wird nicht zum Aufrufer, sondern zum Autor aufgelöst. Belassen Sie einen Eigentümerfilter, der einen authentifizierten Aufrufer voraussetzt, und schalten anonyme Aufrufe ein, öffnen sich stillschweigend die Ressourcen des Autors; eine solche Definition wird daher von vornherein nicht gespeichert (siehe unten).

Zusätzliche Prüfungen beim Speichern

Für ein Script mit anonymousCallEnabled gleich true gilt eine weitere Regel.

Denn bei einem anonymen Aufruf gibt es keine Aufrufer-Identität, sodass :self zum Autor aufgelöst wird. Damit wird schon beim Speichern verhindert, dass ein Eigentümerfilter, der einen authentifizierten Aufrufer voraussetzt, stillschweigend durchlässig wird.

Die tatsächliche Authentifizierung übernimmt das Script selbst

Auf diesem Weg gibt es keine Authentifizierung, die die Plattform vorschaltet. Jeder, der die URL kennt, kann aufrufen, dieser Aufruf verbraucht das Script-Ausführungskontingent der Organization, und es gibt kein eigenes Rate-Limit. Deshalb muss ein anonymes Script die Anfrage, die es empfängt, selbst prüfen.

• Setzen Sie ganz vorne ein Signature, prüfen die Signatur über { /rawPayload } und brechen bei Nichtbestehen mit Return an dieser Stelle ab. Ein vollständiges Beispiel finden Sie unter Webhook-Signaturprüfung im Cookbook.
• Prüfen Sie mit /now zusätzlich das Replay-Window, verhindern Sie auch das erneute Senden einer alten Anfrage (siehe /now).
• Nehmen Sie in ein anonymes Script nur das auf, was dieser Callback wirklich tun muss. Ein Script läuft mit den delegierten Berechtigungen des Autors, daher ist genau so viel ohne Authentifizierung geöffnet, wie Sie hineinlegen (siehe Sicherheitsmodell).

ScriptLog

Jedes Mal, wenn ein Script ausgeführt wird, bleibt ein Protokolleintrag zurück. Dieser Eintrag ist ein ScriptLog. Er ist nur abfragbar und hat keine Endpunkte zum Erstellen, Ändern oder Löschen. Der Pfad lautet /spaces/{spaceId}/scripts/{scriptId}/logs, und die Basis-URL ist nicht der Ausführungs-Host, sondern die der CMA, https://cma.weegloo.com/v1. Zum Lesen ist die Read-Berechtigung auf dieses Script erforderlich.

{
  "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": "Produktbeschreibung für ein Sommerkleid in 3 Zeilen" },
    "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"
  }
}

Alle Werte liegen in sys, Body-Eigenschaften gibt es nicht. Ein Schlüssel ohne Wert fehlt in der Antwort.

trigger zeigt auf das, was diese Ausführung ausgelöst hat. Bei einem direkten Aufruf ist es dieses Script selbst, bei einer Ausführung über die Anbindungsaktion eines Webhook dieses Webhook, und bei einem Lauf durch einen Scheduler dieser Scheduler.

Das requestId ist derselbe Wert wie das requestId im Antwort-Envelope der Ausführung. Wenn der Aufrufer ausgehend von der erhaltenen Antwort den Protokolleintrag dieser Ausführung sucht, verwendet er diesen Wert als Suchkriterium.

Der Eintrag wird nach dem Ende der Ausführung einmal geschrieben und ändert sich nicht mehr. Eine erfolgreiche Ausführung verschwindet nach 1 Stunde, eine fehlgeschlagene nach 3 Tagen. Werte, die länger erhalten bleiben müssen, speichern Sie innerhalb des Script als Content.

createdBy zeigt an, unter welcher Identität diese Ausführung erfolgt ist. Eine Ausführung, die mit einem Weegloo-User-Token aufgerufen wurde, gehört diesem Benutzer, eine Ausführung mit dem Token eines Mitglieds (ServiceUser) diesem Mitglied. Bei einer Ausführung ohne Aufrufer kommt die Identität vom Trigger. Bei einer anonymen Ausführung ist es der Autor dieses Script, bei einer Ausführung durch einen Scheduler der Benutzer, der diesen Scheduler erstellt hat (kann vom Autor des Script abweichen), und bei einer Ausführung durch ein Webhook der Benutzer, der dieses Webhook erstellt hat. Das runAs eines Webhook legt nur fest, unter wessen Namen die Arbeiten innerhalb des Script erfolgen, und ändert die Zuschreibung dieses Logs nicht.

Fehler

Dies sind die Codes, die beim Aufrufen oder Löschen eines Script auftreten. Die Codes, die beim Speichern der Definition auftreten, stehen unter Fehler in Ausführungssemantik, Einschränkungen und Sicherheit, die Codes für Verstöße gegen die Regeln der Wertausdrücke unter Fehler bei den Wertausdrücken, die Codes, die allen Ressourcen gemeinsam sind, unter Gemeinsame Fehler.

API

Die Basis-URL der folgenden fünf Endpunkte (auflisten, abfragen, erstellen, ändern, löschen) ist die der CMA, https://cma.weegloo.com/v1, und im Authorization-Header ist ein Bearer-Token zur Authentifizierung an der CMA erforderlich. Bei der Änderung muss zur optimistischen Nebenläufigkeitskontrolle der Header X-Weegloo-Version (die sys.version der aktuellen Ressource) mitgesendet werden. Auch die beiden ScriptLog-Abfragen ganz unten verwenden dieselbe CMA-Basis-URL.

Die Basis-URL der beiden Ausführungsendpunkte ist der eigene Script-Host, https://script.weegloo.com/v1. Die authentifizierte Ausführung (/execute) nimmt beide Bearer-Token an: das der Weegloo-User-Identität und das der Mitglieds-Identität (ServiceUser); in beiden Fällen benötigt der Aufrufer die Execute-Berechtigung auf dieses Script.

Einzige Ausnahme ist die anonyme Ausführung (/execute/anonymous): Sie verlangt keinen Authentifizierungsheader. Sie liegt auf demselben Script-Host und ist nur erreichbar, wenn dieses Script anonymousCallEnabled eingeschaltet hat (siehe Anonymer Aufruf oben).

Die Antwort im Beispiel für die authentifizierte Ausführung oben enthält kein return, weil das betreffende Script endete, ohne ein Return mit einem Wert zu erreichen (in diesem Fall ist statusCode standardmäßig 200). Gibt ein Return wie im Beispiel für die anonyme Ausführung einen Wert zurück, enthält die Antwort return (oder error, wenn Return.isError wahr ist). Die vollständigen Regeln für die Antwort werden im Abschnitt Anfrage und Antwort der Script-Übersicht behandelt.

Verwandte Dokumente

• Script-Übersicht: Behandelt die oberste ScriptDefinition-Struktur, Anfrage und Antwort sowie die Zeit für eine einzelne Ausführung.
• Statement-Katalog: Behandelt die Felder und Ergebnisse der einzelnen Statements, die Sie in statements einfügen.
• Wertausdrücke: Behandelt { /pointer }-Referenzen und JsonLogic-Operationen.
• Ausführungssemantik, Einschränkungen und Sicherheit: Behandelt die statischen Einschränkungen, die Anzahllimits pro Plan sowie das Berechtigungs- und Sicherheitsmodell.
• SpaceRole und ServiceUserRole: Behandeln, wie die Aktionsberechtigungen eines Script (einschließlich Execute) einer Rolle zugewiesen werden.