Explains the local HTTP API server, how it maps to submit verbs and workers, and how to smoke test it.
The HTTP API is the networked counterpart to the existing CLI submit and inspection commands. It is intentionally narrow. The API server accepts requests, resolves JS submit verbs, writes durable workflow state into the engine DB, and exposes read-only inspection endpoints. It does not replace the worker process.
The main mental model is:
HTTP API -> submit initial durable work
worker run -> execute queued ops
That split is the same one used by scraper site <site> run <verb> and scraper worker run. The HTTP layer is a thin host around the same services and submit-verb runtime.
Start the server with scraper api serve. In practice, most local runs also need bootstrap site manifests loaded first, so the full command usually looks like:
scraper \
--sites-manifest-dir ./sites \
api serve \
--address 127.0.0.1:8080 \
--engine-db state/engine.db \
--sites-dir state/sites
Important flags:
--sites-manifest-dir: directory or directories containing site manifests used to build the site/verb catalog before the command tree is executed--address: loopback bind address for the local server--engine-db: durable engine SQLite database--sites-dir: directory holding per-site DBs--read-timeout: HTTP read timeout--write-timeout: HTTP write timeoutThe API does not execute full workflows inline. A submit request runs exactly one JS submit verb under sites/<site>/verbs/*.js. That JS function can seed the workflow by emitting initial ops. Those ops are then picked up later by the worker process.
This is the same split described in scraper help scraper-runtime-model:
http/fetchThe first server slice exposes:
GET /healthzGET /api/v1/infoGET /api/v1/sitesGET /api/v1/sites/{site}GET /api/v1/sites/{site}/verbsGET /api/v1/sites/{site}/verbs/{verb}POST /api/v1/sites/{site}/verbs/{verb}:submitGET /api/v1/engine/statusGET /api/v1/engine/migrationsGET /api/v1/workflows/{workflowID}GET /api/v1/workflows/{workflowID}/opsCatalog endpoints expose the same JS/Glazed metadata the CLI uses for site <site> run <verb>. That makes the API suitable for future form generation or a small dashboard without inventing a second schema language.
Start the server:
scraper \
--sites-manifest-dir ./sites \
api serve \
--address 127.0.0.1:8080 \
--engine-db /tmp/scraper-http-api/engine.db \
--sites-dir /tmp/scraper-http-api/sites
Submit a js-demo workflow:
curl -X POST http://127.0.0.1:8080/api/v1/sites/js-demo/verbs/seed:submit \
-H 'Content-Type: application/json' \
-d '{
"workflowID": "demo-http-001",
"values": {
"count": 3,
"multiplier": 4,
"prefix": "http"
}
}'
In another terminal, process the queued work:
scraper \
--sites-manifest-dir ./sites \
worker run \
--engine-db /tmp/scraper-http-api/engine.db \
--sites-dir /tmp/scraper-http-api/sites \
--max-cycles 16 \
--poll-interval 5ms
Then inspect the workflow:
curl http://127.0.0.1:8080/api/v1/workflows/demo-http-001
curl http://127.0.0.1:8080/api/v1/workflows/demo-http-001/ops
curl http://127.0.0.1:8080/api/v1/engine/status
Start here if you need to change the implementation:
pkg/cmd/api.gopkg/api/server/server.gopkg/api/handlers/pkg/services/catalog/service.gopkg/services/submission/service.gopkg/services/engineview/service.gopkg/sites/submitverbs/host.goscraper worker run separately.400 on unknown or incompatible fields.scraper help scraper-runtime-modelscraper help scraper-architecture-overviewscraper help scraper-new-developer-onboardingscraper help scraper-bootstrap-config-and-site-manifest-loading