Core

Built-in SuperPlane components.

Triggers

Schedule Start a new execution chain on a schedule

Manual Run Start a new execution chain manually

Webhook Start a new execution chain when a webhook is called

Actions

Approval Collect approvals on events

Filter Filter events based on their content

HTTP Request Make HTTP requests

If Route events based on expression

Merge Merge multiple upstream inputs and forward

No Operation Just pass events through without any additional processing

SSH Command Run a command on a remote host via SSH. Authenticate using an organization Secret (SSH key or password).

Time Gate Route events based on active days and time windows, with optional excluded dates

Wait Wait for a certain amount of time

Schedule

The Schedule trigger starts workflow executions automatically based on a configured schedule.

Use Cases

Periodic tasks: Run daily reports, backups, or maintenance tasks
Data synchronization: Regularly sync data between systems
Monitoring: Periodic health checks and monitoring
Batch processing: Process data on a recurring schedule

Schedule Types

Minutes: Trigger every N minutes (1-59)
Hours: Trigger every N hours at a specific minute (1-23 hours)
Days: Trigger every N days at a specific time (1-31 days)
Weeks: Trigger every N weeks on specific weekdays at a specific time (1-52 weeks)
Months: Trigger every N months on a specific day and time (1-24 months)
Cron: Use a cron expression for advanced scheduling patterns

Timezone Support

For days, weeks, months, and cron schedules, you can specify a timezone to ensure triggers occur at the correct local time.

Cron Expressions

Supports both 5-field and 6-field cron expressions:

5-field: minute hour day month dayofweek (e.g., 30 14 * * MON-FRI)
6-field: second minute hour day month dayofweek (e.g., 0 30 14 * * MON-FRI)

Event Data

Each scheduled execution includes calendar information:

calendar: Year, month, day, hour, minute, second, week_day
timezone: Timezone information (for applicable schedule types)

Examples

Every 15 minutes: Minutes schedule with 15-minute interval
Daily at 9 AM: Days schedule with hour=9, minute=0
Weekdays at 2 PM: Weeks schedule with weekDays=[Monday-Friday], hour=14
First of every month: Months schedule with dayOfMonth=1

Example Data

{
  "calendar": {
    "day": "1",
    "hour": "09",
    "minute": "00",
    "month": "January",
    "second": "00",
    "week_day": "Monday",
    "year": "2024"
  },
  "timezone": "+00:00"
}

Manual Run

The Manual Run trigger allows you to start workflow executions manually from the SuperPlane UI.

Use Cases

Testing workflows: Manually trigger workflows during development and testing
One-off tasks: Run workflows on-demand for specific operations
Debugging: Manually execute workflows to debug issues
Ad-hoc processing: Process data when needed without automation

How It Works

Add the Manual Run trigger as the starting node of your workflow
Click the “Run” button in the workflow UI to start an execution
The workflow begins immediately with empty event data

Configuration

The Manual Run trigger requires no configuration. It’s ready to use immediately after being added to a workflow.

Event Data

Manual runs start with an empty event payload. You can use this as a starting point and add data through subsequent components.

Example Data

{
  "foo": "bar"
}

Webhook

The Webhook trigger starts a new workflow execution when an HTTP request is received at the generated webhook URL.

Use Cases

External system integration: Receive events from third-party services
CI/CD pipelines: Trigger workflows from build systems
Form submissions: Process data from web forms
Event notifications: Receive notifications from external applications

How It Works

When you add a Webhook trigger to a workflow, SuperPlane generates a unique webhook URL
Configure the authentication method for the webhook
External systems can send HTTP requests to this URL
Each request starts a new workflow execution with the request data

Authentication Methods

Signature (HMAC): Verify requests using HMAC-SHA256 signature in the X-Signature-256 header
Bearer Token: Require a Bearer token in the Authorization header
None (unsafe): No authentication (not recommended for production)

Request Data

The webhook payload includes:

body: Parsed request body (JSON if possible, otherwise raw data)
headers: All HTTP headers from the request

Security

Each webhook has a unique secret key for authentication
Secrets can be reset using the “Reset Authentication” action
Maximum payload size: 64KB

Example Usage

Send a POST request to the webhook URL with your payload. The workflow will receive the data and start execution.

Example Data

{
  "body": {
    "event": "push",
    "repository": "superplanehq/superplane"
  },
  "headers": {
    "X-Event": [
      "push"
    ]
  }
}

Approval

The Approval component pauses workflow execution and waits for manual approval from specified users, groups, or roles before continuing.

Use Cases

Deployment approvals: Require approval before deploying to production
Financial transactions: Get approval for high-value operations
Content moderation: Review content before publishing
Compliance workflows: Ensure regulatory approvals are obtained

How It Works

