Skip to main content
T1 starter · e-commerce / personal: no infer: anywhere in this file. A workflow engine is not an LLM wrapper: the DAG, the tools and one CEL comparison do the whole job, deterministically, for free.

The job

You’re waiting for a price to drop. Checking the page every day is a robot’s job. This workflow pulls one structured field from the shop’s API, compares it to your target, and pings your webhook only when it’s time to buy.

The shape

The file

price-watch.nika.yaml

How it works

1

Fetch ONE field, not a page

mode: jq extracts structured JSON from the API response, and the output: block binds named fields: ${{ tasks.check.price }} is a number, not a blob of HTML.
2

CEL gates the alert

The named binding crosses in with: (price: ${{ tasks.check.price }}), then when: ${{ with.price < config.alert_below }} is a plain CEL comparison. False → the task is skipped, not failed.
3

The webhook stays secret

secrets: declares a vault/env-backed reference. The URL is masked in logs: ${{ secrets.alerts_webhook }} never appears in a trace.

Constructs you just used

Make it yours

  • Watch N products: lift the URL into a list input and for_each over it. See Competitor radar for the fan-out pattern.
  • Schedule it: workflow files describe a run. Your host’s cron (or nika serve) decides when runs start.
  • Add a second when: branch that notifies on price INCREASES above a ceiling.

Next · Social repurpose

The last starter introduces the diamond: one source fanning into three parallel rewrites.