The Envo Public API is the single entry point for integrating with the Envo platform. It
exposes a curated, read-oriented slice of the platform — sites and their building metadata,
parameters and measurement data, energy consumption and production, and deviations — behind
one address and one login.
Behind it sit several Envo services, but that is an implementation detail: everything is
served under api/v1, documented here, and reachable with the same credentials.
Every request needs an OAuth2 client credentials token, sent asAuthorization: Bearer . Envo issues you a client id and secret; exchange them at the
token endpoint for an access token and reuse it until it expires.
Most endpoints are site-scoped — the route contains {siteId} and your client must hold
the relevant permission for that site. A 403 means the token is valid but the client
lacks the permission on that site, which is different from a 401 (missing, expired or
invalid token).
Errors come back as RFC 9457 problem documents (application/problem+json), with title,status and — where there is something specific to say — detail.
Parameter logs became measurements. The biggest change. The old per-parameter log routes
are gone:
The parameter moves out of the path into a required parameterIds query parameter, which
takes a comma-separated list — so one request can now cover several parameters instead of one
per call. startTime and endTime are required. The response payloads change name to match
(MeasurementResponse, AggregatedMeasurementResponse).
Nine write endpoints were withdrawn. POST, PUT and DELETE on/api/v1/building-types, /api/v1/building-categories and/api/v1/sites/{siteId}/site-information are no longer part of the public API. The building
taxonomy is managed internally; these are read-only now.
GET /api/v1/sites returns more. Each item is now a full site — timezone, address,
coordinates, a new state field — rather than just id and name. Existing code reading id
and name keeps working.
GET /api/v1/sites/{id} is now site-scoped. Previously any authenticated client could
read any site. It now requires access to that specific site, so an integration that reads
sites it is not granted will start getting 403. Worth checking before you upgrade.
A lot was added — 42 new endpoints, taking the API from 23 to 56. Chiefly energy data
(consumption by category or tenant, energy flow, solar production, grid export, indoor and
outdoor temperature, meter structure and distributions), building tenants, and deviations:
reading active deviations, fetching the acknowledge form for a category, and acknowledging
them.
Set the collection variables first. baseUrl is the API address for your environment;clientId and clientSecret are the credentials Envo issued you; tokenUrl is the token
endpoint for the same environment. Everything else inherits from these.
Set authorization once, on the collection, so individual requests do not each carry their
own. On the collection's Authorization tab choose OAuth 2.0 with the client credentials
grant, point it at tokenUrl, then Get New Access Token. Requests inherit it and run
without further setup until the token expires; repeat the same step to refresh.
Start with GET /api/v1/sites****. It confirms the credentials work and returns the sites
your client can reach. Take a siteId from the response and use it in the site-scoped
requests, most of which take siteId as a path variable.
Requests are grouped by area — Sites, Parameters, Measurements, Consumption, Deviations and
so on — mirroring the sections in this documentation.
A couple of practical notes. List endpoints are paginated with pageNumber andpageSize. If you need to report a problem, include the X-Correlation-Id from the response
headers: it is how Envo traces a single request through the platform.
Contact Support:
Name: Envo Platform Team