Connecting Green Button data to a CRM or a custom app

Utility consumption data is useful well beyond an energy dashboard. A retailer wants it in the CRM next to the customer record. An ESCO wants it in the project tool that tracks savings. A property manager wants it in the system that already holds leases and work orders. In each case the question is the same: how do you get a customer's energy data into an application that was not built to talk to utilities?

Green Button gives you a standard to build against. This guide covers the integration patterns that matter when the destination is a CRM or a custom app, and the trade-offs between a one-time import and an ongoing feed.

The two ways data arrives

Green Button, based on the NAESB Energy Services Provider Interface (ESPI) standard, defines two delivery methods. The distinction drives your whole integration design.

The Green Button developer overview describes both, along with the roles involved: the Data Custodian (the utility), the Retail Customer, and the Third Party that receives the data. If your app needs data once, DMD is enough. If it needs to reflect new reads without the customer repeating any steps, you want CMD.

How the Connect My Data feed authorizes

CMD uses OAuth 2.0, defined in RFC 6749, for the authorization step. The flow is a browser redirect: the customer, starting from either the utility or your app, is sent to the utility to approve sharing, and your application receives an access token and a refresh token in return. NIST has a clear write-up of the OAuth patterns Green Button uses.

A few properties of that flow shape your build:

• No passwords are shared. The customer authenticates with their utility, not with you, which is the main reason to prefer CMD over scraping a portal.
• Tokens expire. Your integration has to store the refresh token securely and renew access, or the feed goes quiet.
• Authorizations can be revoked. Your app needs to handle a feed that stops because the customer or utility ended the grant.
• Registration comes first. Many utilities require a third party to register and be approved before it can receive CMD feeds at all.

That last point is the one teams underestimate. The OAuth code is straightforward. Getting registered and approved with each utility, and keeping tokens healthy across all of them, is the ongoing operational cost.

The data model you will be mapping

Green Button data is expressed as ESPI resources delivered as Atom XML over RESTful APIs. The Green Button developer documentation and the OpenESPI developer guide describe the structures in detail. The pieces you will map into your CRM or app are, at a minimum:

• A usage point, which represents a metered service such as a specific electricity or gas account.
• Meter readings and reading types, which tell you the units, the commodity, and how to interpret the numbers.
• Interval blocks and interval readings, which carry the time-stamped consumption values.
• The customer and account information that lets you attach the readings to the right record in your system.

The work on your side is translating those ESPI resources into your own schema: a customer, an account, a meter, and a series of readings. Once that mapping exists, it holds across utilities, because certified platforms present the same structures. That is the payoff of a standard.

Integration patterns for a CRM or custom app

Depending on what the destination system is, one of these patterns usually fits:

1. Enrich a record on a schedule. For a CRM, attach a CMD feed to each customer and refresh usage on a nightly or monthly job, so the account record always shows current consumption without a person exporting anything.
2. Import once at onboarding. For a project or audit tool, use DMD to pull a block of history when a customer signs up, then decide whether ongoing updates are worth a CMD connection.
3. Store readings, compute in the app. Keep the raw interval readings in your own database and derive charts, baselines, and savings inside your application, rather than depending on the utility for anything but the data.
4. Normalize before you store. Map every utility's output to one internal schema at ingestion, so your app code never has to know which utility a reading came from.

For most CRM use cases the first pattern is the target: the customer authorizes once, and their energy data stays current in the record with no repeated manual step.

The build-versus-connect decision

You can implement all of this directly against each utility. The standard is public, the OpenESPI reference code exists, and for a single utility it is a reasonable project. The cost grows with coverage. Every additional utility means another registration, another approval, another set of tokens to keep alive, and another platform quirk to accommodate. Multiply that across the dozens of certified Ontario utilities and the maintenance, not the initial code, becomes the real workload.

This is where a connector earns its place. EZGB collects Green Button data across many utilities using both Download My Data and Connect My Data, and exposes it through a single API. Instead of your app holding a registration and a token set for every utility, you integrate once with EZGB and receive a consistent feed. For customers whose history only exists as bill PDFs, EZGB turns those bills into structured data in the same shape, so your CRM or app sees one format regardless of source. Your team writes one mapping into your own schema and maintains one integration, not many.

The authorization mechanics behind an ongoing feed are set out in Green Button OAuth: how CMD authorization works.

Whether you build straight against the utilities or connect through a service, the design questions are the same: one-time import or ongoing feed, how you handle OAuth tokens, and how you map ESPI resources into your own records. Start from those decisions, lean on the standard, and getting energy data into a CRM or a custom app becomes an integration project like any other.