Recurso Script y endpoints

Script es un endpoint de backend declarativo que el frontend invoca por HTTP (su concepto y estructura de nivel superior se tratan en Descripción general de Script). Esta página trata la estructura sys y las propiedades de cuerpo del recurso Script, la especificación de los endpoints HTTP que crean y ejecutan un Script, y el ScriptLog, que es el registro de cada ejecución.

Crear y gestionar un Script (listar, consultar, crear, modificar, eliminar) se hace en CMA (https://cma.weegloo.com/v1). De la ejecución se encarga la ruta de ejecución del host de Script dedicado (https://script.weegloo.com/v1), y esa única ruta de ejecución acepta los dos tokens: el de Weegloo User y el del miembro (ServiceUser) que se ha registrado en el producto. ACMA no tiene API de Script, y tampoco la tienen las API de entrega de solo lectura (CDA, ACDA).

Script es un recurso que tiene version y es un recurso facturable sujeto a un límite de recuento por plan. Sin embargo, a diferencia de Content o Media, no tiene estado de publicación. Su sys no tiene propiedades relacionadas con la publicación como status o publish, y con cada cambio solo sube version. Como no existe el concepto de publicar ni de anular la publicación, la eliminación también se produce de inmediato sin anular la publicación previamente.

Estructura del recurso

A continuación se muestra la respuesta de consulta única del Script "t6-http". Junto con sys (propiedades del sistema), tiene como propiedades de cuerpo name, definition y las que abren y cierran las rutas de invocación, directCallEnabled y 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"
      }
    ]
  }
}

Claves principales:

• sys.id: identificador único del Script. Se coloca en {scriptId} de las rutas de consulta única, modificación, eliminación y ejecución.
• name: nombre del Script (de 1 a 64 caracteres). Se usa en la lista en pantalla y para la identificación de administración.
• definition: el ScriptDefinition que declara qué hace este Script. Se compone del método de invocación (method), el array de statements (statements) y un esquema de payload opcional (payloadSchema). Su estructura detallada se trata más abajo en Definición y nombre y en la estructura de nivel superior en Descripción general de Script.
• directCallEnabled: indica si este Script se puede invocar directamente mediante /execute (booleano; si se omite, true). Si es false, la invocación directa se rechaza. Las demás rutas para ejecutar este Script se mantienen sin cambios. La acción vinculada (script) de un Webhook y un Scheduler no pasan por este endpoint, así que lo ejecutan igualmente.
• anonymousCallEnabled: indica si este Script se puede invocar sin autenticación mediante /execute/anonymous (booleano; si se omite, false). Al activarlo, incluso un tercero que no puede adjuntar un token puede ejecutar este Script por esa ruta, y la ejecución se realiza con la identidad del autor. Las condiciones y las reglas de guardado se tratan más abajo en Llamada anónima.

Tenga en cuenta que sys no tiene status, publish ni archive. Script no es un recurso que se publique en una ruta de entrega, sino un recurso que se crea y ejecuta en las API de administración.

Propiedades del sistema (sys)

Todo Script incluye propiedades del sistema comunes en el objeto sys. space, createdBy y updatedBy se incluyen con la forma Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

El status (estado de publicación) y el publish (historial de publicación) que están en el sys de Content, Content Type y Media no existen en un Script, porque un Script no se publica. Tampoco tiene la propiedad archive. Por eso, el version de un Script aumenta puramente según el número de creaciones y modificaciones, sin ninguna publicación.

Definición y nombre (name, definition)

Las propiedades de cuerpo de un Script son cuatro: name, definition, directCallEnabled y anonymousCallEnabled.

Claves de definition (ScriptDefinition):

Los tipos y campos de cada statement que se coloca en el array statements se tratan en Catálogo de statements, y las expresiones { /pointer } que hacen fluir los valores se tratan en Expresiones de valor.

En el ejemplo "t6-http" anterior, el definition tiene method Post: invoca una API externa con un statement Http y luego devuelve ese resultado con un statement Return. Un statement con llamada externa, como Http, declara su parte de tiempo, y esa cantidad se suma al tiempo concedido a una ejecución (véase El tiempo concedido a una ejecución).

Restricciones

Las restricciones estáticas anteriores se comprueban en el momento de guardar (crear/modificar), y una infracción hace que se rechace el guardado. El número de llamadas externas y el total de statements no son errores de validación, sino límites de plan, así que la misma definición sí se permite en un plan superior.

