Developers
Build on Powoflow
A comprehensive API with 611 REST endpoints, real-time WebSocket streams, real-time events, and OpenAPI specifications. Everything you need to integrate and extend.
API & Integration Capabilities
Everything you need to build custom integrations, dashboards, and workflows on top of Powoflow.
REST API
611 REST endpoints covering assets, telemetry, work orders, inventory, alarms, documents, users, and more. Consistent JSON responses with pagination and filtering.
WebSocket Real-time
Subscribe to live data streams for sensor updates, alarm state changes, position reports, and system events. Sub-second delivery for real-time dashboards.
Real-time Event Bus
25+ event types for event-driven workflows. Build automations triggered by asset changes, alarms, work orders, and more.
OpenAPI Specifications
Two OpenAPI documents, one for the tenant API, one for administration, covering 592 of the 611 served routes. Import into Postman, generate a client, or drive contract tests. Where specification and served surface disagree, the served surface is the truth and closing the gap is our job.
Generate your own client
No hand-written client library to fall behind the API. The OpenAPI documents drive code generation, so you get a typed client in your own language and toolchain, and it regenerates when the API moves instead of drifting quietly.
Authentication & Security
OAuth 2.0 with JWT bearer tokens, verified at the Field Agent before a request reaches any handler. Tenant and roles come from the token, so a caller cannot reach another tenant’s data by editing an identifier in the path. All traffic over TLS.
Webhooks
Register webhook endpoints to receive push notifications for Powoflow events. HMAC signature verification ensures payload integrity.
Throttling you can plan around
Throttling is applied at the Field Agent across the whole surface rather than sold as a per-caller quota. We will tell you the limits for your deployment rather than letting you discover them in production.
Stable in the way that matters
Additive change is the default and the served route table is the contract. We are pre-launch and small enough that a breaking change comes with an email from the person who made it, rather than a deprecation notice you were supposed to have read.
An MCP server, not a chatbot bolted on
Both APIs speak the Model Context Protocol, so Claude, ChatGPT or your own agent can work Powoflow directly, with the guardrails on the server side, where they belong.
Fifty-one tools across two servers
Twenty-six on the tenant API, assets, hierarchy, telemetry, work orders, alarms, inventory, documents, meters, fuel, team, and twenty-five on the administration side for the device fleet, edge deployments, firmware rollouts and the audit log. Both live in production today.
Every write asks first
Call a write tool and nothing happens. You get back what it would do. The exact request, a plain-English consequence, and a live read of the record as it stands right now. It executes only on a second call carrying an explicit confirmation. Enforced per tool and pinned by a test, so a newly added tool cannot quietly skip it.
Secrets never reach the model
Responses are scrubbed of credential-shaped fields at every depth before they leave the server. This exists because a routine fleet listing was found returning dashboard passwords and device claim codes, data the caller was entitled to, heading somewhere it should not. A model’s context gets transcribed, forwarded and pasted into tickets. It is a different trust boundary from an API client.
It lands in the same audit trail
Every tool call, read or write, is recorded with the caller, the arguments, the duration, the outcome and a correlation id joining it to the underlying API request. Not a separate MCP log. The same audit record as the in-product assistant, so agent activity appears in the governance dashboard with nothing extra to wire.
Documentation that cannot drift
Each server publishes its own tool reference at /mcp/docs, rendered from the live registry rather than maintained beside it, schemas, access badges and copy-paste client wiring included. If a tool changed, the page changed.
It cannot exceed your own access
Your token is forwarded verbatim to the same REST API, so every tenant boundary and role check governing a normal request governs an agent request identically. Administration tools additionally require a platform-admin login, and a refusal explains what is missing instead of returning an opaque error.
How you connect, plainly
Sign in from the command line and point your client at the endpoint. That covers Claude Code, curl, and the Anthropic and OpenAI APIs. One-click sign-in from a hosted assistant needs a registration handshake we have not built yet, so that route is not open, worth knowing before you plan around it. Tool results carry text your own people wrote, and each server tells every connecting model to treat that as data rather than instructions: useful, and honestly a reminder to the model rather than a filter.
Build something against it
Tell us what you are integrating and we will get you a token and the specs. If you are pointing an agent at it, say so. We would like to know what it does.