Green Button Connect My Data (CMD) for Energy Managers and Resellers

Energy managers and resellers who work across dozens or hundreds of accounts run into the same wall. Pulling a single customer's utility history is tedious. Pulling it every month, for every meter, without asking the customer to log in and export files again, is close to impossible with manual methods. Green Button Connect My Data (CMD) was built to remove that wall. It gives an authorized third party ongoing, automated access to a customer's utility usage and billing data, with the customer's explicit consent and the ability to revoke it at any time.

CMD is one of two access methods under the Green Button standard. Both are built on the North American Energy Standards Board (NAESB) Energy Services Provider Interface (ESPI) standard, which defines a common XML schema for interval usage and billing data. The difference is how the data moves. Download My Data (DMD) is a file a customer exports and hands to you. CMD is an API connection that keeps delivering data on a schedule after a one-time authorization. For anyone managing data at scale, that distinction changes the entire operating model.

In Ontario this is not a niche capability. Under O. Reg. 633/21, rate-regulated electricity and natural gas utilities were required to implement Green Button CMD and DMD and certify with the Green Button Alliance by November 1, 2023, a mandate that covers roughly 60 utilities provincewide according to the Green Button Alliance. The pipes for authorized, automated data access already exist across most of the province.

Download My Data versus Connect My Data

Both methods return the same ESPI XML payload, so the underlying data model is identical. What CMD adds is the authorization and delivery layer. The table below is the practical view most teams care about.

DMD is the right tool when you need a one-time look at a building or a customer wants to hand you a snapshot. CMD is the right tool when the same accounts need to feed a monthly report, a benchmarking model, or an ESG submission without anyone re-exporting files.

How CMD authorization works

CMD uses the OAuth 2.0 authorization code flow, the same pattern used when you let one web service read data from another. The customer never hands you their utility password, and the utility never hands you data the customer did not approve. The sequence is short.

1. The customer selects your service and is redirected to their utility's authorization page.
2. They log in at the utility and approve the specific data scope and time range you requested.
3. The utility issues your registered application an access token plus a refresh token, which is used to renew access as the token expires, a pattern documented in the NIST MyData API guidance.
4. Your system pulls ESPI XML on a schedule, and the customer can revoke access from the utility at any point, as described in the Green Button OAuth documentation.

What CMD enables at scale

The value of CMD shows up when you stop thinking about one account and start thinking about a book of business. A one-time authorization can cover historical interval data plus everything the meter records going forward.

• Portfolio onboarding without file chasing. New customers authorize once and their data starts flowing.
• Recurring reporting. Monthly benchmarking, tenant reports, and ESG rollups draw from a live feed instead of a manual export cycle.
• Historical plus ongoing in one connection. Backfill for baselines and keep current data arriving on the same channel.
• Multi-commodity coverage where the mandate applies. In Ontario both electricity and natural gas utilities are in scope under O. Reg. 633/21.

Where CMD still needs a data layer

CMD solves access and delivery, not interpretation. ESPI XML is standardized in structure, but utilities populate it differently. Reading types, units, quality flags, time zones, and the split between billing blocks and interval blocks vary from one custodian to the next. A standard container does not guarantee standard content, a gap covered in green-button-and-the-standard-data-problem.

There is also coverage. Not every account is reachable through CMD. Some legacy meters, some out-of-province or non-mandated utilities, and some commodities such as water or district energy still arrive as PDF bills or portal exports. A reseller serving customers across provinces will always have a mix of automated feeds and manual documents. The operating model has to handle both without splitting into two workflows.

How MartinAI helps

MartinAI reads utility data across every commodity and layout. That includes Green Button ESPI XML from CMD and DMD, plus PDF bills, spreadsheets, and portal exports for the accounts CMD does not cover. Each record is validated for missing periods, estimated reads, unit mismatches, and meter mapping, then standardized to consistent units and billing periods. Whether a customer's data arrives as an automated CMD feed or a stack of scanned bills, the output is one clean, normalized dataset you can push into analysis, benchmarking, and ESG tools.

For resellers and energy managers, that means CMD becomes the fast lane for the accounts it covers, and everything else still lands in the same place, in the same shape. You get the scale benefit of automated access without leaving the non-mandated accounts stranded in a separate manual process.

Green Button CMD is the closest thing the Canadian market has to a standard front door for customer-authorized utility data. Used well, it removes the file chasing that eats analyst time and makes recurring reporting realistic across a whole portfolio. The work that remains is turning that access into consistent, trustworthy records, and that is a data problem you can solve once rather than account by account.