Al guardar también se comprueban los permisos y el tipo de recurso.

• Se comprueba si el autor tiene realmente los permisos de recurso y de acción que usan esos statements (si falta alguno, se rechaza el guardado; véase Errores). Los statements que leen miembros (ServiceUser) no se comprueban con el mapa de permisos, sino con SETTING_SERVICE_LOGIN en el settings del SpaceRole.
• Si contiene algún statement que modifica un miembro (ServiceUser), se rechaza el guardado. Este recurso solo se puede leer desde un Script, así que no se puede guardar con ningún rol.

Las reglas detalladas, el presupuesto de tiempo y los límites de longitud de los valores que se comprueban durante la ejecución se tratan en Semántica de ejecución, restricciones y seguridad.

El Script es un recurso facturable y el número por Organization está limitado por plan (Free 10 / Basic 30 / Pro 100 / Enterprise ilimitado). Cuando se alcanza el límite, se rechaza la creación de un nuevo Script (véase límites de recuento por plan).

Llamada anónima (anonymousCallEnabled)

Si anonymousCallEnabled se deja en true, ese Script también se ejecuta por una ruta dedicada sin autenticación.

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

Los casos en los que esto hace falta son raros. Es un mecanismo para terceros que tienen que enviarnos un callback, como una pasarela de pago (PG, MoR), pero que no admiten cabeceras personalizadas y no tienen forma de adjuntar un Access Token. Todos los llamantes que sí pueden adjuntar un token usan la ruta autenticada (/execute).

• La ruta autenticada no cambia. /execute sigue exigiendo un token Bearer y el permiso Execute de Script. Lo único que queda sin autenticación es esa única ruta, /execute/anonymous.
• No acepta ningún token. Aunque se envíe un token, se ignora y la ejecución es siempre con la identidad del autor. Para ejecutar con la identidad del llamante se usa /execute.
• Hay que pasar las dos puertas. Si anonymousCallEnabled es false, se rechaza por acceso no autenticado; si directCallEnabled es false, se rechaza porque la invocación directa está bloqueada. El código que se devuelve difiere según la puerta en la que se haya quedado la llamada (véase Errores). Como primero se mira si se permite el anonimato, un llamante sin credenciales no puede averiguar el estado de configuración de ese Script.
• A partir de ahí es igual que /execute. El método HTTP de la petición debe coincidir con definition.method, y consume la cuota de ejecución de Script de la Organization y se contabiliza como uso.
• Esta ruta está en el mismo host de Script que la ruta de ejecución autenticada (https://script.weegloo.com/v1).

Se ejecuta con la identidad del autor

Como no hay llamante, la ejecución se realiza con la identidad del usuario que creó ese Script (sys.createdBy).

• El createdBy y el updatedBy de los Content y Media que se crean o modifican dentro del Script quedan como el autor (no como el llamante anónimo: no hay otra identidad a la que atribuirlo).
• El createdBy: ":self" de where también se resuelve como el autor, no como el llamante. Si se activa el anonimato dejando tal cual un filtro de propiedad escrito dando por supuesto un llamante autenticado, quedarían abiertos en silencio los recursos del autor, así que una definición así no se guarda de entrada (véase más abajo).

Comprobaciones adicionales al guardar

A un Script con anonymousCallEnabled en true se le añade una regla más.

Es porque una llamada anónima no tiene identidad de llamante y :self se resuelve como el autor. Así se impide, en el momento de guardar, que se abra en silencio un filtro de propiedad escrito dando por supuesto un llamante autenticado.

La autenticación efectiva la hace el propio Script

Esta ruta no tiene ninguna autenticación puesta por la plataforma. Cualquiera que conozca la URL puede llamarla, y esa llamada consume la cuota de ejecución de Script de la Organization sin un rate limit propio. Por eso, un Script anónimo debe verificar por sí mismo la petición que recibe.

• Coloque al principio un Signature para comprobar la firma sobre { /rawPayload } y, si no pasa, corte ahí mismo con un Return. El ejemplo completo está en la verificación de la firma de un webhook del Cookbook.
• Si además comprueba la replay window con /now, también evita que se reenvíe una petición pasada (/now).
• En un Script anónimo se pone solo lo que ese callback tiene que hacer realmente. Como un Script se ejecuta con los permisos del autor delegados, todo lo que se ponga queda abierto sin autenticación (modelo de seguridad).

ScriptLog

Cada vez que un Script se ejecuta queda un registro. Ese registro es el ScriptLog. Es de solo consulta y no tiene endpoints de creación, modificación ni eliminación. Su ruta es /spaces/{spaceId}/scripts/{scriptId}/logs, y su URL base no es la del host de ejecución, sino la de CMA, https://cma.weegloo.com/v1. Para leerlo se necesita el permiso Read de ese Script.

{
  "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 líneas de descripción para un vestido de verano" },
    "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"
  }
}

