Server-side flows

Flows on Bowrain Server execute the same processing pipelines available in the CLI, over content held in the workspace rather than in local files. A flow runs on the server in one of two ways: as the flow a convergence run drives, or from an automation rule's run_flow action. Either way it runs in the background, reads the project's blocks, streams them through its tools, and writes the results back, with no CLI involved.

How a server-side flow runs

Progress and the outcome appear in the project's Runs view, and in kapi up's terminal view when the run was started from a checkout.

Triggering flows

As part of a run

Every run drives the project's default flow: recycle from memory, draft, check. Start one from the Runs view with Run now, from a checkout with kapi up, or let the project's bowrain.converge policy start one on every push.

From an automation rule

An automation rule runs a named flow when an event fires. See Automation for the triggers and for creating rules.

Example: draft content when it arrives from a push:

{
  "name": "auto-draft",
  "trigger": "connector.push.completed",
  "action": {
    "type": "run_flow",
    "config": {
      "flow": "translate",
      "target_locales": "fr,de,ja"
    }
  }
}

From the web app

The Bowrain web app exposes a flow and automation editor under Project > Automations, with three tabs:

1. Runs: run history (see Automation).
2. Rules: trigger, conditions, and ordered actions. A run_flow action selects a flow from the project's flow registry.
3. Flows: the flow canvas, the same visual editor the desktop app renders. It lists the built-in flows alongside the project's stored flows and edits the latter on a reader → tool(s) → writer graph; transformers such as redaction and normalization are ordinary ordered steps whose placement is validated when the flow is built.

Flows are connector-agnostic: a flow runs server-side on content from any connector. The graph never names one; content that arrived from a content platform, a design tool, a repository, or a developer's checkout is handled identically.

Event flow

One end-to-end example: the developer route, where a checkout pushes and the server runs the flow. Content arriving through any other connector follows the same server-side path:

Managing flow definitions

Project flow definitions are stored server-side and exposed through a project-scoped REST API. The flow editor in the web app (and the desktop app) drives these endpoints; automations reference a flow by its id.

Method	Path	Description
GET	/api/v1/:ws/:id/flows	List flows (built-in catalog + project flows)
GET	/api/v1/:ws/:id/flows/:flowId	Get one flow (built-in or project)
POST	/api/v1/:ws/:id/flows	Create a project flow
PUT	/api/v1/:ws/:id/flows/:flowId	Replace a project flow
DELETE	/api/v1/:ws/:id/flows/:flowId	Delete a project flow

Built-in flows are read-only; the server rejects writes to a flow whose id collides with a built-in. Mutations require the manage_automation permission.

A flow definition is a node/edge graph (reader → tool(s) → writer) rather than a flat step list, so it round-trips losslessly through the visual editor:

curl -X POST https://app.bowrain.cloud/api/v1/acme/proj-1/flows \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "translate-with-checks",
    "description": "Translate then run quality checks",
    "nodes": [
      {"id": "reader", "type": "reader", "name": "auto", "position": {"x": 0, "y": 0}},
      {"id": "translate", "type": "tool", "name": "translate", "position": {"x": 250, "y": 0}},
      {"id": "qa", "type": "tool", "name": "qa", "position": {"x": 500, "y": 0}},
      {"id": "writer", "type": "writer", "name": "auto", "position": {"x": 750, "y": 0}}
    ],
    "edges": [
      {"id": "e1", "source": "reader", "target": "translate"},
      {"id": "e2", "source": "translate", "target": "qa"},
      {"id": "e3", "source": "qa", "target": "writer"}
    ]
  }'

On the developer route, flow definitions can also live in a project's .kapi/flows/ directory and be pushed with the rest of the project.

Composing multi-step work

Multi-step work composes inside a single flow definition: the node graph above chains translate and qa in one run. There is no flow-to-flow chaining. Automations react to content events such as connector.push.completed with a fixed set of actions (see Automation), and no automation trigger fires when a flow finishes, so a rule cannot chain on one. See Automation > Loop prevention for how the automation engine bounds event-driven work.

Related

• Automation: event-driven automation rules
• Connectors: where flow input comes from
• Flows on the developer route: authoring flows in a project
• kapi up: catch a connected project up (push → run → pull)