We're trying to lower the barriers to entry to building helpful energy services by building a standardized and centralized API to allow developers to easily authenticate with user utility accounts and use their data.
Yes, we connect with each utility company API and expose our own. Each utility API is a little bit different, so we simplify this sort of the way segment simplified analytics integrations or Plaid simplified bank account integrations.
Their APIs are read-only, no bill paying through them. We can see different types of data, though, from usage to billing intervals.
We have to register as a company with a tax ID. We plan to open it up as a flat subscription model based on the amount of requests required. There will be a free "developer" plan that allows unlimited use with request limits.
If you're just using the PGE api, then not much. If you're building an app that doesn't discriminate between utilities and your users are from all over, then this is a solution. We're trying to simply make it so the API from every utility looks exactly the same, so developers can write code once, and it works regardless of what utility the user is a part of.
Whats the stack? Im mostly cuellos about the db of choice. I built something similar for another market and the database choice was PostgreSQL for its json capabilities and full text search.
Only PGE right now? Are you implementing Green Button Connect? How are you getting past the requirement for users to fill out CISR forms to allow 3rd party to manage data?
10 comments
[ 3.3 ms ] story [ 26.3 ms ] threadAre their APIs used for bill payments? is yours?
Their APIs are read-only, no bill paying through them. We can see different types of data, though, from usage to billing intervals.
Are you planning to monetize it as subscription?