Todos los valores están dentro de sys y no hay propiedades de cuerpo. Las claves sin valor se omiten en la respuesta.

trigger apunta a lo que provocó esta ejecución. Si fue una invocación directa, es el propio Script; si se ejecutó como acción vinculada de un Webhook, ese Webhook; y si lo lanzó un Scheduler, ese Scheduler.

requestId es el mismo valor que el requestId del sobre de respuesta de la ejecución. Cuando el llamante busca el registro de esa ejecución a partir de la respuesta que recibió, usa este valor como referencia.

El registro se escribe una sola vez al terminar la ejecución y luego no cambia. Las ejecuciones correctas desaparecen al cabo de 1 hora y las fallidas, al cabo de 3 días. Lo que haya que conservar más tiempo, guárdelo como Content desde el propio Script.

createdBy apunta a la identidad con la que se llevó a cabo esa ejecución. Una ejecución invocada con un token de Weegloo User es ese usuario, y una invocada con un token de miembro (ServiceUser) es ese miembro. En las ejecuciones sin llamante, la identidad viene del disparador: una ejecución anónima es el autor de ese Script; una ejecución lanzada por un Scheduler es el usuario que creó ese Scheduler (que puede no ser el autor del Script); y la que ejecuta un Webhook es el usuario que creó ese Webhook. El runAs de un Webhook solo decide en nombre de quién se realizan las operaciones dentro del Script, y no cambia la atribución de este log.

Errores

Códigos que aparecen al invocar o eliminar un Script. Los códigos que aparecen al guardar la definición están en los errores de Semántica de ejecución, restricciones y seguridad; los códigos por infringir las reglas de las expresiones de valor, en los errores de Expresiones de valor; y los códigos comunes a todos los recursos, en Errores comunes.

API

La URL base de los cinco endpoints de más abajo (listar, consultar, crear, modificar y eliminar) es la de CMA, https://cma.weegloo.com/v1, y en la cabecera Authorization se necesita un token Bearer que autentique contra CMA. La modificación debe enviar además la cabecera X-Weegloo-Version (el sys.version del recurso actual) para el control de concurrencia optimista. Las dos consultas de ScriptLog del final usan esa misma URL base de CMA.

La URL base de los dos endpoints de ejecución es la del host de Script dedicado, https://script.weegloo.com/v1. La ejecución autenticada (/execute) acepta los dos tokens Bearer, el de la identidad de Weegloo User y el de la identidad de miembro (ServiceUser), y en cualquiera de los dos casos el llamante necesita el permiso Execute de ese Script.

Solo la ejecución anónima (/execute/anonymous) es la excepción y no exige cabecera de autenticación. Está en el mismo host de Script, y únicamente se alcanza cuando ese Script tiene activado anonymousCallEnabled (véase Llamada anónima más arriba).

La respuesta del ejemplo de ejecución autenticada anterior no tiene return, porque el Script de destino terminó sin llegar a un Return que contenga un valor (en ese caso statusCode toma el valor predeterminado 200). Si se devuelve un valor con Return, como en el ejemplo de ejecución anónima, la respuesta incluye return (o error si Return.isError es verdadero). Las reglas completas de la respuesta se tratan en la sección de solicitud y respuesta de Descripción general de Script.

Documentos relacionados

• Descripción general de Script: trata la estructura de nivel superior ScriptDefinition, la solicitud y la respuesta, y el tiempo concedido a una ejecución.
• Catálogo de statements: trata los campos y resultados de cada statement que se coloca en statements.
• Expresiones de valor: trata las referencias { /pointer } y las operaciones de JsonLogic.
• Semántica de ejecución, restricciones y seguridad: trata las restricciones estáticas, los límites de recuento por plan y el modelo de permisos y seguridad.
• SpaceRole y ServiceUserRole: tratan cómo otorgar los permisos de acción de un Script (incluido Execute) a un rol.