Recipe Format

A Recipe is a JSON object that describes a complete workflow. It is the format that agents (and humans) use to define what S6S should execute. Recipes are designed to be simple to produce — no UUIDs, no canvas positions, no internal plumbing.

You deploy a Recipe with POST /api/v1/workflows/deploy. S6S validates it, compiles it to the internal representation (IR), checks credentials, saves a new version, and (for some trigger types) starts a run. The compilation pipeline:

Recipe (agent-friendly JSON)
  → compileRecipe() → IR Workflow (typed, UUID-based, positioned)
    → compile() → CompiledPlan (topological order, parallel groups, retry policies)

The same endpoint also accepts a raw IR workflow (a body with nodes and edges) or an n8n workflow export (nodes and connections). A body that is none of these gets 400.

If the Recipe is invalid, the deploy returns 422 with every problem found:

{
  "error": "Recipe validation failed",
  "details": {
    "ok": false,
    "format": "recipe",
    "errors": [
      {
        "code": "STEP_NOT_IN_FLOW",
        "message": "Step 'notify' is defined but not included in the flow array",
        "path": ["steps"],
        "suggestion": "Add 'notify' to the flow array or remove it from steps"
      }
    ]
  }
}

When the only problems are refs in flow or on_error that are a close misspelling of a real step ref, S6S fixes them and lists the fixes under corrections in the deploy response. Non-blocking hints come back as validation_warnings.

A Recipe accepts only these fields. Any other key is rejected.

{
  "name": "Hello World",
  "trigger": { "type": "manual" },
  "steps": [
    {
      "ref": "greet",
      "action": "transform",
      "config": { "template": { "message": "Hello from S6S!" } }
    }
  ],
  "flow": ["greet"]
}

Deploy request options

These fields are not part of the Recipe. You can send them in the same deploy request body; S6S removes them before compiling.

The raw IR format has two workflow-level fields a Recipe cannot set: inputSchema (JSON Schema that webhook input must match, see Triggers) and settings.

The trigger field determines how the workflow starts. Its keys sit directly on the object (there is no nested config). Four types are supported; the Triggers page covers each one in depth.

Manual

Runs once right after deploy (unless autoRun is false), and whenever you start it from the app or with POST /api/v1/workflows/{id}/run.

"trigger": { "type": "manual" }

Schedule

Runs on a five-field cron expression (cron, required) in an IANA timezone (default UTC). S6S checks schedules once a minute. Deploying does not start a run.

"trigger": {
  "type": "schedule",
  "cron": "0 */4 * * *",
  "timezone": "America/New_York"
}

Schedule triggers provide {{trigger.output.fired_at}} and {{trigger.output.scheduledAt}}, the same ISO timestamp, set when the scheduled run starts.

Webhook

Runs when an HTTP request reaches /api/webhooks{path}. path is required; method is GET or POST (default POST). The deploy response returns the invoke URL and, on the first deploy, the webhook secret that callers must send.

"trigger": {
  "type": "webhook",
  "path": "/new-lead",
  "method": "POST"
}

Webhook trigger outputs are available via expressions:

• {{trigger.output.body}} — request body (parsed for JSON requests)
• {{trigger.output.headers}} — request headers
• {{trigger.output.query}} — query string parameters
• {{trigger.output.method}} — HTTP method
• {{trigger.output.path}} — the trigger path
• {{trigger.output.receivedAt}} — ISO time the request arrived

Telegram

Runs when a Telegram chat linked to your S6S account sends a message to the S6S Telegram bot. An optional credential label can be set on the trigger.

"trigger": { "type": "telegram" }

Each step defines a single action in the workflow. Steps are referenced by their ref in the flow array, in on_error, and in expressions. A step accepts only these fields.

{
  "ref": "notify_slack",
  "action": "slack",
  "config": {
    "channel": "#sales",
    "textTemplate": "New lead: {{trigger.output.body.name}}"
  },
  "credential": "default",
  "run_if": "{{trigger.output.body.score}} >= 50",
  "retry": { "max_attempts": 3, "base_delay_ms": 2000 }
}

The action field on each step determines what it does. S6S supports 28 built-in actions and dynamic integrations.

Built-in Actions

The Credential column names the provider of the connected account the step needs. http takes an optional credential; ai and rag use the LLM configured for the install.

Sub-action shorthand

For gmail, google_sheets, google_drive, telegram, twitter, discord, imap, youtube and buffer you can write the sub-action into the action name. "action": "gmail.search_messages" compiles as "action": "gmail" with config.action set to search_messages. A config.action you set yourself wins.

Dynamic Integrations

For a platform not covered by built-in actions, use the provider.action syntax (lowercase, one dot). S6S compiles it to an HTTP request from a learned description of that API and injects the credential.

S6S first looks the integration up in its store of learned integrations. When the learning module is installed and an LLM is configured, an unknown provider is learned at deploy time and cached for later workflows. If an integration can't be resolved, the step can't run: depending on its config, the deploy either returns an UNRESOLVED_INTEGRATION warning or fails. The step's output has the same shape as an http step. Prefer provider.action over raw http for any API that requires authentication.

