Integration nodes

What this accomplishes

HTTP, RSS, email, file watcher, git events, and approval gates in workflows.

The integration nodes are the node types that connect a workflow to an external system. The integration nodes are: HTTP, RSS, email, file watcher, git event, and approval. Each integration node has a per-node configuration that the user configures 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 the workflows) is in local scheduler; the webhook receiver (which receives the HTTP and git event 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

The HTTP node calls a REST API. The HTTP node supports:

• Methods — GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS.
• URL — the URL of the API endpoint. The URL can be a constant or a reference to a previous node’s output.
• Headers — the request headers. The user can add a header; the user can remove a header; the user can set a header from a previous node’s output.
• Query parameters — the request query parameters. The user can add a parameter; the user can set a parameter from a previous node’s output.
• Body — the request body. The body can be a constant (JSON, form-encoded, multipart, raw), a reference to a previous node’s output, or a custom body.
• Authentication — none, basic (username / password), bearer (token), API key (header / query).
• Timeout — the request timeout in milliseconds. The default is 30 seconds.
• Retry — the retry policy. The default is “retry 3 times with exponential backoff”.

The HTTP node’s output is the response. The output includes the status code, the response headers, and the response body. The workflow can use the output as input to subsequent nodes.

The RSS node

The RSS node polls an RSS feed. The RSS node supports:

• URL — the URL of the RSS feed.
• Polling interval — the polling interval in minutes. The default is 15 minutes.
• Filter — a filter expression to apply to each item in the feed. The user can use a simple expression (e.g. “title contains ‘Miton’”) or a custom expression.
• Deduplication — whether to deduplicate items by URL. The default is enabled.

The RSS node’s output is the new items in the feed. The output is a list of JSON objects, each with the item’s title, URL, content, author, and published date. The workflow can use the output as input to subsequent nodes (e.g. an AI node to summarise each item).

The email node

The email node sends an email. The email node supports:

• Recipients — the email recipients. The user can add a recipient; the user can set a recipient from a previous node’s output.
• Subject — the email subject. The subject can be a constant or a reference to a previous node’s output.
• Body — the email body. The body can be plain text or HTML. The body can be a constant or a reference to a previous node’s output.
• Attachments — the email attachments. The user can add an attachment; the user can set an attachment from a previous node’s output.
• SMTP server — the SMTP server configuration. The user configures the SMTP server’s host, port, authentication, and TLS.

The email node’s output is the email’s delivery status. The output includes the recipient, the delivery status, and the delivery error (if any).

The file watcher node

The file watcher node triggers a workflow when a file changes. The file watcher node supports:

• Path — the path to watch. The path can be a file or a directory.
• Event — the event to watch for (created, modified, deleted, renamed).
• Filter — a filter expression to apply to the file’s name. The user can use a glob pattern (e.g. *.json).

The file watcher node’s output is the file change event. The output includes the file’s path, the event, and the file’s modification time. The workflow can use the output as input to subsequent nodes.

The git event node

The git event node triggers a workflow when a git event happens. The git event node supports:

• Event — the git event to watch for (push, pull request opened, pull request closed, tag created, branch created, branch deleted).
• Repository — the repository to watch. The repository can be a constant or a reference to a previous node’s output.
• Branch — the branch to watch. The branch can be a constant or a reference to a previous node’s output.
• Authentication — the git authentication (none, basic, bearer, SSH key).

The git event node’s output is the git event. The output includes the event type, the repository, the branch, the author, and the commit message (if applicable). The workflow can use the output as input to subsequent nodes.

The git event node is a webhook receiver under the hood; the user configures the git event as a webhook in the user’s git provider (GitHub, GitLab, Bitbucket). The git event node listens for the webhook and triggers the workflow when the webhook arrives.

The approval node

The approval node suspends a workflow until a human approves. The approval node supports:

• Approvers — the users who can approve. The user can add a user; the user can add a group.
• Required approvals — the number of approvals required. The default is 1.
• Timeout — the timeout in hours. The default is 24 hours. The workflow is cancelled if the approval is not received within the timeout.
• Notification — whether to send a notification to the approvers. The default is yes. The notification is sent via the notification node (Slack, email, Discord, push).

The approval node’s output is the approval. The output includes the approver, the approval time, and the approval status (approved, rejected). The workflow can branch on the approval status (e.g. “if approved, continue; if rejected, halt”).

What the integration nodes do not cover

The integration nodes do not cover:

• Custom protocols — the integration nodes are HTTP, RSS, email, file watcher, git event, and approval. The user cannot add a custom protocol without modifying the node type.
• OAuth flows — the HTTP node supports bearer tokens and API keys, but not full OAuth flows. The user can use a third-party tool for OAuth flows.
• WebSocket — the integration nodes are HTTP-based (or polling-based for RSS). The user cannot use a WebSocket connection.

The integration nodes focus on the common protocols. The less common protocols are covered by the user’s existing tools.

What success looks like

The integration nodes are the right shape for the user to connect a workflow to an external system. The user picks a node type; the user configures the node; the workflow runs.

The HTTP node is the most general integration node. The user can call any REST API. The HTTP node supports the common authentication schemes, the common body formats, the common retry policies.

The RSS node is the right shape for the user to poll an RSS feed. The user configures the URL, the polling interval, the filter. The node deduplicates items by URL.

The email node is the right shape for the user to send an email. The user configures the recipients, the subject, the body, the attachments, the SMTP server.

The file watcher node is the right shape for the user to trigger a workflow when a file changes. The user configures the path, the event, the filter.

The git event node is the right shape for the user to trigger a workflow when a git event happens. The user configures the event, the repository, the branch.

The approval node is the right shape for the user to suspend a workflow until a human approves. The user configures the approvers, the required approvals, the timeout.

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 dry-run or step replay before starting the complete workflow again.

Related next action

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