The Losant Workflow Engine API is the most interesting of the six APIs Losant has on the network. It is the programmable side of Losant’s visual workflow engine, the drag-and-drop logic that runs its IoT platform in the cloud, on edge gateways and on embedded devices. It is also where the contract we hold is furthest from the API Losant actually serves.
Losant scores 83.1, exemplar, up from 80.4. Operational transparency is 94.7, access clarity 92.1 and developer ergonomics 91.1. Agent Readiness is 62.3, agent-ready, with protected resource metadata verified on its MCP server at mcp.losant.com, delegated identity served, and dynamic client registration lit. It has one of the best-lit identity rows in the catalog.
What Losant publishes, and what we kept
Losant does not hide its API. https://api.losant.com/ serves its own machine-readable schema, a Bravado document at version 1.30.2 with 99 resources and 375 actions. Four of those resources make up the workflow engine: flow, flows, flowVersion and flowVersions. Between them they have 25 actions.
Our OpenAPI 3.2 contract for this API has 11 operations on 4 paths. Most of the missing 14 are sub-resource actions, and how they went missing matters. Upstream, a flow has separate actions at /storage, /virtualButton, /errors, /logs, /stats and /storage-metadata. In our contract those suffixes are gone. Their summaries survived, but they ended up on the bare resource paths, attached to the wrong methods:
| Our contract | Summary it carries | What upstream says that path does |
|---|---|---|
GET /flows/{flowId} |
errors during runs | retrieves the flow |
PATCH /flows/{flowId} |
sets a storage value | updates the flow |
DELETE /flows/{flowId} |
clears all storage | deletes the flow |
POST /flows/{flowId}/versions |
delete flow versions | creates or replaces a flow version |
GET /flows |
palette nodes | returns the flows |
An agent that trusted our DELETE summary would think it was clearing a cache, when that request deletes the workflow. That is the one failure a contract should never cause.
This is our defect, not Losant’s
Losant did the work: it published the schema, and it built an MCP server with OAuth. The conversion from its schema to OpenAPI is ours. The tool crosswalk in the repo already says so, recording that “the 138-operation shortfall is a gap in this repo’s derived OpenAPI, not in the provider’s API.” The workflow file shows that the gap is not just missing operations but mislabelled ones. One more small thing: every Losant API page, this one included, links its human documentation to the /rest-api/auth/ page rather than to the flow reference.
The MCP server shows why this matters. It is a thin, generic facade with three tools (losant_query, losant_write and losant_timeseries) that fan out across REST operations by resource type. To know what a given tool call will actually do on the REST side, an agent or a reviewer has to look up the operations it fans out to, and on apis.io the only operation map is our contract.
Takeaway
The fix is on our side: re-derive the workflow contract from the Bravado schema, keep the action suffixes as their own paths, and restore all 25 actions. For Losant, the one move left is to serve OpenAPI directly alongside Bravado, so that nobody has to translate it. See the API at apis.io/apis/losant/losant-workflow-engine-api/ and the reference at docs.losant.com.