Automation

Bowrain provides two complementary layers of automation: server-side rules, configured in the web app, that respond to events across the whole workspace — the primary automation surface — and local rules declared on a project recipe for kapi-driven (CLI/CI) workflows.

Server-side automation

Server-side automations are event-driven rules configured in the Bowrain web app under Project > Automations. They respond to events on the server — content pushed, a connector syncing new source, translations completed, quality gates evaluated — and trigger actions like running flows or sending notifications. Because they react to events on the server, they apply to content from any connector, not just a local checkout.

The Automations surface is a superset flow + automation editor with three tabs: Runs (run history), Rules (trigger + conditions + actions), and Flows (the flow canvas — see Server-Side Flows). The Flows tab embeds the same @neokapi/flow-editor component the desktop apps use, so a run_flow action and the flow it runs are authored in one place.

Creating rules

1. Navigate to Project > Automations > Rules
2. Click New Rule
3. Select a trigger event (for example, "When content is pushed" or "When a connector syncs")
4. Add optional conditions (filter by project, locale, or event data)
5. Add one or more actions. A run_flow action picks a flow from the project's flow registry (the built-in catalog plus any project flows authored on the Flows tab) — connector-agnostic, so the same flow applies to content from any connector
6. Save and enable the rule

Rules and the flow definitions they reference are persisted through the project-scoped REST API: /api/v1/:ws/:id/automations for rules and /api/v1/:ws/:id/flows for flow definitions. Rules can be reordered, disabled, and duplicated from the editor.

Local automation (CLI)

Local automations run in kapi (with the bowrain plugin) and are declared at the top level of your project's kapi.yaml recipe. They hook into CLI commands and execute actions before or after operations like push, pull, and flow runs — the developer-workflow and CI layer that complements the server rules above.

Configuration

Add an automations: section to your kapi.yaml recipe:

automations:
  - name: qa-before-push
    trigger: pre-push
    actions:
      - type: run_flow
        config:
          flow: qa

  - name: sync-on-push
    trigger: post-push
    actions:
      - type: wait_translate
        config:
          timeout: 5m
      - type: pull

Trigger types

Trigger	Fires when
pre-push	Before kapi push sends content to the server
post-push	After kapi push completes successfully
pre-pull	Before kapi pull fetches content from the server
post-pull	After kapi pull writes files locally
pre-flow	Before kapi run executes a flow
post-flow	After kapi run completes

Action types

Action	Description
run_flow	Execute a flow by name (inline on the recipe, from .kapi/flows/, or built-in)
wait_translate	Wait for server-side translations to complete (with configurable timeout)
pull	Pull translated content from the server
push	Push local content to the server

Example: QA gate before push

Prevent pushing content that fails quality checks:

automations:
  - name: qa-gate
    trigger: pre-push
    actions:
      - type: run_flow
        config:
          flow: qa
          fail_on_error: true

If qa finds issues and fail_on_error is true, the push is aborted.

Catching up on every push

Catching the project up on push is not an automation — it is the project's server.converge policy. With the default on-push, the server runs a full pass (reuse, drafting, QA, terms, gates, parking) after every push, recorded as a run anyone can watch:

# kapi.yaml
server:
  url: https://bowrain.example.com/my-team/abc123
  converge: on-push        # on-push (default) | manual | schedule

kapi push from CI just pushes; the server catches the project up on its own clock; kapi up is push + watch the run + pull. See Keeping content caught up for the model, and AD-022: Convergence as a Service for the server-side design.

Every run — started by a push, by kapi up, or manually — appears in the project's Runs view in the web and desktop app, with its state (Running, Up to date, Parked), its trigger, the pass count, and a per-locale summary such as "3 shippable · 1 parked". A Run now button starts a run from the app, and an in-flight run can be canceled. Parked units land in the review queue.

Quality gates

Quality gates evaluate content against thresholds before allowing operations to proceed. A blocking gate aborts the operation if the check fails; an advisory gate logs a warning but continues.

Gates integrate with both server-side and local automation, so you can enforce standards at the server level (on push or connector sync) and at the CLI level (pre-push).

Webhooks

Webhooks notify external systems when events occur. Configure them in Project Settings > Webhooks with a destination URL and the events you want to receive.

Webhook payloads are signed with HMAC-SHA256 so the receiving system can verify authenticity. Delivery history is visible in the web UI.

Loop prevention

Automation chains are tracked through a causation chain. If a chain of rules exceeds five levels deep, it stops automatically and a warning is logged. This prevents circular rules from running indefinitely.

Execution history

Both server-side and local automations maintain execution history:

• Server: Project Settings > Automation > History provides an execution log with status, duration, and error details
• Local: kapi status --automations shows recent local automation runs