Ressource Script et endpoints

Script est un endpoint backend déclaratif qu'un frontend appelle via HTTP (son concept et sa structure de niveau supérieur sont traités dans Aperçu de Script). Cette page traite la structure sys et les propriétés de corps de la ressource Script, ainsi que la spécification des endpoints HTTP qui permettent d'écrire et d'exécuter un Script.

Un Script se manipule via deux API de gestion. Sur CMA (identité Weegloo User), vous pouvez tout faire : lister, lire, créer, modifier, supprimer, exécuter et sonder. Sur ACMA (identité d'un ServiceUser inscrit au produit), vous pouvez uniquement exécuter et sonder ; l'écriture (création, modification, suppression) est réservée à CMA. Les API de livraison en lecture seule (CDA, ACDA) n'ont pas de Script.

Un Script est une ressource dotée d'un version, et c'est une ressource facturable (Billable) soumise à une limite de nombre par plan. Toutefois, contrairement à Content ou Media, il n'a pas de statut de publication. Son sys ne comporte pas de propriétés liées à la publication telles que status ou publish, et seul version augmente à chaque changement. Comme il n'existe pas de notion de publication ni de dépublication, la suppression se fait elle aussi immédiatement, sans dépublication préalable.

Structure de la ressource

Voici la réponse de lecture unitaire du Script « t6-http ». Avec sys (propriétés système), il possède deux propriétés de corps, name et definition.

{
  "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",
  "definition": {
    "method": "Post",
    "executionMode": "Async",
    "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"
      }
    ]
  }
}

Propriétés principales :

• sys.id : identifiant unique du Script. Il s'insère dans le {scriptId} des chemins de lecture unitaire, de modification, de suppression et d'exécution.
• name : nom du Script (1 à 64 caractères). Utilisé dans la liste à l'écran et pour l'identification lors de la gestion.
• definition : le ScriptDefinition qui déclare ce que fait ce Script. Il se compose de la méthode d'appel (method), du mode d'exécution (executionMode), du tableau de statements (statements) et d'un schéma de payload facultatif (payloadSchema). Sa structure détaillée est traitée plus bas dans Définition et nom et dans la structure de niveau supérieur dans Script.

Notez que sys n'a ni status, ni publish, ni archive. Un Script n'est pas une ressource publiée sur un chemin de livraison ; c'est une ressource que l'on écrit et exécute via les API de gestion.

Propriétés système (sys)

Chaque Script porte des propriétés système communes dans l'objet sys. space, createdBy et updatedBy ont la forme Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

Le status (statut de publication) et le publish (historique de publication) présents dans le sys de Content, Content Type et Media ne figurent pas sur un Script, car un Script n'est pas publié. Il n'a pas non plus de propriété archive. Ainsi, le version d'un Script augmente purement au rythme du nombre de créations et de modifications, sans aucune publication.

Définition et nom (name, definition)

Un Script a deux propriétés de corps : name et definition.

Clés de definition (ScriptDefinition) :

Les types et les champs de chaque statement que l'on place dans le tableau statements sont traités dans le Catalogue des statements, et les expressions { /pointer } qui font circuler les valeurs sont traitées dans les Expressions de valeur.

Dans l'exemple « t6-http » ci-dessus, le definition a method valant Post et executionMode valant Async ; il appelle une API externe avec un statement Http, puis en renvoie le résultat avec un statement Return. Un Script comportant des I/O externes, comme le statement Http, doit obligatoirement avoir executionMode valant Async (voir Contraintes plus bas).

Contraintes

Les contraintes statiques ci-dessus sont vérifiées au moment de l'enregistrement (création/modification), et une violation entraîne le rejet de l'enregistrement. Lors de l'enregistrement, le système vérifie aussi si l'auteur détient réellement les permissions de ressource et d'action qu'utilisent ces statements (s'il en manque une seule, la requête est rejetée avec WGL403015). Les règles détaillées et le budget de temps sont traités dans Sémantique d'exécution, contraintes et sécurité.

Un Script est une ressource facturable (Billable) et le nombre par Organization est limité selon le plan (Free 3 / Basic 10 / Pro 50 / Enterprise illimité). Une fois la limite atteinte, la création d'un nouveau Script est refusée (voir les limites de nombre par plan).

API

L'URL de base des endpoints de liste, lecture, création, modification et suppression ci-dessous est celle de CMA, https://cma.weegloo.com/v1, et un jeton Bearer authentifiant auprès de CMA est requis dans l'en-tête Authorization. La modification doit aussi envoyer l'en-tête X-Weegloo-Version (le sys.version actuel de la ressource) pour le contrôle de concurrence optimiste.

L'exécution (/execute) et le polling (/executions/{requestId}) sont aussi proposés sur ACMA, aux mêmes chemins. Dans ce cas, l'URL de base est https://acma.weegloo.com/v1, et l'authentification se fait avec un jeton Bearer de l'identité ServiceUser. L'écriture (création, modification, suppression) n'existe pas sur ACMA et est réservée à CMA.

La réponse de complétion dans les exemples d'exécution et de polling ci-dessus n'a pas de return, car le Script visé s'est terminé sans atteindre de Return porteur d'une valeur (auquel cas statusCode vaut la valeur par défaut 200). Si un Return renvoie une valeur, la réponse contient return (ou error si Return.isError vaut vrai). L'ensemble des règles de la réponse est traité dans la section Requête et réponse de Script.

Documents liés

• Aperçu de Script : traite la structure ScriptDefinition de niveau supérieur, les modes d'exécution, ainsi que la requête et la réponse.
• Catalogue des statements : traite les champs et les résultats de chaque statement que l'on place dans statements.
• Expressions de valeur : traite les références { /pointer } et les opérations JsonLogic.
• Sémantique d'exécution, contraintes et sécurité : traite les contraintes statiques, les limites de nombre par plan, ainsi que le modèle de permissions et de sécurité.
• SpaceRole et ServiceUserRole : traitent la manière d'accorder à un rôle les permissions d'action d'un Script (Execute compris).