A utility data API lets your ESG, billing or analytics platform collect meter data on its own, on a schedule and in a fixed format. For a real estate team, it is the difference between someone exporting a spreadsheet every month and the numbers already being where they are needed.
This guide explains what a utility data API is, what data comes through it, how it differs from a CSV export or a building management system (BMS) connection, and the five questions to ask before you connect one to an ESG or billing platform. It is written for the person who has to make the integration work, and for the real estate team that has to trust the result.
What is a utility data API?
A utility data API is a standard way for one system to request energy, gas, water and heat data from another system automatically. API stands for application programming interface: a documented set of requests one system accepts from another. Instead of downloading a file and uploading it somewhere else, your ESG, billing or analytics platform asks for the data it needs and gets it back in a consistent format.
In real estate, the system answering those requests is usually the monitoring platform that collects readings from the meters. The systems asking are the ones that report, bill or analyze: an ESG reporting platform, a property management and billing system, or a business intelligence tool.
What data comes through a utility data API?
A utility data API delivers four kinds of information: the readings themselves, the facts about each meter, the units, and the status of every reading. The readings are only usable when the other three come with them.
| What does the API deliver? | What does it look like? | Why does it matter? |
|---|---|---|
| Interval reads | Consumption per meter at a fixed interval, such as every 15 minutes or every hour, each with a timestamp. | The interval decides what you can analyze, from monthly totals down to the load at 3 a.m. |
| Meter metadata | The meter ID, utility type, location, building or tenant assignment, and whether it is a main meter or a submeter. | Without metadata, a number cannot be assigned to the right building, tenant or reporting line. |
| Units | kWh, m³, GJ and so on, stated explicitly with every value. | A receiving system should never have to guess whether a gas value is in cubic meters or kilowatt hours. |
| Gaps and estimates | Missing, estimated or corrected reads, flagged as such rather than silently filled. | Auditors and tenants will ask which numbers were measured and which were not. |
If you want to know what the interval means in practice, our guide to 15-minute interval data explains what each resolution can and cannot show.
How is a utility data API different from a CSV export or a BMS connection?
A utility data API delivers current, structured consumption data across many buildings without anyone in the loop. A CSV export is a manual snapshot, and a BMS connection is built to control one building's systems, not to report on a portfolio.
| How does the data get there? | CSV export | BMS connection | Utility data API |
|---|---|---|---|
| Who starts the transfer? | Someone downloads a file and uploads it, which depends on that person remembering. | An integrator links one site's BMS to one other system. | The receiving system requests the data on a schedule, with no one in the loop. |
| How current is the data? | It is as old as the last export, often a month or more. | It is current, but usually only for the systems the BMS controls. | It is as current as the collection interval, for example every 15 minutes. |
| What does it cover? | Whatever the person exporting selected that day. | Usually one site and one vendor's equipment. | Every connected meter across buildings and utility types. |
| Does the format stay the same? | Columns, units and date formats often change between files. | It depends on the BMS vendor and how the integration was built. | The structure is fixed and documented, so the receiving system knows what to expect. |
A CSV export is not wrong. For a single building that reports once a year, it can be enough. It stops working when the same data has to reach several systems every month across dozens of buildings, because every manual step is a chance for a missed file or a wrong unit.
How does a utility data API work in practice?
Most utility data APIs follow the same pattern: the receiving system authenticates, asks for the list of meters, then asks for the consumption of each meter over a period. The answers come back as structured data, usually JSON over HTTPS, following REST conventions.
Authentication is typically OAuth 2.0 client credentials, a standard for one machine to prove its identity to another, or a simpler API key. Some APIs also push data instead of waiting to be asked: a webhook sends a message to the receiving system when something happens, such as a new reading or a threshold being crossed. Good APIs publish their endpoints in an OpenAPI specification, so a developer can see every request and response before writing any code.
What should you ask before integrating a utility data API?
Ask five questions before you connect a utility data API to an ESG or billing platform. Each one covers a failure that usually only shows up after the integration is live.
1. Which meters and utilities are covered?
Check whether the API covers electricity, gas, water and heat, including submeters and meters without smart readers. An API that only carries main electricity meters leaves the tenant billing and the water figures in a spreadsheet.
2. What is the read interval, and how fast does new data arrive?
The read interval sets the finest detail you can analyze, and the delay sets how current your reports are. Ask for both, because a 15-minute interval that arrives a day late behaves very differently from one that arrives within the hour.
3. How are gaps, estimates and corrections handled?
Ask how a missing read is flagged, whether estimates are marked as estimates, and how a corrected value is backfilled. If corrections overwrite old values without a trace, your report and your auditor will be looking at different numbers.
4. Are units, time zones and metadata consistent across all buildings?
Ask whether every building returns the same units, the same time zone convention and the same metadata fields. Inconsistency here is the most common reason an integration works for the pilot building and breaks on the tenth.
5. What are the rules for authentication, rate limits and versioning?
Ask how credentials are issued and revoked, how many requests the API accepts per minute, and how changes to the API are announced. Then ask who supports the integration when something breaks, and how fast.
When is a utility data API not the answer?
A utility data API is not the answer when there is no system to receive the data, or no meter to collect it from. An API moves data, it does not create it. If half your buildings still rely on manual reads, an API delivers the gaps faster, it does not close them.
It is also more than a small portfolio needs when one person reports once a year from a handful of buildings. In that case an export, or the dashboards in the monitoring platform itself, can be enough. The API earns its place once several systems need the same data, often, across many buildings.
Where does Rhino fit in?
Rhino is the data layer between your meters and your stack. It collects electricity, gas, water and heat data, including submeters, through existing smart meters, utility provider connections, third-party infrastructure already in the building, or Rhino's own hardware where nothing else fits. Rhino is not an ESG platform or a billing system: it feeds them.
The Rhino Utility Data API delivers that data at 15-minute intervals as JSON over HTTPS, documented with OpenAPI. Each reading carries a timestamp, meter ID, consumption value and unit, and endpoints cover meter listings, consumption time series, building hierarchies and alert states. Authentication is OAuth 2.0 client credentials or an API key, webhooks are available for real-time triggers, and historical data is available from the point of connection. API access is included in the platform subscription.
The API cannot read a meter that is not connected, so the first step is usually a check of which meters can be read remotely. See how one dataset across all buildings supports portfolio operations, or book a demo to walk through the data with your technical lead.
Frequently asked questions
What is a utility data API in real estate?
A utility data API is a documented way for one system to request energy, gas, water and heat data from another automatically. In real estate, the monitoring platform that collects meter readings answers the requests, and ESG, billing or analytics platforms ask. The data arrives on a schedule in a fixed format, instead of through manual file exports.
Is a utility data API better than a CSV export?
A utility data API is better when several systems need the same data often across many buildings. It delivers current data on a schedule in a fixed structure, without anyone in the loop. A CSV export can be enough for one building that reports once a year, but every manual step risks a missed file or a wrong unit.
What data does a utility data API return?
A utility data API returns interval reads, meter metadata, units and the status of each reading. Interval reads give consumption per meter at a fixed interval such as 15 minutes. Metadata identifies the meter, utility, building and tenant. Units are stated with every value, and missing or estimated reads should be flagged rather than silently filled.
What should I check before connecting a utility data API to an ESG platform?
Check five things before connecting a utility data API to an ESG platform: which meters and utilities it covers, the read interval and delay, how gaps and corrections are flagged, whether units and metadata are consistent across buildings, and the rules for authentication, rate limits and versioning. Also confirm who supports the integration when something breaks.
