HTTP serve
Expose a stitch over HTTP for callers that aren't in-process.
Reach for stitch serve when a caller can't import your stitches in-process —
a remote service, another language, a shell script — and you want to expose the
registry of named stitches over a thin local HTTP front door instead.
Example
Start the server, then call a registered stitch by name with a JSON body:
# Serves the registry on http://127.0.0.1:8787 by default.
stitch serve
# List the available stitch names.
curl http://127.0.0.1:8787/
# Run the `me` stitch; the request body is its input.
curl -X POST http://127.0.0.1:8787/stitch/me \
-H 'content-type: application/json' \
-d '{}'The server runs the named stitch through the same engine as an in-process call and returns the final validated result as JSON.
Options
Two routes serve the registry of named stitches:
GET /lists the available stitch names.POST /stitch/:nameruns that stitch; the JSON request body is its input. Any other method returns405, and an unknown name returns404.
The server binds to 127.0.0.1:8787 by default. Responses are the final
validated result as JSON; send Accept: text/event-stream (or add ?stream=1)
to receive the live event stream as SSE instead.
Serving a stitch over HTTP changes nothing about the capability boundary — auth, validation, and resilience still run server-side, exactly as they do in-process. The HTTP route exposes the same stitch definition, not a looser one.
A served stitch is the same definition as the in-process
function surface and the
stitch CLI — one source of truth, three ways to call it.