The flow array controls execution order. It contains step refs as strings, with nested arrays for parallel execution.

Sequential

Steps listed as strings execute one after another. Here fetch_data runs first, then process, then notify:

"flow": ["fetch_data", "process", "notify"]

Parallel

Steps inside a nested array (two or more refs) run concurrently. The next item waits for all of them. Here post_slack, post_discord and send_email run in parallel after prepare, and summarize runs when all three are done:

"flow": ["prepare", ["post_slack", "post_discord", "send_email"], "summarize"]

A step can only reference outputs of steps from earlier flow items. Steps in the same parallel group can't reference each other; the deploy rejects that with EXPRESSION_REF_NOT_UPSTREAM.

Mixed

Combine sequential and parallel items freely. Here step_a and step_b run in sequence, step_c and step_d in parallel, and step_e after both:

"flow": ["step_a", "step_b", ["step_c", "step_d"], "step_e"]

Condition branching

A nested array whose first ref is a "action": "condition" step is a branch: [condition, true_branch, false_branch]. The false branch is optional. Here check is evaluated after prep; yes_path runs if it is true, no_path if it is false, and finalize runs after whichever branch ran:

"flow": ["prep", ["check", "yes_path", "no_path"], "finalize"]

For routing on more than two values, use a switch step.

The top-level on_error field sets a policy per step, keyed by step ref. Steps themselves have no on_error field; a step-level retry is covered below.

"on_error": {
  "flaky_api": {
    "action": "retry",
    "retry": { "max_attempts": 3 }
  },
  "optional_notify": { "action": "continue" },
  "critical_step": { "action": "stop" }
}

Step-level retry

Set retry on a step for full control:

Each delay is a random value up to the computed delay. Only temporary errors are retried: HTTP 5xx and 429 responses, HTTP timeouts and request failures, step timeouts, AI timeouts, and sub-workflow timeouts. Other errors (for example HTTP 4xx, expression errors or missing credentials) fail at once.

Steps can include an optional run_if field. S6S resolves its expressions just before the step and evaluates the resulting string. If it is falsy, the step is skipped, not failed, and the run can still succeed.

Supported comparisons: >, <, >=, <=, ==, !=, ===, !==. When both sides are numbers they are compared as numbers; otherwise as strings. Without a comparison, the value is falsy if it is empty, false, 0, null or undefined. Keep the operator outside the braces: "{{amount.output.total}} > 100".

{
  "name": "High Value Alert",
  "trigger": { "type": "manual" },
  "steps": [
    {
      "ref": "get_total",
      "action": "transform",
      "config": {
        "template": { "amount": "{{trigger.output.payload.amount}}" }
      }
    },
    {
      "ref": "notify",
      "action": "telegram",
      "config": {
        "action": "send_message",
        "text": "High value alert: {{get_total.output.amount}}"
      },
      "credential": "default",
      "run_if": "{{get_total.output.amount}} > 10000"
    }
  ],
  "flow": ["get_total", "notify"]
}

Run it with input { "amount": 5000 } and the notify step is skipped; the run finishes as succeeded.

A multi-step workflow with a webhook trigger, parallel steps, error handling, and credentials:

{
  "name": "New Lead Notification Pipeline",
  "trigger": {
    "type": "webhook",
    "path": "/new-lead",
    "method": "POST"
  },
  "steps": [
    {
      "ref": "format_message",
      "action": "transform",
      "config": {
        "template": {
          "text": "New lead: {{trigger.output.body.name}} ({{trigger.output.body.email}})",
          "name": "{{trigger.output.body.name}}",
          "email": "{{trigger.output.body.email}}"
        }
      }
    },
    {
      "ref": "notify_slack",
      "action": "slack",
      "config": {
        "channel": "#sales",
        "textTemplate": "{{format_message.output.text}}"
      },
      "credential": "default"
    },
    {
      "ref": "log_to_sheet",
      "action": "google_sheets",
      "config": {
        "action": "append_row",
        "spreadsheetId": "your-spreadsheet-id",
        "range": "Leads!A:B",
        "values": [["{{format_message.output.name}}", "{{format_message.output.email}}"]]
      },
      "credential": "default"
    },
    {
      "ref": "record",
      "action": "transform",
      "config": {
        "template": {
          "lead": "{{format_message.output.email}}",
          "sheet_range": "{{log_to_sheet.output.updatedRange}}",
          "run_id": "{{run.id}}"
        }
      }
    }
  ],
  "flow": [
    "format_message",
    ["notify_slack", "log_to_sheet"],
    "record"
  ],
  "on_error": {
    "notify_slack": { "action": "continue" },
    "log_to_sheet": { "action": "retry", "retry": { "max_attempts": 3 } }
  }
}

This workflow receives a lead via webhook and formats it. It then posts to Slack and appends a row to a Google Sheet in parallel. If Slack fails, the run continues to record. If the Sheets call fails with a temporary error, it is tried up to 3 times in total. The record step runs last and keeps a summary in the run. The webhook caller gets an immediate reply with the run ID; read the results with GET /api/v1/runs/{runId}.