Guide
Build and run your first HTTP graph
Place two nodes, wire an exec chain and a data port, run the graph and read the console.
Build and run your first HTTP graph
In about ten minutes you will place two nodes, wire an exec chain and a data port, run the graph, read the console, save it, and decide how to share it.
Before you start
No account is needed to draw the first draft. Running and saving ask you to sign in with a verified email address. The tutorial uses the HTTP and Output categories of the node catalog; if you have not opened the catalog yet, it is the panel next to the canvas.
1. Open a blank canvas
Go to the editor and stay at the workspace root. You do not need an account to draw: the draft lives in this browser until you save it.
Tip: Give the graph a name in the header so you can find it again. A reload restores the draft.
2. Add two nodes
Open the node catalog and drag HTTP GET from the HTTP category, then Print from Output. The editor stamps each node with the catalog version it was dropped from.
http_get, print
Tip: The version matters: the runner downloads exactly that version, so an update never changes a graph silently.
3. Wire the exec chain first
Drag from the Start node's exec output to HTTP GET's exec input, then from HTTP GET's exec
output to Print's exec input. Exec ports decide the order of work.
start
Tip: If a node never runs, the missing connection is almost always an exec link, not a data link.
4. Wire the data port
Connect HTTP GET's response output to Print's in input. The port type is a dictionary, so the
editor accepts the connection and the Print node receives the response.
Tip: The editor refuses mismatched types. If a port will not connect, check the type shown on both ends.
5. Set the parameters
Select HTTP GET, open its parameters and set url to a small endpoint you control, or keep the
default https://example.com. Set a prefix on Print so the log line is easy to spot.
Tip: Parameters are stored on the node. Values that arrive on a port override the parameter at run time.
6. Run and inspect the log
Press Run. The API starts or reuses a container for the graph, the runner executes the nodes, and the console shows stdout plus one event per node. Nodes turn green while they run.
Tip: Expand the events in order: the GET node reports its request, then Print reports the dictionary it received. A failed node keeps the error in the same log.
7. Save the graph
Save asks you to sign in and to have a verified email address. It writes the whole structure — nodes, connections, container settings and generated nodes — to the project you choose.
Tip: If you are signed in but Save still refuses, check the email verification status on the account page before assuming the graph is broken.
8. Publish or import
Snapshot the saved graph into the store as a free or paid product, open or closed, with a one-time or rental variant. To reuse someone else's work, open a public example, fork it, or import an owned asset from the Library.
Tip: A closed snapshot never reaches the browser: only its interface is visible, and the API decrypts it in memory when an entitled run starts.
What the console should show
run started · graph "My first HTTP graph"
http_get · request GET https://example.com
http_get · response 200 · dict
print · in: status 200 · headers · body
run finished · 2 nodes · 0 errors
Values are illustrative: the exact body depends on the endpoint you call. What matters is the order — the GET node finishes before Print runs, because the exec chain says so.
How the run actually works
The editor sends the graph structure to the API. The API starts or reuses a Docker container for that
graph and calls the runner inside it. The runner fetches each node at the version pinned in the graph
— from the package registry, or by cloning a third-party source — imports its Node class, starts
one asyncio task per node, and connects the ports with queues. Every stdout line and node event is
posted back to the API, re-emitted over Socket.IO, and printed in the console you are watching.
Common mistakes
- The node never runs. No exec connection reaches it. Exec ports carry control flow; data ports alone do nothing.
- A port refuses the connection. The types differ. A number port will not accept a dictionary and vice versa.
- Save is unavailable. The account is not signed in or its email is not verified yet. The draft remains in the browser.
- The run fails before any node starts. A pinned node version could not be fetched. The runner fails the run instead of quietly using another version.
Tips that save time
- Keep the first graph small. One request and one Print node is enough to prove the wiring.
- Use Print and Print JSON instead of guessing; the console is the fastest debugger here.
- Name groups after the step they perform, not after the nodes inside them.
- Pin node versions by dropping from the catalog and avoid editing the version by hand.
- For a server graph, add HTTP Server → HTTP Route → HTTP Respond after this exercise, then test with a request from outside the container.
- When a graph grows past one screen, cut it into groups with clear input and output ports.
Open a finished graph next
Reading a working graph is faster than reading another guide. The examples page links public graphs you can open in the editor and fork; the store has open and closed assets with a documented interface.