When the Approval component executes, it creates approval requirements based on the configured approvers
The workflow pauses and waits for all required approvals
Approvers receive notifications and can approve or reject from the workflow UI
Once all approvals are collected, the workflow continues:
- Approved channel: All required approvers approved
- Rejected channel: At least one approver rejected

Configuration

Approvers: List of users, groups, or roles who must approve
- Any user: Any authenticated user can approve
- Specific user: Only the specified user can approve
- Group: Any member of the specified group can approve
- Role: Any user with the specified role can approve

Output Channels

Approved: Emitted when all required approvers have approved
Rejected: Emitted when at least one approver rejects (after all have responded)

Actions

approve: Approve a pending requirement (can include an optional comment)
reject: Reject a pending requirement (requires a reason)

Example Output

{
  "data": {
    "records": [
      {
        "approval": {
          "approvedAt": "2024-01-01T12:00:00Z",
          "comment": "Looks good"
        },
        "index": 0,
        "state": "approved",
        "type": "user",
        "user": {
          "email": "alex@example.com",
          "id": "user_123",
          "name": "Alex Doe"
        }
      }
    ],
    "result": "approved"
  },
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "approval.finished"
}

Filter

The Filter component evaluates a boolean expression against incoming events and only forwards events that match the condition.

Use Cases

Data validation: Only process events that meet certain criteria
Event filtering: Filter out unwanted events before processing
Conditional routing: Stop processing events that don’t match requirements
Data quality: Ensure only valid data continues through the workflow

How It Works

The Filter component evaluates a boolean expression against the incoming event data
If the expression evaluates to true, the event is emitted to the default output channel
If the expression evaluates to false, the execution passes without emitting (effectively filtering out the event)

Expression Environment

The expression has access to:

$: The run context data
root(): Access to the root event data
previous(): Access to previous node outputs (optionally with depth parameter)

Examples

$["Node Name"].status == "active": Only forward events where status is “active”
$["Node Name"].amount > 1000: Filter events with amount greater than 1000
$["Node Name"].user.role == "admin" && $["Node Name"].action == "delete": Complex condition checking multiple fields

Example Output

{
  "data": {},
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "filter.executed"
}

HTTP Request

The HTTP component allows you to make HTTP requests to external APIs and services as part of your workflow.

Use Cases

API integration: Call external REST APIs
Webhook notifications: Send notifications to external systems
Data fetching: Retrieve data from external services
Service orchestration: Coordinate with microservices

Supported Methods

GET, POST, PUT, DELETE, PATCH

Request Configuration

URL: The endpoint to call (supports expressions)
Method: HTTP method to use
Query Parameters: Optional URL query parameters
Headers: Custom HTTP headers (header names cannot use expressions)
Body: Request body in various formats:
- JSON: Structured JSON payload
- Form Data: URL-encoded form data
- Plain Text: Raw text content
- XML: XML formatted content

Response Handling

The component emits the response with:

status: HTTP status code
headers: Response headers
body: Parsed response body (JSON if possible, otherwise string)

Error Handling & Retries

Configure timeout and retry behavior:

Fixed timeout: Same timeout for all retry attempts
Exponential backoff: Timeout increases with each retry (capped at 120s)
Success codes: Define which status codes are considered successful (default: 2xx)

Output Events

http.request.finished: Emitted on successful request
http.request.failed: Emitted when request fails after all retries
http.request.error: Emitted on network/parsing errors

Example Output

{
  "data": {
    "body": {
      "message": "ok"
    },
    "error": "Error to read request body: EOF",
    "headers": {
      "Content-Type": [
        "application/json"
      ]
    },
    "status": 200
  },
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "http.request.finished"
}

If

The If component evaluates a boolean expression and routes events to different output channels based on the result.

Use Cases

Conditional branching: Route events down different paths based on conditions
Decision logic: Implement if-then-else logic in workflows
Data routing: Send events to different processing paths
Workflow control: Control workflow flow based on event properties

How It Works

The If component evaluates a boolean expression against the incoming event data
If the expression evaluates to true, the event is emitted to the “True” output channel
If the expression evaluates to false, the event is emitted to the “False” output channel

Output Channels

True: Events where the expression evaluates to true
False: Events where the expression evaluates to false

Expression Environment

The expression has access to:

$: The run context data
root(): Access to the root event data
previous(): Access to previous node outputs (optionally with depth parameter)

Examples

$["Node Name"].status == "approved": Route approved items to True channel
$["Node Name"].amount > 1000: Route high-value items to True channel
$["Node Name"].user.role == "admin": Route admin actions to True channel

Example Output

{
  "data": {},
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "if.executed"
}

Merge

The Merge component waits for events from all upstream nodes before forwarding a combined result downstream.

Use Cases

