Function Reference

A workflow is an ordered list of tasks, and every task invokes one built-in function with an input object:

{
  "id": "enrich",
  "name": "Look up customer",
  "function": {
    "name": "http_call",
    "input": { "connector": "crm", "path": "/customers/42", "response_path": "data.customer" }
  }
}

Functions read from and write to the data context — the JSON document that flows through the pipeline. By convention the request body is parsed into data.* by parse_json, later tasks read data.* in their JSONLogic, and the data object is what a sync channel returns. See the Workflow Reference for the context model and how condition expressions are evaluated.

Orion ships 16 functions (plus validate, an alias for validation). Eight are contributed by the dataflow-rs engine; eight are Orion handlers that talk to connectors or compose channels.

Wherever an input field is described as JSONLogic, you pass a JSONLogic expression that is evaluated against the data context. A plain JSON literal (string, number, object) is also valid JSONLogic and evaluates to itself.

Data functions

These come from the dataflow-rs engine. Orion does not input-schema-validate them at workflow-create time (unlike the connector functions below), so an invalid input here surfaces at execution time rather than on create.

parse_json

Reads a raw value (typically the request payload) and parses it as JSON into the data context. Almost every workflow starts with this — without it, task conditions that reference data.* see an empty context.

{ "name": "parse_json", "input": { "source": "payload", "target": "order" } }

parse_xml

Same input shape as parse_json, but parses an XML payload into a JSON structure at data.{target}.

{ "name": "parse_xml", "input": { "source": "payload", "target": "order" } }

map

Applies an ordered list of JSONLogic expressions, writing each result to a dotted path in the context. The primary tool for reshaping, computing, and enriching data.

{
  "name": "map",
  "input": {
    "mappings": [
      { "path": "data.order.flagged", "logic": true },
      { "path": "data.order.total_with_tax", "logic": { "*": [{ "var": "data.order.total" }, 1.1] } }
    ]
  }
}

filter

Evaluates a JSONLogic condition. If it is truthy the pipeline continues; otherwise the on_reject action is taken.

{
  "name": "filter",
  "input": {
    "condition": { ">": [{ "var": "data.order.total" }, 0] },
    "on_reject": "halt"
  }
}

validation / validate

Evaluates a list of rules. Each rule’s logic must evaluate to exactly true; any other result records the rule’s message in the response’s error list. Validation is non-destructive — it never mutates the data context. validate is an accepted alias for validation.

{
  "name": "validation",
  "input": {
    "rules": [
      { "logic": { "!!": [{ "var": "data.order.customer_id" }] }, "message": "customer_id is required" },
      { "logic": { ">": [{ "var": "data.order.total" }, 0] },        "message": "total must be positive" }
    ]
  }
}

log

Emits a structured log line. message is a JSONLogic expression (a plain string is valid), and fields attaches additional JSONLogic-derived key/values.

{
  "name": "log",
  "input": {
    "level": "info",
    "message": "Order processed",
    "fields": { "order_id": { "var": "data.order.id" } }
  }
}

publish_json

Serializes a field inside the data context to a JSON string and stores it at another field. (It writes back into the context; it does not publish to an external system.)

{ "name": "publish_json", "input": { "source": "order", "target": "order_json", "pretty": true } }

publish_xml

Like publish_json, but serializes to an XML string.

{ "name": "publish_xml", "input": { "source": "order", "target": "order_xml", "root_element": "Order" } }

Connector functions

These reference a connector by name — credentials and endpoints live in the connector, not the workflow. Orion validates their input at workflow create/update time and exposes the schema via GET /api/v1/admin/functions. Every connector call is wrapped in a circuit breaker.

http_call

Makes an HTTP request through an HTTP connector, with retry and circuit-breaker support. The connector supplies the base URL and auth.

{
  "name": "http_call",
  "input": {
    "connector": "payment-api",
    "method": "POST",
    "path": "/charge",
    "body_logic": { "var": "data.payment" },
    "response_path": "data.charge_result",
    "timeout_ms": 5000
  }
}

db_read

Runs a SELECT against a SQL connector and writes the result rows as a JSON array. Use placeholders bound from params — ? for SQLite/MySQL, $1, $2, … for PostgreSQL.

{
  "name": "db_read",
  "input": {
    "connector": "primary-db",
    "query": "SELECT id, name, tier FROM customers WHERE id = ?",
    "params": [{ "var": "data.order.customer_id" }],
    "output": "data.customer"
  }
}

db_write

Runs an INSERT/UPDATE/DELETE against a SQL connector and writes { "rows_affected": N }.

{
  "name": "db_write",
  "input": {
    "connector": "primary-db",
    "query": "INSERT INTO orders (id, total) VALUES (?, ?)",
    "params": [{ "var": "data.order.id" }, { "var": "data.order.total" }],
    "output": "data.write_result"
  }
}

cache_read

Reads a key from a cache connector (Redis or the built-in in-memory backend). Missing keys yield null.

{ "name": "cache_read", "input": { "connector": "redis", "key": "rate:42", "output": "data.cached" } }

cache_write

Writes a key to a cache connector, optionally with a TTL.

{ "name": "cache_write", "input": { "connector": "redis", "key": "rate:42", "value": 1, "ttl_secs": 60 } }

mongo_read

Runs a find() against a MongoDB connector and writes the matched documents as a JSON array.

{
  "name": "mongo_read",
  "input": {
    "connector": "mongo",
    "database": "shop",
    "collection": "customers",
    "filter": { "tier": "vip" },
    "output": "data.vips"
  }
}

publish_kafka

Publishes a message to a Kafka topic through a Kafka connector. Requires Kafka to be enabled in config. If value_logic is omitted, the full data context is published.

{
  "name": "publish_kafka",
  "input": {
    "connector": "events",
    "topic": "order.placed",
    "key_logic": { "var": "data.order.id" },
    "value_logic": { "var": "data.order" }
  }
}

Composition functions

channel_call

Invokes another channel’s workflow in-process — no network hop. The called channel keeps its own versioning and governance. Cycle detection and a max call depth prevent runaway recursion. Provide exactly one of channel/channel_logic and at most one of data/data_logic.

{
  "name": "channel_call",
  "input": {
    "channel": "customer-lookup",
    "data_logic": { "var": "data.order.customer_id" },
    "response_path": "data.customer"
  }
}

Inspecting schemas at runtime

GET /api/v1/admin/functions returns the live input schema for the connector and composition functions (the data functions are provided by dataflow-rs and are not catalogued there). The Orion CLI MCP server surfaces the same schemas to AI assistants so generated workflows use correct field names.