How to build a workflow you can actually inspect

Why we built it this way

Most workflow tools make you choose: a visual canvas that hides what's actually running, or code that gets you out of the canvas entirely. Nodesin started as an internal engine for orchestrating high-frequency APIs and long-running agents, and the two things we kept wanting were a canvas with prebuilt connectors, and code as a real step on that canvas — not an escape hatch you drop into when the drag-and-drop version runs out of road.

The other thing we wanted was a bill that didn't grow every time we added a step to a workflow that was already working. Executions are metered per month, not per node. Building a workflow properly — more steps, better error handling — doesn't cost more.

What's actually running under the canvas

A workflow in Nodesin compiles to a directed graph. That's not marketing language — it's what lets you open any node while a run is in flight and see its resolved inputs, its output, and the expression that produced them. Nothing is inspectable "after the fact" only; you can watch it while it executes.

The pieces that make that possible:

Canvas — the graph compiler and inspector. Every node's state and payload is visible mid-run.

Code — a sandboxed runtime. JavaScript runs in its own process, filesystem and subprocess access denied, under a memory ceiling and wall-clock timeout. Python runs the same way when an operator turns it on.

Vault — credentials encrypted with AES-256-GCM at rest, decrypted only in worker memory for the length of a single node call. Never written to logs, never sent to the browser.

Queue — non-blocking, so a burst of webhooks or a cron spike gets absorbed instead of dropped, and a long-running workflow doesn't hold up a short one behind it.

History — every change to a workflow is a commit. You get structural diffs between versions and can roll back one that turns out wrong.

Audit — sign-ins, workflow edits, and credential changes are logged with who and when, alongside replayable execution traces for debugging failures later.

Building your first workflow

Start from a trigger. A webhook, a cron schedule, or a manual run — whatever kicks off the workflow you're automating.

Wire in a connector node for the app or API you're integrating with. If there isn't a prebuilt one, an HTTP Request node or a generic webhook receiver gets you there.

Drop in a code step where the visual nodes run out. This is the part worth sitting with: code in Nodesin is a step on the canvas like any other, with its own inspectable input and output — not a black box you tunnel through to get real work done.

Add an AI step if the workflow needs judgment, not just data movement. You can configure a master key or a per-workflow credential against OpenAI, Anthropic, Google Gemini, Groq, or Mistral models, depending on what the step actually needs.

Write results to a table if you need state that persists between runs — schema editing, CSV import/export, and nodes that read and write mid-run are built into the workspace, so you're not standing up a separate database for a workflow that just needs to remember something.

Run it, then open any node in the completed run to see exactly what it received and returned. If something's wrong, you're looking at the actual payload, not a summary of it.

The assistant, and what it's actually good for

Mira reads the graph you have open. Ask her to draft a workflow from a description and she'll wire up a starting point; when a run fails, she points at the specific step that broke rather than the whole run. She's built on the same principle as everything else here — when she doesn't know something about your workflow, she says so rather than guessing at what a node's schema might be.

What we're not going to trade away

Three calls get made the same way every time, even when the shortcut is tempting:

Nothing hidden. Every intermediate output is inspectable, replayable, and diffable.

Code is not an escape hatch. It's a step on the canvas, with the same visibility as everything else.

Predictable pricing. Executions are counted per month, not per step — no overage surprise for building the workflow properly instead of cramming it into fewer nodes.

Where this is going next

We're a small team, and the roadmap moves based on what people building on Nodesin tell us is missing. Right now that's multi-agent runs that can repair their own failed steps, edge workers to cut the delay between a webhook firing and a run actually starting, a connector marketplace with an SDK for writing your own nodes, and SAML/SCIM with log streaming for teams that need it.

If you're evaluating workflow tools and the black-box part of the usual options is what's been slowing you down, that's the gap we built this to close.