Integration smoke test (recommended order)

Follow this order the first time you wire a deployment. It matches how the product is built today: integration primitives (GitHub PAT / Slack webhook / HTTP) rather than full SaaS connectors.

What “testing integrations” actually means here

There are three layers. A smoke test is about proving they work together, not checking a single screen.

Testing integrations = validate secrets (present, decryptable, correct shape), integration configs (saved, enabled, pointing at the right secret or inline value), and execution (node reaches the executor, external side effect + logs + proof). Skip any one layer and you are not testing the real path.

Clean environment: Run checks against a new workflow run (fresh workflow_run / new run id) when you care about proof payload hashes and log lineups. Comparing a new integration setup to stale runs mixes old task outputs into expectations and makes hash / metadata diffing ambiguous.

Operational cheat sheet: failure signals

Use this when triaging execution_logs.event_type, task errors, or integration save errors. It turns the guide from descriptive to operational (failure → likely cause).

Expected log severity

When scanning the run timeline, execution_logs.level is as important as event_type:

Rule of thumb: *_created / *_sent → info, integration_missing → warn, *_failed / *_missing_* / executor validation errors → error.

For bundled presets, missing vendor config often shows as stub task output instead of the rows above — that is intentional. To force the diagnostic signals, use a workflow whose github / slack node is not behind hasIntegration:*, or temporarily disable the guard in a copy of the graph.

1. Start with GitHub (do this first)

Why first: Path is wired end-to-end, output is deterministic (a real issue), and the external result is easy to verify.

Setup

1. Open Dashboard → Integrations.
2. Under GitHub, save either:
   • A Personal Access Token (classic: repo, or fine-grained with Issues write on the target repo), or
   • A saved secret (secretKey) whose value is the PAT — see GitHub Integration (PAT).
3. Set default repository to owner/repo if your workflow nodes use repository: "__default__".

Run a known-good workflow

Use one of:

• Verified Incident Response (demo) — wf-cascades-incident-response
• Incident Triage + Proof — wf-incident-triage-proof

Both include GitHub on an escalation / notify path (with a hasIntegration:github gate on presets so missing config does not hard-fail the whole demo).

Use Run with sample inputs from the workflow builder, or POST /api/workflows/run with the sample context from each guide.

If everything is correct

• The workflow completes the branch that hits the live GitHub node.
• A real issue appears in your repository.
• execution_logs include success-path events from the executor; on a successful create you should see github_issue_created (see GitHub Integration (PAT)).
• Task output on the GitHub node includes issue metadata (number, URL, etc.).
• proof_records / proof payload hashing reflects those outputs — see Execution proofs.

If something fails

Use the Operational cheat sheet above.

Do not treat “run finished” as success until you have checked logs + task output + proof.

---

2. Then Slack (second step)

Why second: Simpler setup, but the structural proof is mostly in logs and run detail, not a durable artifact in your repo.

Setup

1. Dashboard → Integrations → Slack — paste an incoming webhook URL (https://hooks.slack.com/services/…) or a webhookSecretKey pointing at a secret whose value is that URL.
2. Run Incident Triage + Proof so the remediate → Slack branch can execute (again gated by hasIntegration:slack on the preset).

Expected

• A message appears in the Slack channel for that webhook.
• execution_logs include slack_webhook_sent on success (or slack_webhook_failed / executor errors if the URL or payload path fails).

---

3. Optional: generic API node

Use a safe, obvious endpoint, for example:

https://httpbin.org/post

This checks:

• HTTP executor wiring
• {{ secrets.* }} interpolation in node params (if you use secrets)
• Upstream payload flowing into the node

Inspect execution_logs, task output, and proof metadata the same way as for GitHub.

---

Known-good test path (baseline sanity check)

Use Incident Triage + Proof (wf-incident-triage-proof) as a single catalog reference. It exercises both vendor branches, but not in the same run — severity drives the condition. Use a fresh run per attempt (see Clean environment above).

Run A (high severity — escalation / GitHub)

Context: { "sampleAlert": { "id": "INC-0001", "severity": "high", "service": "api" } }
Requires: GitHub integration configured and hasIntegration:github TRUE on the live path.

• Expect: A GitHub issue is created in your default repo (visible in GitHub).
• Log: github_issue_created at info (see expected log severity).
• Proof: Proof / task output for the GitHub node includes issue payload (e.g. issue number, URL, state) and contributes to the run’s proof hash — see Execution proofs.

Run B (low severity — remediation / Slack)

Context: { "sampleAlert": { "id": "INC-0002", "severity": "low", "service": "api" } }
Requires: Slack integration configured and hasIntegration:slack TRUE after remediate.

• Expect: A Slack message appears in the channel for your incoming webhook.
• Log: slack_webhook_sent at info.
• Proof: Proof / task output for the Slack node includes delivery payload (e.g. httpStatus, messageTs, upstream bodyPreview in the recorded output — not necessarily the full Slack message text, but enough to anchor the run).

After both runs

• execution_logs — event types and levels match the tables above (or stub/guard behavior if an integration is absent).
• catalogItemId / workflow id — still wf-incident-triage-proof on each new run.

If both GitHub and Slack are configured, execute Run A and Run B once each on separate new runs — that is the minimal end-to-end baseline for this preset.

---

What to verify (minimum bar)

Do not stop at “the run completed.”

Confirm:

• execution_logs — event types and severity (info / warn / error): e.g. github_issue_created, slack_webhook_sent, integration_missing, executor errors.
• Task outputs — JSON on the node row reflects external IDs, URLs, or HTTP status where the executor records them.
• proof_records — payload hash and metadata change in a way consistent with those outputs; see Execution proofs.
• Metadata — catalogItemId / workflow identity consistent across run detail, proof, and API.

Minimal success criteria:

1. GitHub creates real issues when the live branch runs.
2. Slack delivers real messages when the live branch runs.
3. Missing integrations fail cleanly (not silently) on graphs that hit a live node without config — e.g. integration_missing and a failed task when requireIntegration applies; bundled presets may stub behind hasIntegration:* instead.
4. Proof records include external outputs in the hashed / persisted proof path where the platform records them.

---

What not to test yet

Avoid ServiceNow, n8n, or long multi-vendor chains until you have dedicated connector docs and credentials. Those need full connector layers beyond the current integration primitives (GitHub / Slack / HTTP + secrets).

---

Related guides

• Integration Overview — provider matrix and composition patterns
• GitHub Integration (PAT)
• Verified Incident Response (demo)
• Incident Triage + Proof
• Execution proofs
• DAG execution