Node Types

Available nodes for building integration workflows

This is the reference for every node type Integration Studio supports. Each entry explains what the node is for, what you configure on it, and what it hands to the next step. It's meant to be dipped into rather than read front to back — if you haven't built a workflow yet, Workflow Builder shows how the nodes connect; come back here once you know roughly what you're building and need the specifics.

The nodes fall into five families, and most workflows draw from several of them. Triggers start a workflow, and there's exactly one per workflow — a webhook, a schedule, or a manual button. Actions reach out and do something in the world, like an HTTP request or an email. Transforms reshape data as it passes through, with JSON mappings, filters, and regex. Control-flow nodes decide where data goes or loop over it, namely Switch and Iterator. And file-operation nodes move files in and out of storage with Download and Upload.

Beyond what ships today, the platform has a roadmap of additional nodes — Postgres, CSV, BMECAT, Cache, and more — covered at the bottom of this page.

Triggers

A trigger is what makes a workflow run, and every workflow has precisely one. The choice mostly comes down to who starts the run: an external system, the clock, or a person. The three trigger nodes below map onto exactly those cases. For the deeper treatment — webhook security, cron syntax, parameter forms — see the dedicated Triggers page; this section is the quick catalog entry for each.

Webhook Trigger

The webhook trigger turns your workflow into an HTTP endpoint that an external system can call. When a request arrives at the configured path, the workflow starts and the request's body, headers, and query string become its input. This is how you react to things that happen elsewhere — an order placed on a storefront, a file dropped by a supplier, a status change pushed by a payment provider.

Config:

path: URL path (e.g., /orders/received)
method: HTTP method to accept (default: POST)

Outputs:

request.body — Raw JSON body from the POST
request.headers — HTTP headers (Authorization, Content-Type, etc.)
request.query — Query string parameters

Example:

JSON

{
  "connector": "webhook-trigger",
  "config": {
    "path": "/orders/received",
    "method": "POST"
  }
}

Reach for it whenever another system needs to tell yours that something happened — order creation from an e-commerce platform, file uploads from an external system, or real-time events from a third-party webhook provider.

Schedule Trigger

The schedule trigger runs a workflow on a recurring clock, expressed as a cron pattern. There's no caller and no incoming data — the platform simply fires the workflow at the times you specify, in the timezone you choose. Because nothing is waiting on a response, schedule triggers only run on the async engine.

Config:

schedule: Cron expression (e.g., 0 9 * * MON = 9am every Monday)
timezone: Timezone (default: UTC)

Example:

JSON

{
  "connector": "schedule-trigger",
  "config": {
    "schedule": "0 */6 * * *",
    "timezone": "Europe/Zurich"
  }
}

This is the trigger behind any "every night / every hour" job — nightly data imports, hourly price syncs, weekly reconciliation reports.

Manual Trigger

The manual trigger puts a button in Cockpit (or exposes a programmatic call) that a person can press to run the workflow on demand. You can declare parameters, and Cockpit renders a small form for them so the operator can supply inputs like an order ID before the run starts.

Config:

parameters: Array of input fields (name, type, required)

Example:

JSON

{
  "connector": "manual-trigger",
  "config": {
    "parameters": [
      { "name": "order_id", "type": "string", "required": true },
      { "name": "force_retry", "type": "boolean", "required": false }
    ]
  }
}

It's the natural fit for human-in-the-loop work — one-off syncs, retrying a known failure by hand, or exercising a workflow while you're still building it.

Actions

Actions are the nodes that actually do something outside the workflow — they call other systems and cause side effects. Where transforms only rearrange data in memory, an action sends an HTTP request or dispatches an email. They're usually the reason a workflow exists in the first place; everything else is plumbing around them.

HTTP Request

This is the workhorse of Integration Studio. It makes an HTTP call — any standard method — to any reachable endpoint, with full control over the URL, headers, and body, all of which accept expressions so you can build the request from earlier step outputs and secrets. The vast majority of integrations are, at heart, one system's data shaped into another system's HTTP API, and this node is how that shaping reaches the wire.

Config:

method: GET, POST, PUT, DELETE, PATCH
url: Endpoint URL (supports {{expressions}})
headers: Key-value object (supports expressions)
body: Request body (supports expressions)
timeoutMs: Timeout in milliseconds (default: 30000)

Outputs:

status — HTTP status code
headers — Response headers
body — JSON or text response body

Example:

JSON

