The REST Server node opens its own small HTTP server, letting another system call into a workflow directly: useful for a lightweight, ad hoc integration point that doesn't need the full Control API's resource model.
Warning
This node binds to every network interface on the machine, not just localhost. Set a Bearer Token and an appropriate rate limit before relying on it, especially on any network you don't fully control; Buttons doesn't warn you about this in the node itself.
Before you begin#
- A free port (1024–65535) for this server to use.
- A plan for at least one Bearer Token, unless this endpoint is genuinely meant to be open.
- Add a REST Server node to your workflow.
- Set Port.
- Set Rate Limit to an appropriate preset (10, 100, or 1000 requests per minute, or Off).
- Open Bearer Tokens and add at least one token. Leaving this empty makes every endpoint open to anyone who can reach the port.
- Select Add Endpoint, set its Path and Method (GET or POST), and repeat for each endpoint you need.
Paths must start with /, contain no whitespace or double slashes, and be unique within this node.
Wire an endpoint to your workflow#
- A GET endpoint gets one input handle on the node: connect a value to it, and that value becomes the response body whenever the endpoint is called.
- A POST endpoint gets two output handles: one carrying the request body as a value, and one firing an event on every call. The response to a POST is always a bare
200 with no body; there's no way to send a custom status or response body back from a POST endpoint.
Rotate a bearer token without downtime#
Bearer Tokens accepts more than one token, and any of them authenticates a request. Add the new token first, update whatever's calling this endpoint, then remove the old token once nothing depends on it anymore. Tokens here are plain text, not bound to a secret the way HTTP Request's authentication fields are: treat this node's configuration itself as sensitive.
Understand restarts and shutdown#
Changing anything about this node (the port, an endpoint, the rate limit, or the tokens) restarts the whole server, not just the part you changed. Expect a brief moment where the port is unreachable immediately after any edit and after selecting Apply.
Disabling the node stops the server outright. In-flight requests are handled however the underlying server library's own graceful shutdown behaves: Buttons doesn't add any extra draining or force-close logic on top of that.
If the node fails to start (most commonly because the port is already in use), that failure does show up through the normal workflow error indicator, unlike HTTP Request's own call failures; see
Troubleshoot a workflow.
If you get stuck#
What you see | What to try |
|---|
Any request gets rejected as unauthorized. | Confirm the caller is sending one of the tokens currently listed in Bearer Tokens: any request without a matching token is rejected once at least one token is configured. |
The node shows a red error border. | The server likely failed to start: check whether the configured port is already in use, possibly by a duplicate of this same node. |
A GET endpoint always returns the same value. | Confirm something is actually connected to that endpoint's input handle: it serves whatever value is currently on that handle. |
A POST endpoint doesn't return the response you expected. | It can't: POST endpoints always reply with a bare 200 and no body; use the request event to trigger logic, not to shape a custom response. |
The server briefly goes offline after a small config change. | That's expected: any change to port, endpoints, rate limit, or tokens restarts the whole server. |
You copied this node and now have two on the same port. | Change the port (and tokens, if they should differ) on the copy: pasting a node doesn't regenerate either. |
Where to go next#
