custom blocks & middleware Your own blocks, beside the built-ins.

When the same few blocks appear in route after route — notify Slack, check a token, call an internal API — package them once. Fix it in one place; every route gets the fix.

Read the docs

Build the inside once, design the settings form, and the block shows up in the picker next to the built-ins. Fix it once and every route that uses it gets the fix.

settings form

You design the form people fill in.

Each parameter becomes a field on the block's Parameters tab. Inside the block, scripts read them as params.

Text input URLs, names, messages — accepts js: expressions
Checkbox · Dropdown on/off options and fixed choices
Array editor lists of values
Integration picker choose which database or queue to use
App Config picker secrets by name — the value never lands on the canvas

execution modes

Wait for it, fire and forget, or queue it.

Each placement of a custom block picks how it runs. Use queued for work that must survive a restart; make it safe to run twice, because it may be retried.

Grey: your route. Violet: the custom block. Queued work only receives the block's parameters and input — request headers, cookies and variables aren't available inside it.

middleware

Wrap any route, before or after.

A middleware is a named, ordered list of custom blocks attached to as many routes as you like. Most belong before the route — auth, rate limits, input clean-up. After-middlewares reshape the reply.

A middleware is an ordered list of custom blocks attached to any route, before or after it. Each block handles its own errors; a before middleware that answers skips the route.

next Testing Suites with checks, hooks that fake a block, and overrides.