Choosing and arming a trigger

One active automatic trigger

A workflow can store settings for every trigger type, but only the selected one starts runs automatically. Manual Run is always available.

triggers:
  enabled: true          # false = all automatic triggers paused
  manual: true
  selected: schedule     # manual | schedule | startup | after | file | http | telegram
  schedule:
    every: 1h
  http: true             # kept for later, but inactive while schedule is selected

Consent

The first time you enable an automatic trigger, the page lists every HTTP call, MCP tool, model connection, and secret name that a run can use. Confirm arms the trigger, and Cancel leaves it off. If you later add a new call or secret name, Termorq asks again. A manual Run never asks.

Pausing

Pause triggers stops automatic starts. Run still works. Copies and imports always start with their triggers paused.

Reference: Triggers, runs, and notices

Schedule

Presets

triggers:
  enabled: true
  selected: schedule
  schedule:
    every: 1h        # 1m | 5m | 15m | 30m | 1h | 1d

Cron

  schedule:
    cron: "0 7 * * 1-5"    # minute hour day-of-month month day-of-week

• Five fields are supported, using *, lists (1,15), ranges (1-5), and steps (*/15). Both 0 and 7 mean Sunday.
• Runs are at least one minute apart.

Passing inputs on a schedule

schedule.input provides the run’s inputs. A JSON object becomes inputs.*. Any other value becomes inputs.input.

inputs:
  region:
    type: string
triggers:
  enabled: true
  selected: schedule
  schedule:
    every: 1d
    input: '{"region":"eu-west"}'

At startup and After another workflow

At startup

triggers:
  enabled: true
  selected: startup
  at_start: true

This runs once when the app process opens. It’s useful for warming caches or checking prerequisites.

After another workflow

schema: 1
name: Notify on failure
id: notify-on-failure
triggers:
  enabled: true
  selected: after
  after:
    workflow: refresh-acme-users
    outcome: failed        # success | failed | any
blocks:
  - id: note
    kind: code
    language: bash
    body: |
      echo "refresh-acme-users failed at $(date -u +%FT%TZ)" >&2
      echo '{"ok":true}'
    outputs:
      type: object
      properties:
        ok: { type: boolean }

File change

schema: 1
name: On config change
id: on-config-change
folder: ~/src/acme-apis
triggers:
  enabled: true
  selected: file
  file:
    path: config/app.json     # relative to `folder`; must be inside it
    debounce_ms: 1500
blocks:
  - id: changed
    kind: code
    language: python
    uses: [trigger.path, trigger.received_at]
    body: |
      import json, os
      t = json.load(open(os.environ["TERMORQ_INPUT"], encoding="utf-8"))["trigger"]
      print(json.dumps({"line": f"{t['path']} changed at {t['received_at']}"}))
    outputs:
      type: object
      properties:
        line: { type: string }

Rules

• Termorq watches inside the workflow folder, and refuses a path outside it.
• Changes are debounced (by 1.5 seconds by default), so a burst of saves starts one run.
• path matches the changed file’s path relative to the folder (or a trailing part of it). If you leave path empty, any change in the folder triggers a run.
• The trigger provides trigger.path and trigger.received_at.

import json, os
t = json.load(open(os.environ["TERMORQ_INPUT"], encoding="utf-8"))["trigger"]
p = os.path.join(os.environ["TERMORQ_FOLDER"], "config", "app.json")
try:
    json.load(open(p, encoding="utf-8")); ok = True
except Exception:
    ok = False
print(json.dumps({"valid": ok}))

HTTP request

Steps

1. Use the Input and output example from Stage 2 (the echo block with uses: [trigger.text]).
2. On Triggers, choose HTTP request, Save, and confirm.
3. Click Copy key. The key is stored in the OS keychain (account workflow-hook-<workflow id>). It never appears in the YAML, the run record, or the picker.
4. Call the hook:

export TERMORQ_HOOK_KEY='<paste the key>'
curl -sS -i \
  -H "content-type: application/json" \
  -H "x-api-key: $TERMORQ_HOOK_KEY" \
  -d '{"text":"Hello from curl"}' \
  http://127.0.0.1:8787/hooks/input-output-example

triggers:
  enabled: true
  selected: http
  http: true

How the body maps

The JSON body becomes inputs.<name>. Supported trigger fields, such as text, also become trigger.<name>. So {"text":"Hi"} provides both inputs.text and trigger.text. Declare inputs.text if you want to read it that way.

Responses

The listener

One listener serves every armed workflow. It defaults to 127.0.0.1:8787 (This machine only), and the socket is open only while at least one workflow has HTTP armed. All interfaces exposes the port on your network. There’s no TLS, so the key travels in clear text.

inputs:
  names:
    type: array
    items: { type: string }

Telegram

Steps

1. On Triggers, choose Telegram. Enter the bot token and click Save bot settings. Termorq checks the token with getMe and stores it in the keychain (account telegram-token-<id>).
2. Add your chat ID to the allowlist, and optionally a command such as refresh (with or without /).
3. Save, confirm, and keep Termorq open.

triggers:
  enabled: true
  selected: telegram
  telegram:
    bot: '@acme_ops_bot'
    chats: ['123456789']
    command: refresh
blocks:
  - id: args
    kind: code
    language: bash
    uses: [trigger.args, trigger.from_username]
    body: |
      jq -c '{text: (.trigger.args // ""), who: (.trigger.from_username // "")}' "$TERMORQ_INPUT"
    outputs:
      type: object
      properties:
        text: { type: string }
        who: { type: string }

What the message provides

Rules

• Termorq long-polls Telegram. The bot doesn’t reply.
• Messages from chats that aren’t on the allowlist are ignored. /refresh and /refresh@my_bot both match the command.
• When the bot first connects, it skips messages that were already waiting. The poll stops when you quit Termorq.
• The Triggers panel shows the poll status: Telegram API errors, allowlist or command mismatches, and the run ID that each matching message started.