From canvas to paid endpoint.

Calls any REST API over http or https. This is a free node (Suede charges nothing for it; you pay whatever the target API charges), and it is the app's primary SSRF surface, so every request is validated before it's made.

SSRF guard. The URL's scheme must be http or https. Requests are blocked to a fixed set of hostname literals (localhost, localhost.localdomain, ip6-localhost, ip6-loopback, and anything ending in .local, .internal, or .localhost) and to reserved IP ranges: loopback (127.0.0.0/8), the three RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local (169.254.0.0/16, which also covers the 169.254.169.254 cloud metadata endpoint), 0.0.0.0/8, and the 100.64.0.0/10 CGNAT range, plus the IPv6 equivalents (loopback, unspecified, link-local, unique-local, and IPv4-mapped addresses resolved through the same IPv4 list). The hostname is resolved and the resolved address is checked, not just the hostname string, and the same check runs again before every redirect hop (up to 5 redirects). This narrows but does not close DNS rebinding: validation and the actual connection are two separate DNS lookups a few milliseconds apart, so a resolver that changes its answer inside that window could still slip through. Closing that gap fully would need pinning the socket to the exact validated IP, which this pass does not do.

A 303 redirect downgrades the method to GET and drops the body; every other redirect status preserves both. The response body is capped at 2 MB, read in a stream and aborted (not truncated) if it goes over; the request itself times out after the configured timeoutMs (10000 by default, 30000 max).

Output: { status: number, body: <parsed JSON if the response is application/json, otherwise the raw text> }

Dry-run: no request is made. The node returns a placeholder in the same envelope shape so a downstream node still typechecks, but the body content is a fixed marker, not a guess at what the real target would have returned:

{
  "status": 200,
  "body": {
    "dryRun": true,
    "note": "HTTP request skipped during dry-run; no real request was made.",
    "method": "POST",
    "url": "https://example.com/webhook"
  }
}

A trigger node: an external service (GitHub, Stripe, Slack, your own backend) posts JSON to this agent's webhook URL and the flow runs with that body as its input. Authentication is not a node field. A signing secret is generated once, server-side, when you launch the agent, and shown to you exactly once. It cannot be recovered later; relaunching an agent that already has a webhook endpoint leaves the existing secret untouched rather than rotating it out from under whatever third party is already using it.

Calling it. POST to /api/agents/<agent-id-or-slug>/webhook with a JSON body (application/json, exactly, charset suffix aside; anything else is rejected) and two headers: x-suede-webhook-signature (sha256=<hex>) and x-suede-webhook-timestamp (Unix milliseconds, as a decimal string). The signature is an HMAC-SHA256, keyed by your webhook secret, over the exact string <timestamp>.<raw request body bytes, before any JSON parsing>. Binding the timestamp into the signature means a captured request can't be replayed with a new timestamp without also forging a new signature, and requests signed more than 5 minutes off the current time (either direction) are rejected as stale. The request body is capped at 256 KB. A bad signature, a stale timestamp, and a nonexistent agent all return the same generic 401, on purpose, so a caller can't use the response to enumerate which agent ids or slugs exist. Both the source IP and the agent id are separately rate-limited.

Output: the inbound JSON body, forwarded as-is (wrapped as { body: <value> } if the posted JSON wasn't a plain object).

Dry-run: not stubbed. A webhook delivery's dry-run mode is decided by the agent's own settlement setting, never by the caller. An agent that hasn't gone live stays free no matter what a third party sends, and a live agent is never forced back into a free run either.

Security note: the secret is stored as a hash, but that stored value is also the literal HMAC key used to verify every request, so a database compromise gets an attacker forgeable signatures. That is the same property Stripe's and GitHub's webhook secrets have; there is no way to have a recoverable HMAC key that a database read can't also recover.

Reshapes data between steps: plucks a field, builds a new object, filters or formats a list, without a round trip through an LLM. This is not a code-execution node: the expression language is a small, non-Turing-complete grammar. There is no eval or new Function, no globals, no network or filesystem access, no require or import, no user-defined functions, and no loop construct beyond the single fixed-arity map() builtin.

Grammar. Path access with in.field or in.items[0].id; arithmetic (+ - * / %); comparisons (== != < <= > >=); logical && and ||; unary ! and -; a ternary test ? a : b; object literals ({ key: value, ... }); and array literals ([ a, b, c ]). Builtins: map, len, upper, lower, trim, join, split, get, jsonParse, jsonStringify, number, string, default. map() is the one binder in the language: map(array, item => expr) evaluates its lambda body once per array element with item scoped to that call only.

{ email: in.user.email, count: len(in.items) }

map(in.items, x => x.id)

in.status == "active" ? "go" : "hold"

Limits, all enforced before or during evaluation: 5000 characters of source, 1000 tokens, 24 levels of nesting, 500 AST nodes total, 20000 evaluation steps (this is what bounds map() fanning out over a large array), a 1000ms wall-clock budget per evaluation, 1000 items max for map()/join()/split(), and 200,000 characters max for jsonParse()'s input. __proto__, constructor, and prototype are denied everywhere, static and dynamic, so no path through the language can reach the prototype chain.

Dry-run: not stubbed. This is local computation only, so it always runs for real, dry run or not.

Runs another flow once per element of an upstream array and collects the per-element results in order. Without this node, a flow author has to pre-batch an entire array into one blob and ask a single LLM call to handle all of it at once, forcing an all-or-nothing retry on any hiccup. The loop node itself never makes a paid or external call; every dollar it can spend comes from the nodes inside the subflow it runs.

Failure policy: collect errors, not fail fast. Every element is attempted; one flaky item does not stop the others. The loop node itself still reports success as long as it could start (a valid array, a loadable subflow, within the iteration cap). Per-element failures land in the errors output instead of failing the whole node. The cost trade-off is explicit: because every element still runs, the worst-case cost of a loop is always up to N times the subflow's cost, whether or not some elements fail.

Output: two separate outputs, result and errors. Each entry in result is the full outputs record from that element's nested run (keyed by the subflow's own internal node ids), or null if that element failed. Each entry in errors is { index, error }, where error names the subflow node that failed:

{
  "result": [
    { "<subflow-node-id>": { "result": "..." } },  // item 0: succeeded
    null,                                            // item 1: failed, see errors
    { "<subflow-node-id>": { "result": "..." } }    // item 2: succeeded
  ],
  "errors": [
    { "index": 1, "error": "<subflow-node-id>: <message>" }
  ]
}

Cost ceiling. Every run (top-level or nested) shares one in-run cost ceiling, checked before every cost-bearing node runs. The ceiling is the minimum of an absolute per-run cap (the RUN_COST_CEILING_USDC environment variable, $5 if unset or invalid) and the agent's own remaining daily budget at the start of the run. If a loop iteration's nested run gets aborted for hitting that ceiling, it is not treated as a per-element failure: no further iterations start, and the loop node itself fails with a message stating how many of the N iterations completed before the abort, so the abort propagates to the whole run instead of being swallowed by collect-errors.

Nesting. A loop's subflow runs one level deeper than the run that called it, and the engine bounds total subflow/loop nesting with a depth guard: 16 levels. Loops inside subflows (and loops inside loops) are legal up to that ceiling, all sharing the one in-run cost ceiling; a nested run that would cross the depth guard fails just that iteration, surfaced in errors, not the whole run.

Dry-run: not stubbed. The loop always runs for real so its inner nodes get a chance to see dry-run mode themselves; ctx.dryRun passes through unchanged to every nested run, so a dry-run loop still iterates fully, it just never lets an inner cost-bearing or side-effecting node spend anything.