Skip to content

Product API

LyftData exposes supported product operations through an HTTP API for the web UI, CLI, workers, operators, and external integrations. Use this API to inspect or manage the LyftData control plane—not to move pipeline event data.

Goal Surface
Inspect jobs, workers, deployments, credentials, health, or observability Product API under /api/...
Consume an independently versioned integration contract Integration API under /integration/v1/...
Receive webhooks or poll/send provider data inside a pipeline Runtime http-server, http-poll, or http-post components

Product API requests reach the control plane. Runtime HTTP components run as part of a job and process event data. Exposing an http-server input does not expose a control-plane API, and a product API route is not a pipeline endpoint.

/api/... is the same-release-train application namespace. The embedded UI, CLI, workers, and server normally upgrade together, so these routes are not root-versioned and can reshape with a product release.

/integration/v1/... is for consumers that can upgrade independently. Within v1, changes are additive; a breaking contract requires a new root version. Do not add a family-level v1 segment beneath /api.

When OpenAPI is included in the server build, download:

Terminal window
curl --fail --silent --show-error \
"https://lyftdata.example.com/api-doc.json" \
--output lyftdata-openapi.json

Use the document served by the installation you will automate. A cached or newer source-tree document can describe operations that are not present in an older installed release.

OpenAPI coverage is broader than generated-client coverage. A route can be a supported UI or operator API while intentionally remaining outside generated clients because it uses browser redirects, streaming, sensitive write-only values, or an evolving schema.