Webhook
The webhook node is the entry point of every workflow. It listens for incoming events and triggers the workflow when one is received. Every workflow must begin with a webhook node — it cannot be deleted or moved to a different position in the flow. When you open the webhook node, you’ll see:- Test URL — a temporary endpoint for sending test events during development. Copy this URL to use when testing.
- Production URL — the live endpoint that triggers the workflow once it’s active.
- Response type — controls when the webhook sends a response back to the caller:
- Immediate — responds to the caller as soon as the webhook is received, before the rest of the workflow runs.
- After last node — waits until the final node in the workflow completes before responding. This adds a Response node to the end of your workflow.
HTTP
The HTTP node makes a call to an external API or service and passes the response downstream. Use it to query a pricing engine, send data to your ERP, or trigger actions in other tools. Configuration options:- URL — the API endpoint to call.
- Method — the HTTP method: GET, POST, PUT, DELETE, or PATCH.
- Authentication — select a pre-configured authenticator (OAuth2 or API key) to handle authentication automatically. Authenticators are configured under Administration > Authenticators.
- Headers — toggle on to add custom request headers as key/value pairs.
- Params — toggle on to add URL query parameters as key/value pairs.
- Body — toggle on to add a request body (JSON or raw text).
- Response mode — controls how the node’s response is passed to the next node:
- Replace — the HTTP response replaces the current data payload entirely.
- Append — the HTTP response is merged into the existing payload alongside previous data.
Transform
The transform node processes and modifies data as it moves through the workflow. Use it for calculations, field mapping, formatting, filtering, or any logic that needs to run between other steps. Transformation logic is written in JavaScript. The node provides a code editor where you write a function that receives the current data payload and returns a modified version. The input and output viewers show the live data state before and after transformation, making it easy to verify your logic is working correctly. Use the Test button to run the transformation against the current input data.Switch
The switch node routes data down different paths based on conditions you define. Use it to branch your workflow — for example, sending order requests one way and quote requests another. Each switch node contains one or more routes. Each route has:- Name — a label for the path (shown on the canvas connection line).
- Condition — a comparison that must be true for data to follow this route. A condition is a first value, an operator, and a second value. Drag data from the input viewer onto either value input to reference a field from the current payload, or type a literal.
- Default — one route can be marked as the default fallback, which is taken when no other conditions match.
Each route creates a separate output handle on the node. Connect each handle to the next node in that path. The switch node evaluates conditions in order and follows the first route that matches.
Every switch node should have a default route configured to handle cases where none of your conditions match.
If
The if node splits a workflow into two paths based on a single condition. Use it when you only need a yes/no decision — for example, “does this order include a hazardous material?” — and want to keep the canvas simpler than a full switch node. Configuration options:- Condition name — an optional label shown on the canvas so you can tell at a glance what the node checks.
- Condition — a first value, an operator, and a second value. Drag data from the input viewer onto either value input to reference a field from the current payload, or type a literal. Uses the same operators as the switch node (equal to, contains, greater than, etc.).
- Add else branch — by default, the if node only has a then output that fires when the condition is true. Click Add else branch to also create an else output for the false path. Click Remove else branch to drop the else path — any edges connected to it are removed.
Price check
The price check node compares the captured price (the unit price extracted from the source document — PDF, Excel, email, etc.) against the ERP price (any price coming from another source, typically your ERP) for each line in the payload and decides which one becomes the final unit price. Use it to reconcile pricing discrepancies before an order is confirmed downstream. The node only rewrites lines where the two prices are close enough to be considered the same offer. Lines with a bigger gap are passed through untouched so a human can review them. Configuration options:-
Run if — an optional gate that decides whether the check runs for a given payload. Uses the same first value / operator / second value pattern as other conditions. Leave both values empty to always run. Example: skip payloads whose warnings mention mounting by setting the first value to the warnings field and using does not contain with
mounting. -
Max price deviation (%) — the check only applies when the captured and ERP unit prices differ by at most this percentage. Lines with a bigger gap are left untouched. Defaults to
5. - Price cap — lines where either unit price exceeds this amount are left untouched. Leave empty for no cap. Useful for holding back high-value lines for manual review regardless of deviation.
-
Retain — which price becomes the line’s final unit price when the check applies:
- Captured price — keep the price extracted from the document. This also marks the price as user-selected so downstream systems treat it as manually confirmed.
- ERP price — replace the captured price with the ERP price.
- Write message — when enabled, appends an explanatory line to the payload’s messages every time the check is applied, describing the retained price, the deviation, and the recalculated total. Turn on for auditability; turn off to keep messages clean.
Sticky note
The sticky note is a canvas annotation, not an executable step. Use it to leave context on a workflow — a reminder about why a branch exists, a TODO for a teammate, or a section header that groups related nodes. Sticky notes are ignored at runtime and never appear in execution logs. Drag Sticky note from the node inventory onto the canvas to add one. Double-click a sticky note (or click Edit in its toolbar) to open the full editor, where a larger textarea makes it easy to write longer notes. Configuration options:- Text — the note’s content. Type directly on the canvas for short notes; open the editor for longer ones. Text that overflows the visible area on the canvas is clipped with a subtle fade — the full content is always visible in the editor.
- Color — pick from yellow, pink, green, or blue using the swatches in the node’s floating toolbar or in the editor. Use color to distinguish note types at a glance (e.g., yellow for reminders, pink for warnings).
- Size — drag the corner handles when the note is selected to resize it. Sticky notes have a fixed minimum and maximum size; text past the maximum is clipped on the canvas but preserved in the editor.