Applications, HTTP and ownership

The CLI, Studio and HTTP API operate the same workflow definitions. Your own application can submit work and display results while Laufwerk records execution.

Customer UI → your authenticated backend → Laufwerk serve → workflow
                   owns user access           owns run execution

Keep the owner token on your backend. It grants broad management authority and is not a per-customer browser credential. Your application controls which user can start, inspect or answer which work.

Start the server

Set LAUFWERK_OWNER_TOKEN in the server environment using a generated secret, then run from your consumer project root:

bunx laufwerk@0.0.1-alpha.13 serve --studio

The default listener is loopback port 3000. --studio includes Studio in the same serving process. Use an authenticated TLS proxy for remote browser access and configure the public origin as described in the CLI reference.

Start a known workflow

In a separate terminal with the same owner token configured:

curl --fail-with-body http://127.0.0.1:3000/api/runs \
  -H "Authorization: Bearer $LAUFWERK_OWNER_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"workflowName":"hello","input":{"name":"World"}}'

The initialized hello workflow accepts this payload. The response identifies the run while execution proceeds asynchronously. An accepted HTTP request is not proof of completed work. Follow the run and inspect its lifecycle and result.

Repeated Hello inputs use its name-based execution identity; real applications should choose a business key appropriate to their task.

Add a task-specific endpoint

Default-export defineHttpRoutes(...) from laufwerk/http.ts to translate an application event into workflow input. A handler validates the request and calls context.startWorkflow with a submission key. The submission key and the workflow's idempotencyKey serve different boundaries: route submissions and workflow execution. See the complete route example.

Validate signatures for webhooks. Authentication at the model provider does not authenticate GitHub, your CRM or a storage service. Every integration needs its own scoped credentials and an external receipt for actions whose outcome matters.

What you own

You operate the host, storage, backups and access controls. Your repository owns workflow code, schemas, tools and instructions. Model inference still sends relevant data to the provider. Moving to a different engine requires adapting Laufwerk APIs and recovery behavior; ownership does not make those contracts interchangeable.

Go deeper: HTTP API and routes · External receipts

← Compare workflow changes · Next: A complete research-and-draft workflow →