Parallel processing: Wait for multiple parallel operations to complete
Data aggregation: Combine results from multiple sources
Synchronization: Synchronize multiple workflow branches
Fan-in patterns: Collect outputs from multiple upstream nodes

How It Works

The Merge component waits for events from all distinct upstream source nodes
Once all inputs are received, it emits the combined data to the Success channel
Optional timeout and conditional stop features allow early completion

Configuration Options

Enable Timeout: Cancel merge after a specified time if not all inputs are received
Enable Conditional Stop: Stop waiting early when a condition is met (e.g., if one branch fails)

Output Channels

Success: Emitted when all upstream inputs are received
Timeout: Emitted if the timeout is reached before all inputs are received
Fail: Emitted if the conditional stop expression evaluates to true

Behavior

Tracks distinct source nodes (ignoring multiple channels from the same source)
Combines all received event data into the output
Supports timeout to prevent indefinite waiting
Supports conditional early stop based on expression evaluation

Example Output

{
  "data": {
    "eventIDs": [
      "event_1",
      "event_2"
    ],
    "groupKey": "merge-group-123",
    "sources": [
      "node_a",
      "node_b"
    ],
    "stopEarly": false
  },
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "merge.finished"
}

No Operation

The No Operation component is a pass-through component that forwards events to downstream nodes without any modification or processing.

Use Cases

Testing workflows: Use this component to test workflow connections and flow without side effects
Placeholder nodes: Temporarily replace components during workflow development
Event forwarding: Simply forward events when no processing is needed

Behavior

When executed, the No Operation component immediately emits the incoming event data to the default output channel without any transformation. It has no configuration options and requires no setup.

Example Output

{
  "data": {},
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "noop.finished"
}

SSH Command

Run a single command on a remote host via SSH.

Authentication

Choose SSH key or Password, then select the organization Secret and the key name within that secret that holds the credential.

SSH key: Secret key containing the private key (PEM/OpenSSH). Optionally a second secret+key for passphrase if the key is encrypted.
Password: Secret key containing the password.

Configuration

Host, Port (default 22), Username: Connection details.
Command: The command to run (supports expressions).
Working directory: Optional; Changes to this directory before running the command.
Timeout (seconds): How long the command may run (default 60).
Connection retry (optional): Enable to retry connecting when the host is not reachable yet (e.g. server still booting). Set number of retries and interval between attempts.

Output

success: Exit code 0
failed: Non-zero exit code

Example Output

{
  "result": {
    "exitCode": 0,
    "stderr": "",
    "stdout": "Hello, World!\n"
  }
}

Time Gate

The Time Gate component delays event processing until the next valid day and time window, with optional excluded dates.

Use Cases

Business hours: Only process events during business hours
Scheduled releases: Delay deployments until off-peak hours
Holiday handling: Exclude specific dates from processing
Time-based routing: Route events based on time of day or specific dates

Configuration

Active Days: Days of the week when the gate can open
Active Time: Start and end times in HH:MM-HH:MM format (24-hour)
Timezone: Timezone offset for time calculations (default: current)
Exclude Dates: Specific MM/DD dates that override the rules above

Behavior

Events wait until the next valid time window is reached
Exclude dates override the day/time rules
Can be manually pushed through using the “Push Through” action
Automatically schedules execution when the time window is reached

Example Output

{
  "data": {},
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "timegate.finished"
}

Wait

The Wait component pauses workflow execution for a specified duration or until a specific time is reached.

Use Cases

Rate limiting: Add delays between API calls
Scheduled execution: Wait until a specific time before proceeding
Retry delays: Wait before retrying failed operations
Time-based workflows: Delay processing until a specific date/time

Wait Modes

Interval: Wait for a fixed duration (seconds, minutes, or hours)
- Supports expressions for dynamic wait times
- Example: {{$.retry_delay}} or {{$.status == "urgent" ? 0 : 30}}
Countdown: Wait until a specific date/time is reached
- Supports ISO 8601 date formats
- Supports expressions for dynamic target times
- Example: {{$.release_date}} or {{$.run_time + duration("48h")}}

Behavior

Execution pauses until the wait period completes
Can be manually pushed through using the “Push Through” action
Automatically resumes when the wait time expires
Emits metadata including start time, finish time, and result

Output

The component emits a payload with:

started_at: When the wait began
finished_at: When the wait completed
result: Completion status (completed, cancelled)
reason: How it completed (timeout, manual_override, user_cancel)

Example Output

{
  "data": {
    "actor": {
      "display_name": "Alex Doe",
      "email": "alex@example.com"
    },
    "finished_at": "2024-01-01T12:05:00Z",
    "reason": "timeout",
    "result": "completed",
    "started_at": "2024-01-01T12:00:00Z"
  },
  "timestamp": "2026-01-16T17:56:16.680755501Z",
  "type": "wait.finished"
}