A router is a stable inbound address — webhook, email, REST, and MCP — that points at one thunk at a time. You can repoint it to a different thunk without changing the address your partners already use.
Use a router when other systems or people will keep sending work for a long time, and you may later swap the thunk behind that address — for example, a rebuilt thunk, a copy you tested first, or a rollback to the previous thunk. Release and rollback are the same action: moving the pointer.
Every thunk still has its own email address, webhook, REST API, and MCP export. A router is an extra address in front of a thunk, not a replacement. Traffic sent to the thunk's own addresses is not moved when you repoint the router.
If you are still wiring the first caller and do not expect to swap thunks, the thunk's own inbound channels are enough. See Inbound Requests.
Where to find routers
A router belongs either to you or to your organization:
Your routers — open the menu under your account icon, choose My account, then Routers in the left menu. Only you can see and change these.
Organization routers — from My account, open Org Admin: your organization, then Routers. Only the organization's owner and admins see this. Anyone who can administer the organization can change these routers.
You must own or administer a thunk to point a router at it. A router cannot point at a public thunk.
Create a router
On the Routers page, click Add Router.
Enter a Name.
Optionally search Initial target thunk (optional) by name or goal, and pick the thunk this address should send work to.
Click Create.
Copy the API key now. It is shown once and cannot be retrieved later. You need it for the REST and MCP addresses. You can add more keys later.
If you skip the initial target, use Repoint… to choose a thunk before anyone sends traffic.
Several routers can point at the same thunk.
Share the addresses
Open a router in the list. The detail page shows Current target and the inbound addresses. Copy each address you will use and give it to the partner or system that should send work.
API access — MCP endpoint and REST endpoint. MCP and REST share one set of API keys. Treat each key like a password.
Webhook — one or more webhook URLs. Anyone who has a URL can post data, so share it only with senders you trust.
Email — the router's Address. This address is assigned when you create the router and does not change.
The target thunk still does the work. Set up that thunk to accept the kind of traffic you will send:
Email — allowed senders and routing instructions live on the target thunk's Email tab. See Send requests to your thunk by email.
Webhook — the post is handled as inbound work on the target thunk. See Receive requests through a webhook or a shared form.
REST — start work against the copied REST endpoint the same way you would call a thunk's workflow REST API (
/startto create work,/statusto check it, API key in thex-api-keyheader). The target still needs its workflow REST surface enabled. See Inbound requests via a REST API.MCP — connect an AI agent to the copied MCP endpoint with the same API key. The target still needs its tools published. See Publish your thunk as an MCP server for AI agents.
How work is routed
New work — a fresh email, webhook post, REST start, or MCP call — goes to the current target.
Work that already exists stays where it is. A reply in an email thread, or a status check for a work item that already exists, continues on the thunk that already has that work, even after you repoint. Only new work follows the new target.
Repoint to a different thunk
Repointing moves new inbound traffic. It does not copy or migrate work items. Work that is already running keeps going on the previous thunk until it finishes.
A common pattern is to copy the live thunk, test the copy, then repoint the router at the copy. Repoint back to roll the cutover back.
Open the router and click Repoint….
Search New target thunk by name or goal and pick it.
Click Check. The dialog reports whether the new target can accept and process the traffic the router already receives. This is advisory and never blocks the repoint — changing how work is handled is often why you are switching thunks.
Click Repoint.
If the new target is paused, has no workflow to receive work, or would reject senders or inputs the previous target accepted, Check warns you. You can still repoint.
Watch previous thunks drain
After a repoint, Draining former targets lists thunks this router used to point at and how many work items are still open on each one. drained (0 open) means that thunk has no open work items left. None — this router has only ever pointed at its current target means you have not repointed yet.
Repoint log is the history of pointer moves, including the first target.
Rotate keys and webhook URLs
API keys and webhook URLs are lists of equal credentials — there is no special primary key.
To rotate without downtime: Add API key or Add webhook URL, move senders to the new value, then Revoke the old one. A new API key is shown once; a new webhook URL is shown once.
Revoking the last API key closes REST and MCP until you add a new key. Revoking the last webhook URL closes the webhook until you add a new URL. The confirm dialog warns you when you are about to do that.
Delete a router
Delete stops the router's addresses and keys. Partners using those addresses will fail until you give them a new address. Deleting a router does not delete the target thunk or its work items.