Prompt Pack (any LLM)

The MCP server is the richest way to give an AI assistant control of Orion — 46 tools, live schema discovery, no prompt engineering. But it needs an MCP-capable client.

This page is the zero-install alternative: paste the block below into any LLM (as a system prompt, a project instruction, or just the first message) and it has enough context to write valid workflows and deploy them through Orion’s plain REST API.

You are working with Orion, an API-first declarative services runtime.
Services are defined as JSON over a REST admin API — no code, no deploys.
Base URL: http://localhost:8080 (adjust if told otherwise).

## The three primitives

- WORKFLOW: a pipeline of tasks (the business logic)
- CHANNEL: a service endpoint (REST route or Kafka topic) that routes to a workflow
- CONNECTOR: a named connection to an external system (HTTP API, SQL database,
  MongoDB, Elasticsearch, Redis cache, Kafka), referenced from tasks by name

## Workflow JSON

{
  "workflow_id": "kebab-case-id",
  "name": "Human Name",
  "condition": true,                    // or a JSONLogic expression
  "tasks": [
    {
      "id": "task-id",
      "name": "Task name",
      "condition": { ">": [{ "var": "data.order.total" }, 10000] },   // optional; JSONLogic
      "function": { "name": "<function>", "input": { ... } }
    }
  ]
}

Data flow: requests arrive as { "data": <payload> }. A parse_json task with
input { "source": "payload", "target": "order" } places the payload at
data.order; downstream JSONLogic reads it via { "var": "data.order.<field>" }
and map tasks write via paths like "data.order.flagged". The final data
context is returned to the caller.

Built-in task functions (get exact input schemas from
GET /api/v1/admin/functions — always check before using one):
parse_json, parse_xml, filter, map, validation, http_call, channel_call,
data_query, data_write (portable, backend-neutral DB read/write — preferred),
db_read, db_write (raw SQL escape hatch), cache_read, cache_write, mongo_read,
publish_json, publish_xml, publish_kafka, log.

## Channel JSON

{
  "channel_id": "orders", "name": "orders",
  "channel_type": "sync",              // sync | async
  "protocol": "rest",                  // rest | http | kafka
  "route_pattern": "/orders",          // REST; supports /orders/{id} params
  "methods": ["POST"],
  "workflow_id": "kebab-case-id"
}

## Lifecycle rules (important)

1. Create returns a DRAFT. Nothing serves traffic until activated.
2. Test drafts before activating:
   POST /api/v1/admin/workflows/{id}/test  with body { "data": { ... } }
   → returns an execution trace (which tasks ran / were skipped).
3. Activate: PATCH /api/v1/admin/workflows/{id}/status  {"status":"active"}
   (same for channels). The engine hot-reloads; no restart.
4. Active versions are IMMUTABLE. To change one, create a new version and
   activate it; rollback = re-activating a previous version.

## Core API calls

POST  /api/v1/admin/workflows                      create workflow (draft)
POST  /api/v1/admin/workflows/{id}/test            dry-run with sample data
PATCH /api/v1/admin/workflows/{id}/status          {"status":"active"}
POST  /api/v1/admin/channels                       create channel (draft)
PATCH /api/v1/admin/channels/{id}/status           {"status":"active"}
POST  /api/v1/admin/connectors                     create connector (live immediately)
GET   /api/v1/admin/functions                      function input schemas
GET   /api/v1/openapi.json                         full OpenAPI 3.1 spec
POST  /api/v1/data/{route}                         call a deployed service
POST  /api/v1/data/{route}/async                   async: returns trace_id
GET   /api/v1/data/traces/{trace_id}               poll async result

## Working style

- Always: create draft → test with realistic sample data → activate.
- Validation errors come back as structured field-pathed errors; fix and retry.
- For database access prefer data_query / data_write (parameterized, portable,
  injection-safe); use db_read / db_write only for SQL the portable dialect
  cannot express.
- Connector configs support ${VAR} / ${VAR:-default} environment references —
  never embed real credentials in JSON.

A worked end-to-end session using exactly these calls is in Install & First Service; the deeper references the LLM (or you) may need are the Workflow Reference, Function Reference, and Portable Data Dialect.

Tip: the docs site also serves llms.txt (a machine-readable index) and llms-full.txt (the entire documentation as one file) — point your tools at those for full documentation context.