{
  "connector": "http-request",
  "config": {
    "method": "GET",
    "url": "https://erp.example.com/api/orders/{{steps.0.outputs.order_id}}",
    "headers": {
      "Authorization": "Bearer {{secrets.ERP_API_KEY}}",
      "X-Tenant": "{{$.tenant_id}}"
    },
    "timeoutMs": 60000
  }
}

You'll use it for nearly everything that crosses a network boundary — querying an ERP, calling a third-party API, or forwarding a webhook on to another service.

Send Email

The send-email node dispatches a transactional email over SMTP. The recipient, subject, and HTML body all accept expressions, so you can address the message to a customer pulled from an earlier step and fill the body with order details. It's a fire-and-forward action: it sends the message and reports success, but it doesn't track opens or deliverability beyond the SMTP handoff.

Config:

to: Recipient email (supports expressions)
cc: CC recipients (comma-separated, optional)
subject: Email subject
body: HTML email body (supports expressions)
from: Sender email (default: system@revenexx.com)

Example:

JSON

{
  "connector": "send-email",
  "config": {
    "to": "{{steps.0.outputs.customer_email}}",
    "subject": "Order {{steps.0.outputs.order_id}} Confirmed",
    "body": "<p>Your order total is {{steps.0.outputs.total}}.</p>",
    "from": "orders@example.com"
  }
}

Typical uses are the small notifications that hang off a workflow — order confirmations, invoice delivery, and alerts when something needs a human's attention.

Transforms

Two systems almost never agree on the shape of their data. One calls it supplier_aid, the other sku; one nests the price three levels deep, the other wants it flat. Transform nodes are where you bridge that gap — they take the data flowing through the workflow and reshape, filter, or extract from it, all in memory and without any external call. In a typical "fetch from A, send to B" workflow, the transforms are the middle that makes B accept what A produced.

JSON Transform

The JSON Transform node restructures an object according to a mapping you define, much like a jq expression. You describe the output shape you want and, for each field, write an expression that picks the corresponding value out of the input. Fields that aren't in the mapping are dropped, so it's as much about discarding noise as it is about renaming and reshaping what you keep.

Config:

mapping: Object defining the output structure (supports expressions)

Inputs: Previous step output
Outputs: Transformed object

Example:

JSON

{
  "connector": "json-transform",
  "config": {
    "mapping": {
      "sku": "{{$.articles[0].supplier_aid}}",
      "price": "{{$.articles[0].price}}",
      "currency": "EUR"
    }
  }
}

It's the node you reach for whenever an API's response doesn't match what the next system expects — flattening nested objects, renaming fields, or paring a large payload down to the handful of fields you actually need.

Filter

The Filter node takes an array and keeps only the items that satisfy a condition, dropping the rest. The condition is an expression evaluated against each element, where item refers to the element under test. Use it to narrow a collection before a later step acts on it — there's no point iterating over or sending records you're only going to ignore.

Config:

expression: Condition to evaluate (supports expressions)

Example:

JSON

{
  "connector": "filter",
  "config": {
    "expression": "{{item.price > 100}}"
  }
}

Common cases are trimming a list down to what matters — keeping only high-value items, dropping cancelled orders, or removing duplicates before processing.

Regex Extract

Not everything arrives as clean JSON. When the data you need is buried in a string — an order number inside an email body, a tracking code in a plain-text response — the Regex Extract node pulls it out. You give it a pattern with capture groups and a source string, and it returns the captured fragments as an array.

Config:

pattern: Regex pattern with capture groups
source: Input string (supports expressions)

Example:

JSON

{
  "connector": "regex-extract",
  "config": {
    "pattern": "Order-([A-Z0-9]+)",
    "source": "{{steps.0.outputs.body}}"
  }
}

Outputs:

matches — Array of capture groups

It's the right tool for fishing structured values out of unstructured text — parsing an order ID out of an email, or lifting a tracking number from a carrier's response body.

Control Flow

Most workflows are a straight line — one step feeds the next. Control-flow nodes are what you add when the line needs to branch or repeat: send different data down different paths, or run the same steps once per item in a list. They don't touch the data themselves; they decide what runs and how often.

Switch

The Switch node routes the workflow down different paths depending on the data. You give it an ordered list of cases, each pairing a condition with a named output; the first condition that matches wins, and an optional default case catches everything else. It's the workflow equivalent of an if/else if/else — the place where "paid orders go here, pending orders go there" gets expressed.

Config:

cases: Array of condition/output pairs

Example:

JSON

{
  "connector": "switch",
  "config": {
    "cases": [
      { "condition": "{{steps.0.outputs.status == 'paid'}}", "output": "process_order" },
      { "condition": "{{steps.0.outputs.status == 'pending'}}", "output": "hold_order" },
      { "default": true, "output": "reject_order" }
    ]
  }
}

