One post tagged with "external integration"

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.