The REST API
Every route, its request and its response, generated from the engine's own contract on every build of this site.
Getting started
The shape of every integration is the same: put the file somewhere, ask about it, submit a job, poll the ledger, collect what it wrote.
The loop
Ask for somewhere to put the file
A client uploads its file straight to object storage with a presigned PUT; the bytes are never posted through the API. You are handed a URL to PUT to and the identifier every later call names the file by.
Ask about it before spending anything
Inspect reads the header: bounds, point count, returns, classes and the coordinate reference system. Validate says whether the file is sane. A dry run says what a preset would do to it and what it would write, without doing any of it.
Submit
A named preset, a preset with overrides, an explicit list of stages, or a tier. One job, one identifier back.
Poll the ledger
While a job runs it publishes a ledger a client can poll: state, phase, percent complete, events with stable codes, the run's own log lines and the report.
Collect
The report, the findings and every artifact the run wrote, each with a URL to fetch it, or the whole folder in one archive.
Three front doors
The command line
The same operations as a binary you run over a file on disk — which is also how the service runs them.
MCP, for assistants
The REST API and the MCP server are two front doors onto one typed contract, so an HTTP client and an AI assistant reach the same operations with the same names, schemas and errors.
Or use the console
If you would rather not write anything: the console does the same loop in a browser, with a viewer for the result.
Which version this describes
The API reference on this page is generated from the engine's OpenAPI document at the version this platform is pinned to, at build time.
| Engine image | ghcr.io/alonstech/lazweaver:0.1.2 |
|---|---|
| Contract commit | 005c1e97488c43174c1890a14a7ca26fffd1f355 |