Triggers and Webhooks in Workflow Chain Engine

Webhooks: A URL Per Workflow

Every workflow has its own webhook URL, shown on its settings page, secured by its own long random key in the path:

POST https://yourserver.com/api.php/webhook/WEBHOOK_KEY
{"customer": "Acme", "email": "billing@acme.com"}

No API key header is needed, the key in the URL is the secret, and the webhook answers when that workflow's webhook trigger is switched on. Every body field and query string field becomes a variable, so a form provider, a store, a payment processor, or any service that can send a webhook fills your flow's variables just by posting what it knows.

The response is the run's real result, including the Success or Fail message with its variables resolved, so the caller gets an actual answer, "Processed Acme, total 42", instead of a bare acknowledgement. Services that display webhook responses show something meaningful, and services that retry on failure can react to a Fail status honestly.

Webhook keys are per-workflow secrets with a regenerate button on the settings page. Rotate one any time, the old URL stops working instantly and the new one is live immediately, which makes cleaning up after a leaked URL a ten second job.

The Run API: Triggering From Your Code

Your own applications trigger runs with one authenticated POST:

curl -X POST https://yourserver.com/api.php/run \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{"workflowID": 1, "customer": "Acme"}'

{"status": "success", "message": "Processed Acme, total 42.", "steps": 8, "runID": 17, "durationMs": 240}

Every extra body field becomes a variable, and the response carries the outcome, the resolved message, the step count, the run ID for the history, and the duration. Because the answer comes back in the same call, the run API works as a synchronous building block: your app can call a flow the way it would call a function, then act on status and message.

Alongside it, POST api.php/workflows lists every workflow with its variables, node counts, and triggers. That makes the engine discoverable from outside, an admin panel or another automation system can enumerate the flows and offer them by name.

Schedules: The Cron Trigger

Set Run Every X Minutes on a workflow's settings page and the cron runner takes it from there. In Docker the runner is already going, the container runs the schedule loop automatically. Everywhere else it is one crontab line:

* * * * * php /path/to/Workflow-Chain-Engine/cli/cron.php

Scheduled runs start with empty variables, and the flow gathers what it needs itself, which shapes the pattern: the first node is typically an HTTP Request that fetches the day's data, captures it into variables, and hands the rest of the flow a full pool to work with. Daily digests, polling loops that watch an API for changes, and nightly syncs all live here.

Run Now: The Button

Run Now sits in the admin with an input box for each declared variable. It is the fastest test harness while you build, type realistic values, run, read the log, and it doubles as the trigger for flows a human kicks off on purpose: a refund process, a re-sync, a "send the report early today." Same engine, same history, zero setup.

Choosing a Trigger

The four combine well on one workflow, a lead intake flow can take webhooks from the form, API calls from the mobile app, and a Run Now for manually entered leads, all landing in the same run history with the trigger recorded on each run.