Skip to main content
shtap serve runs the ShoulderTap engine: the routing and asking loop, the scheduler for escalations and timeouts, the HTTP API, and the web approval UI. It is the one process that owns state (a local SQLite file), and every other command talks to it over HTTP.

​
Start it

​
--config
string
default:"shouldertap.yaml"
Path to the configuration file.
​
--transport
console | slack
default:"console"
How experts are reached. console prints DMs to the terminal and reads replies from stdin. slack sends real Slack DMs and captures replies from the Events API.
​
--host
string
default:"0.0.0.0"
Host interface to bind the HTTP server to.
The server listens on the port from server.port in your config (default 8776).

​
Transports

The console transport prints the exact DM ShoulderTap would send an expert to the terminal running shtap serve, and reads the expert’s reply from stdin. It needs no Slack app or credentials, which makes it ideal for a first look and for local development. This is the transport the Quickstart uses.

​
What the server exposes

Once running, the server serves:
  • The HTTP API at http://localhost:8776/api/v1 — used by consumers, the CLI, the SDK, and the MCP server. See the Protocol reference.
  • The approval UI at http://localhost:8776/ — a single page listing pending proposals to accept or reject. See Approvals.
If the bearer-token environment variable is unset, the API accepts every request. Set SHOULDERTAP_API_TOKEN (or whatever server.api_token_env names) before binding to a public interface.

​
Durability

The scheduler persists escalation and give-up timers to SQLite. If the process restarts, overdue timers fire on the next start — a request that should have escalated while the server was down escalates as soon as it comes back up.