Script

Script is a declarative backend endpoint that a frontend calls over HTTP. Rather than writing server code, you declare "what to do" as JSON and the WEEGLOO engine runs it for you. The goal is to replace, with a single Script, the typical backend plumbing that supports a frontend (a BFF, Backend-for-Frontend): authentication, guards, chained CRUD, external API calls, and value shaping.

This document set is the reference for Script syntax. The details of each part of the syntax are split across the pages in Documents in this group below.

Script is authored and executed on CMA (with the Weegloo User identity). Under the identity of a member who has signed up for the product (a ServiceUser), you can use it the same way on ACMA as well. The Script API exists only on these two management APIs (CMA, ACMA); it does not exist on the read-only delivery APIs (CDA, ACDA).

Mental model

• One Script is one HTTP endpoint. The call method (method) determines which Script runs.
• The body is a statements array. They run sequentially, top to bottom. This is just like the body of a function in ordinary programming.
• It is declaration, not code. You do not embed arbitrary code (FaaS); you compose predefined statement types. It is designed less for hand-authoring by a person and more for generation by an AI agent over MCP.
• Values flow through JSON Pointer templates. You reference the result of a previous step, the input payload, or a variable with { /pointer } and pass it to the next step. When you need a condition or a calculation, you use JsonLogic operators. The full rules are covered in Value Expressions.

Top-level structure (ScriptDefinition)

A single Script is defined by the following ScriptDefinition structure.

{
  "method": "Post",               // Get | Post | Put | Patch | Delete. The HTTP method matched on call (required)
  "payloadSchema": { /* ... */ }, // (optional) JSON Schema. If present, validates the request payload before execution
  "executionMode": "Sync",        // "Sync" | "Async" (required)
  "statements": [ /* Statement[]. Executed from top to bottom (required, at least 1) */ ]
}

The payload accepts JSON only. The call body is accessed through the /payload context root ({ /payload/... }). The call's request HTTP headers are referenced through the /headers root ({ /headers/... }, with lowercase keys). The full set of context roots is covered in Value Expressions.

Request and response

In the end, a Script returns the value of its Return statement to the caller. The shape of the response (or the Async polling result) is as follows.

{
  "requestId": "…",     // Execution identifier (for Async, poll for the result with this id)
  "durationMs": 1234,   // Execution time (ms)
  "statusCode": 200,    // The statusCode of the Return that was reached (default 200)
  "return": <value>     // Only when Return.isError is false. If the value is null, ""
  // "error": <value>   // Only when Return.isError is true (in which case "return" is absent). If the value is null, ""
}

• return and error never appear together. The isError of the Return statement decides which one it is.
• If the Script ends without reaching a Return statement, return and error are both absent and statusCode is the default (200).
• If a value is null, that field is emitted as an empty string "".

You control the response body and the status code with the Return statement's value, isError, and statusCode. For details, see Return in the Statement Catalog.

Execution modes: Sync and Async

• If there is external I/O, only Async is allowed. If any statement performs a network operation such as an Http external call (ExternalIo) or a Media file ingest (MediaIngest, from a url or base64), then executionMode must be Async; trying to save it as Sync is rejected at save time. This is so the request thread is not blocked by external latency.
• It is only a difference in where execution happens; either way, the result is the Return value.

The rules for how a given capability forces a mode, along with the applicable limits, are covered in Execution Semantics, Constraints, and Security.

Minimal example

It creates a post Content from the title and body in the request payload, publishes it right away, and then returns the sys.id it created.

{
  "method": "Post",
  "executionMode": "Sync",
  "statements": [
    { "type": "ResourceCreate", "resource": "Content",
      "contentType": { "sys": { "id": "ct_post" } },
      "fields": {
        "title": { "en-US": "{ /payload/fields/title }" },
        "body":  { "en-US": "{ /payload/fields/body }" }
      },
      "publish": true,
      "name": "post" },
 
    { "type": "Return", "value": { "id": "{ /post/sys/id }" }, "statusCode": 201 }
  ]
}

• ResourceCreate creates the Content and binds the result to the name post.
• Return returns { "id": <new Content id> } with 201.
• Why a Content's fields values are locale maps ({ "en-US": ... }) is covered in Locale maps in Value Expressions.

You'll find more varied scenarios in the Cookbook.

Documents in this group

• Value Expressions: Covers { /pointer } references, literals, JsonLogic operations and conditions, context roots, and locale maps. This is the heart of the syntax.
• Statement Catalog: Covers the fields and results of the 17 statement types (resource CRUD and reads, Http, SetVar, If, Loop, Parallel, Try, Return).
• Execution Semantics, Constraints, and Security: Covers execution order, guards, compensation, optimistic locking, errors, static constraints and plan limits, and the security model.
• Cookbook: Covers complete examples such as upsert, a credit guard, an LLM proxy, pagination, parallel execution, and a payment saga.
• Script Resource and Endpoints: Covers the sys structure of the Script resource and the specification of the HTTP endpoints for authoring and execution (/execute).

If this is your first time, we recommend reading from this page onward in the order Value Expressions, then Statement Catalog. The Cookbook is also worth skimming all the way through.