Reach for it when one workflow has to handle several cases differently — branching on order status, say, or routing records to different downstream systems based on a field.

Iterator

The Iterator node runs the steps that follow it once for each element of an array, so a workflow that knows how to handle one record can handle a batch of them. Inside the loop, {{item}} refers to the current element. This is how a single "import orders" workflow processes a response that contains fifty orders rather than one.

Config:

items: Array to iterate (supports expressions)

Example:

JSON

{
  "connector": "iterator",
  "config": {
    "items": "{{steps.0.outputs.articles}}"
  }
}

Inside iterator: Use {{item}} to reference current array element.

It earns its place whenever the data arrives in bulk — processing every order in an import, or syncing each line item of a product.

File Operations

Some integrations don't traffic in JSON payloads at all — they move files. Supplier catalogs arrive as CSVs on an SFTP server; reports need to land in a customer's bucket. The two file-operation nodes handle the two directions of that flow: pulling a file in, and pushing one back out.

Download

The Download node fetches a file from a URL and stages it locally for the rest of the workflow, returning its path along with size and MIME type. It's usually the first step in a file-processing pipeline — get the file, then iterate and transform its contents in later steps.

Config:

url: URL to download from (supports expressions)
filename: Local filename to save as (optional)

Outputs:

path — Local file path
size — File size in bytes
mime_type — Content type

Example:

JSON

{
  "connector": "download",
  "config": {
    "url": "https://supplier.example.com/catalogs/{{steps.0.outputs.catalog_id}}.csv"
  }
}

Typical starting points are pulling in a product catalog, fetching an inventory report, or retrieving a customer's data export.

Upload

The Upload node is the mirror image: it writes a file to cloud storage — S3, Google Cloud Storage, or Azure Blob — at the path you specify, optionally making it publicly accessible. It's how a workflow persists a result that's too large or too file-shaped to hand back as a JSON response.

Config:

provider: s3 | gcs | azure
bucket: Destination bucket name
path: Remote file path (supports expressions)
file: Local file path or contents
public: Make file publicly accessible (default: false)

Example:

JSON

{
  "connector": "upload",
  "config": {
    "provider": "s3",
    "bucket": "order-imports",
    "path": "orders/{{steps.0.outputs.date}}/{{steps.0.outputs.order_id}}.json",
    "file": "{{steps.1.outputs}}"
  }
}

It closes the loop on file work — archiving processed data, exporting a report to the customer's own storage, or keeping a backup of an integration's output.

Roadmap (Vision)

These node types are planned but not yet shipped. The DX-29 source ticket calls them out specifically; the platform team is working on specifications and timelines.

Postgres node (planned)

Direct database operations against the tenant's own data — SELECT, INSERT, UPDATE, UPSERT. Automatically scoped to the tenant, so a workflow can only see and modify the rows for the tenant it runs on. Useful when an integration needs to write straight to a tenant table without going through an app's HTTP API.

Open spec questions: Does it allow connections to external Postgres databases (the customer's own), or only to the platform's tenant store? How are query parameters bound (Postgres-native, or via expression syntax)?

CSV node (planned)

Parse and produce CSV files. The common pattern is: download a CSV from an SFTP server or customer endpoint, run it through Iterator + Transform, then push the rows somewhere. Today this requires manual splitting after a Download node; a CSV node would do parsing and formatting natively.

BMECAT node (planned)

Parse and produce BMECAT XML — the dominant catalog-exchange format in European B2B procurement (especially for OCI and cXML punchouts). End customers in the European B2B market routinely need to import supplier catalogs in BMECAT and export their own catalogs to procurement systems. A native BMECAT node removes the need to hand-write the parser-and-generator pair.

Cache node (planned)

Read and write to a tenant-scoped cache. Useful for memoizing expensive sync workflows — e.g., a live price check that hits SAP. The first call goes to SAP, the next 60 seconds of calls return the cached result.

Open spec questions: Storage backend (in-memory per worker, or a shared cache)? TTL semantics? Eviction policy under memory pressure?

Other planned categories

Aggregation: group, sum, count over array items.
Date/Time: parse, format, calculate durations.
Cryptography: encrypt, decrypt, hash (HMAC-SHA256 for webhook signatures, AES for sensitive payloads).
AI/ML: sentiment analysis, text classification, OCR — likely backed by AI Studio.

Next Steps

Triggers — Detailed trigger configuration
Expression Syntax — How to write dynamic parameters
Workflow Builder — Canvas UI and execution modes

Was this page helpful?