Integration nodes

What this accomplishes

HTTP, RSS, email, file watcher, git events, and approval gates connect a workflow to something outside Miton, or pause it for a person. Each node type has its own per-node configuration in the inspector.

This page is the integration nodes. The visual workflow builder (which uses the integration nodes) is in visual workflow builder; the local scheduler (which triggers workflows) is in local scheduler; the webhook receiver (which receives inbound triggers) is in webhook receiver.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Automation open.
• A connected model plus permission for every file, network or scheduled action in the workflow.

The HTTP node

Calls a REST API.

• Method — GET, POST, PUT, PATCH, or DELETE.
• URL — a constant, or a reference to an earlier node’s output ($nodeId.field) or a secret ($vault.X).
• Headers — a JSON object; values can reference a vault secret the same way.
• Body — a string, sent for POST/PUT/PATCH; also supports node and vault references.
• Timeout — in seconds; defaults to 30.

The node’s output carries the resolved method, URL, headers, body, and timeout so later nodes can use them. Authentication isn’t a separate field — put a bearer token or API key in a header value sourced from the vault.

The RSS node

Polls an RSS or Atom feed.

• URL — the feed address; supports vault interpolation.
• Max items — how many items to return per run; defaults to 10.

The output is the parsed items (title, link, and similar per-item fields) for the workflow to pass to a later node — an AI node to summarise each one, for example.

The email node

Sends an email through a JSON email API you configure yourself (Resend, Mailgun, SendGrid, or similar) — the desktop app has no built-in SMTP transport. Store the endpoint URL under the vault secret workflow_email_endpoint, and an optional bearer token under workflow_email_api_key; the node reads both at send time so nothing sensitive lives in the workflow graph.

• To — a single recipient address; supports vault and node interpolation.
• Subject and Body — plain text or HTML, set by Content type.

A dry run reports what would be sent without calling the endpoint. Attachments aren’t supported.

The file watcher node

Reports filesystem changes since the node’s previous run.

• Path — the directory to watch.
• Pattern — an optional glob (e.g. *.ts).
• Events — any of create, modify, delete.

The first run against a given path establishes a baseline; later runs report what changed since then.

The git event node

Reports repository events since the node’s previous run.

• Event types — any of push, pull request, issue.
• Repository path — defaults to the current project.

Like the file watcher, the first run establishes a baseline (the current commit); later runs report what changed since it.

The approval node

Suspends the workflow until a person responds, or a timeout elapses.

• Prompt — the message shown to the person approving.
• Default action on timeout — approve or reject; defaults to reject.
• Timeout — in seconds; defaults to 300 (five minutes).

The workflow surfaces the pending approval so it can be resolved from the UI; the branch after the node depends on the resulting decision.

What the integration nodes do not cover

• Custom protocols or WebSockets — the built-in set is HTTP, RSS, email, file watcher, git event, and approval; anything else goes through the HTTP node or a custom tool node.
• Full OAuth flows — the HTTP node authenticates with header or query values you supply yourself, not an OAuth handshake.
• Multiple email recipients or attachments — the email node sends to one address with a text or HTML body.

What success looks like

You pick a node type, configure it, and the workflow picks up real output on the next run — an API response, new feed items, a filesystem or git change, a sent email, or a resolved approval — that later nodes can use.

Common failures and recovery

• Inspect the failed run and the exact node output before replaying it.
• Confirm credentials, permissions and test fixtures belong to the active project.
• Use a dry run to isolate a misconfigured node before starting the complete workflow again.

Related next action

Open the Automation overview to connect this task to the rest of the workflow.