Skip to main content

Actions

Actions are the callable operations inside an integration. A capability uses an action step to execute them.

What Actions Do​

  • Read data (for example, lookup an order)
  • Write data (for example, cancel a subscription)
  • Trigger workflows (for example, create a ticket)

Supervised Execution​

The LLM never calls actions directly. The platform executes actions only when the journey and safety rules allow it.

Action Structure​

{
  "name": "Get Order Details",
  "slug": "get-details",
  "type": "read",
  "invocation": {
    "method": "GET",
    "endpoint": "/orders/{order_id}",
    "headers": {
      "Accept": "application/json"
    },
    "dynamic_headers": {
      "X-Request-ID": "$variables.request_id"
    }
  },
  "input_schema": {
    "order_id": {"type": "string", "description": "Order ID"}
  },
  "output_schema": {
    "id": {"type": "string"},
    "status": {"type": "string"}
  },
  "outcomes": [
    {"name": "found", "condition": "response.status == 200"},
    {"name": "not_found", "condition": "response.status == 404"}
  ],
  "settings": {
    "timeout_ms": 5000,
    "retries": 2
  },
  "safety": {
    "requires_confirmation": true,
    "audit_level": "detailed"
  }
}

Key Fields​

  • type: read or write
  • invocation: method, endpoint, headers
  • input_schema: shape and requirements for inputs
  • output_schema: shape of outputs for mapping and validation
  • outcomes: named outcomes used for branching in the DSL
  • settings: timeouts and retry policy
  • safety: governance controls

Outcome Matching​

Each outcome is an expression or code snippet that resolves to true or false. The first matching outcome wins.

"outcomes": [
  {"name": "success", "condition": "response.status == 200"},
  {"name": "not_found", "condition": "response.status == 404"}
]

Dynamic Headers And Path Params​

  • Use {param} in endpoints. The platform resolves it from inputs, variables, or user context.
  • Dynamic headers accept expressions like $variables.request_id.

Safety Controls​

You can enforce safeguards on sensitive actions:

  • requires_confirmation: only run after a confirm step
  • requires_identity_verification: depends on your verification flow setting state
  • redact_fields: remove sensitive fields from logs
  • rate_limit: reserved for future enforcement in some deployments
  • idempotency_key: key used to avoid duplicates
  • audit_level: basic or detailed

Settings​

"settings": {
  "timeout_ms": 8000,
  "retries": 3,
  "retry_backoff_ms": 500
}

Input Mappings And Output Datapoint​

  • input_mappings: default map inputs from datapoints
  • output_datapoint: store the action result into a datapoint slug

These are optional but useful for standardization.

Using Actions In The DSL​

- action:
    call: orders.get-details
    as: order
    outcomes:
      found: continue
      not_found:
        - done: "Order not found"

The result is stored under variables.order and can be used in later steps:

- done: "Order {{variables.order.id}} is {{variables.order.status}}"