2 posts tagged with "event-driven"

Need a workflow that runs the moment someone adds a row to your trading journal, updates a watchlist price, or deletes an expired entry? The new List Change Trigger does exactly that — it watches a User List and fires your workflow whenever rows are added, updated, or deleted.

No polling, no manual kicks, no cron jobs guessing when data changes.

What Is the List Change Trigger?​

The List Change Trigger is a new node type in the Triggers category of the left sidebar. Drag it onto your canvas, pick which list to watch and which operations matter to you, click Run Test, and you are done.

From that moment on, whenever the watched list changes — through the UI, through the User Lists worker in another workflow, or through the API — your workflow fires automatically with the updated data passed in as context variables.

Reactive, Not Polling​

Under the hood, list mutations publish events to a Redis Stream, and a background listener picks them up using XREAD BLOCK — the same efficient mechanism used by message queues. There is no polling, no wasted compute, and near-zero latency (typically under 5 seconds).

Key Features​

• List autocomplete — start typing your list name and the dropdown finds it instantly
• Multi-select trigger operations — choose exactly which changes matter: add_row, update_rows, delete_row, or any combination
• Optional DSL filter — only fire the workflow when rows matching a condition are affected (e.g. only when status eq active AND price gt 100)
• Pass list data — toggle to include the full list rows in the context variables so downstream workers can process them immediately
• Operation filtering — if you only care about updates, the trigger ignores adds and deletes

How to Use It​

Finding the Worker​

Look in the Triggers category in the left sidebar, or search for "list change". The node has a 📋 icon with a pulse indicator showing it monitors for changes.

Adding to Your Workflow​

1. Drag the List Change Trigger node onto the canvas
2. Connect it to the rest of your workflow nodes
3. Configure — click the node to open the right panel

Configuration​

Run Test​

Click Run Test on the trigger node. This saves the configuration and returns:

• Status — active if everything is set up correctly
• List name — confirmation of which list is being watched
• Trigger operations — which changes will fire the workflow
• Row count — how many rows the list currently has

Once saved, the trigger is live — any matching change to that list will start a workflow run.

Context Variables​

The following variables are available in downstream nodes when the trigger fires:

Use Cases​

Reactive Trading Journal​

When you update a trade's P&L in your journal list, the workflow recalculates performance metrics, updates a dashboard widget, and sends a Telegram summary.

[Journal List Update] → [List Change Trigger]
  → [Calculate Metrics] → [Update Dashboard] → [Send Summary]

Watchlist Price Monitor​

A market data worker periodically updates prices in a watchlist. Every time a price changes, the List Change Trigger fires a workflow that checks for breakout signals, evaluates risk, and alerts you.

[Price Updater Worker] → [Update Watchlist] → [List Change Trigger]
  → [Check Breakouts] → [Evaluate Risk] → [Send Alert]

Multi-Step Data Pipeline​

A data collection workflow adds rows to a source list. The List Change Trigger detects the new rows and kicks off a processing pipeline — enriching, analyzing, and storing results in another list.

[Data Collection] → [Add Rows to Source List] → [List Change Trigger]
  → [Enrich Data] → [AI Analysis] → [Store in Result List]

Approval Workflow​

A team member adds a row with status: "pending_approval" to a shared list. The trigger fires, the workflow checks the DSL filter (status eq pending_approval), runs validation, and sends a Slack or email notification to the approver.

[List Change] → [DSL Filter: status eq pending_approval] → [Validate]
  → [Notify Approver via Telegram/Slack]

Audit Trail​

Track every change to critical lists. The trigger fires on every operation, logs the change to a second list or MongoDB collection, and keeps a full audit history.

[Any List Change] → [List Change Trigger] → [Log to Audit List]
  → [Alert on Suspicious Changes]

Workflow Patterns​

Single-Trigger Standalone​

The simplest setup: one trigger, one workflow. Good for simple reactions.

[List Change] → [List Change Trigger] → [Process Data] → [Output]

Chained Triggers​

Multiple workflows can watch the same list with different filters. Workflow A handles add_row for new entries, Workflow B handles status eq active updates only.

[Same List]
  ├─ [Trigger A: add_row] → [New Entry Handler]
  └─ [Trigger B: update_rows + DSL filter] → [Active Item Processor]

Hybrid Timed + Reactive​

Use the Schedule Trigger for periodic maintenance runs and the List Change Trigger for immediate reactions. Both point to shared downstream logic.

[Schedule Trigger (hourly)] → [Shared Logic: Validate → Clean → Report]
[List Change Trigger (instant)] → [Shared Logic: Validate → Clean → Report]

Parameter Loop + List Change​

A Parameter Loop worker generates multiple configurations and stores them in a list. Each new row triggers a separate workflow run that backtests that configuration.

[Parameter Loop] → [Add Row to Config List] → [List Change Trigger (per row)]
  → [Backtest Config] → [Store Results]

Best Practices​

• Be specific with operations — if you only care about updates, uncheck add_row and delete_row. This keeps your workflows focused and avoids unnecessary runs.
• Use DSL filters for large lists — if your list has hundreds of rows but you only care about rows with status eq active, set the filter. The triggered workflow receives matchedRows — only the relevant subset.
• One trigger per (workflow, list) pair — you can have multiple workflows watching the same list, but only one trigger per workflow-list combination.
• Pass list data — keep this enabled unless your list is extremely large. It saves a DB round-trip in downstream workers.
• Test with Run Test — the "Run Test" button saves the trigger config and returns a summary. Make a change to the list and your workflow should fire within seconds.

How It Works (Architecture)​

User List Mutation (UI / Worker / API)
  → publish_list_change_event()
  → XADD to Redis Stream "apudflow:stream:list-change-events"
  → Listener (XREAD BLOCK, 5s timeout)
  → Find matching subscriptions in MongoDB
  → Check triggerOn matches operation
  → Evaluate DSL filter (if set)
  → Create workflow run with context vars
  → Push to workflow queue
  → Executor picks up and runs the workflow

The entire pipeline is asynchronous and event-driven. There is no blocking, no polling, and no performance impact on the list mutation itself.

Legal Disclaimer​

This is not financial advice. Trading involves significant risk of loss. Use reactive workflows at your own discretion.

Need to kick off a workflow from an external system — a CI/CD pipeline, a trading signal provider, a custom script, or even another ApudFlow workflow? The new Webhook Trigger worker lets you do exactly that: expose an HTTP endpoint that starts your workflow on demand.

Unlike the Schedule Trigger (which runs on a timer), the Webhook Trigger is passive — it waits for an incoming HTTP call, then passes the caller's data straight into your workflow as context variables.

What Is the Webhook Trigger?​

The Webhook Trigger is a new node type in the Triggers category of the left sidebar. Drag it onto your canvas, define the variables you expect from the caller, click Run Test, and you get a stable URL like:

POST /api/t/{workflow_id}/{webhook_id}

Any external system — or even another workflow — can call that URL and your workflow runs with the data it sent.

Key Features​

• Both POST and GET — send variables in a JSON body (POST) or as query parameters (GET)
• Typed variables — define each variable as string, integer, boolean, or list with validated choices
• Required / optional — mark variables as required; the endpoint rejects calls that miss them
• Default values — if a variable isn't provided, the default kicks in
• Optional API key — secure the endpoint with a bearer token (or leave it open)
• Isolated path — uses /api/t/ prefix, separate from the existing data provider endpoints under /api/w/

How to Use It​

Finding the Worker​

Look in the Triggers category in the left sidebar, or search for "webhook". The node has a distinctive lightning-bolt icon with an outgoing arrow.

Adding to Your Workflow​

1. Drag the Webhook Trigger node onto the canvas
2. Connect it to the rest of your workflow nodes
3. Configure variables — click the node and the right panel shows a visual variable editor

The Variable Editor​

Each variable is a card with:

Below the variable cards there's an optional API Key field — leave it blank for an open endpoint, or set a secret key to restrict access.

Run Test​

Click Run Test on the trigger node. This saves the configuration and returns:

• The endpoint URL you can share with external systems
• The variables you defined, each shown as a top-level output field with its default value
• The status — success if everything is configured correctly

Calling the Endpoint​

POST (recommended for complex data)​

curl -X POST "https://api.apudflow.io/api/t/{workflow_id}/{webhook_id}" \
  -H "Content-Type: application/json" \
  -d '{"symbol": "BTCUSD", "limit": 100, "mode": "backtest"}'

GET (quick tests / simple values)​

curl "https://api.apudflow.io/api/t/{workflow_id}/{webhook_id}?symbol=BTCUSD&limit=100&mode=backtest"

If you set an API key, pass it as an Authorization: Bearer <key> header or api_key=<key> query parameter.

Variable Resolution Priority​

1. Values from the request (highest priority)
2. Default values from the trigger configuration
3. Empty string if neither is provided and the variable is optional

Use Cases​

External Trading Signal Execution​

A trading signal provider (e.g. MetaTrader, TradingView webhook, custom bot) calls your workflow with symbol, direction, and position size — your workflow validates, logs, and executes.

[TradingView Alert] → HTTP POST → [Webhook Trigger] → [Validate] → [Execute Trade] → [Log Results]

CI/CD Pipeline Trigger​

After a deploy, your pipeline calls the webhook with the build version and environment — your workflow runs tests, sends notifications, and updates dashboards.

[CI/CD Pipeline] → HTTP POST → [Webhook Trigger] → [Run Tests] → [Send Notification]

Worker-to-Workflow Communication​

One workflow's final node (e.g. a Signal Generator or AI Analyzer) triggers another workflow by calling its webhook URL. This decouples large automations into manageable sub-workflows.

[Workflow A: Data Collection] → [AI Analysis] → HTTP POST → [Workflow B: Execution]

Scheduled + Webhook Hybrid​

Use the Schedule Trigger for regular runs (e.g. every hour) and the Webhook Trigger for ad-hoc event-driven runs — both point to the same downstream logic.

Best Practices​

• Set an API key if the endpoint is exposed to the internet — otherwise anyone who knows the URL can trigger your workflow
• Use typed variables — mark boolean and integer fields with matching types so the endpoint validates incoming data
• Default values are your safety net — set sensible defaults so the workflow runs even if the caller omits a field
• Test with curl first before integrating into a production system

Legal Disclaimer​

This is not financial advice. Trading involves significant risk of loss. Use webhook-triggered workflows at your own discretion.