drewkim

That's a great idea! We've identified a use case with solar companies for aiding in sales...this is a great additional case.

They're listed on the bottom of our home page

Thanks for the feedback! To answer your questions: - Myself and my co-founder - Credentials aren't stored in plaintext and the encryption key isn't universally available; "peeking" at the db is quite difficult - Data (I'm assuming you mean credentials) is encrypted at rest and in transit - Only business logic and errors are logged: e.g. when processes are completed and why things are breaking - Yes, eventually - Definitely ISO 27701 & SOC 2, perhaps others

Our process for safeguarding credentials is mentioned further down in the thread.

I'm not sure what more guarantees we can give to inspire confidence other than statements taken at face value. We don't have the scale or resources to undergo rigorous third party auditing at the moment. On the other hand, one of the first conversations my co-founder and I had was about hiring a security engineer as soon as we could afford one; we definitely take the matter seriously. Did you have any other ideas of ways we can showcase our commitment to security/privacy other than "trust us"? I do agree it's not the best method but am unsure of alternatives.

This is also what we've encountered so far...though it's probably safe to assume at least a few providers have looser security protocols.

Thanks for the great advice! We've created more detailed responses, so hopefully there's now a clearer picture of the output for each endpoint. We've added the more implementation-heavy recommendations (like changing the request body for interval data and splitting the address schema into multiple fields) to our roadmap to be implemented shortly. Really appreciate the scrutiny; way better to work everything out now than having developers run into usability issues. Please let us know if there's anything else you notice!

You nailed it!

First guarantee is that nobody is manually going in and poking around your account details since the process you've described happens entirely programmatically.

Now, we could program our system to do things other than what's mentioned. However, we're quite disinterested in (actually, emphatically against) ruining our trust/reputation with customers (plus the general public) given our dependence on such relationships and desire to succeed as a company. All that's to say, the second guarantee is that we won't be touching such sensitive data unless given permission to do so by the user.

An example of when we might need to is if the user wants to pay their utility bill using stored payment options instead of submitting payment information. Even in this case, there won't be human eyes on this data; only our Python backend will be interacting with it.

Here's the guide to using sandbox mode: https://pelm.readme.io/reference/sandbox-mode

We're excited for the challenge!

Arc was released after we'd already been working on this for a while so it did take us a bit by surprise. We'll compete by focusing on building an amazing team and a high quality product.

Arcadia requires their customers to sign NDAs and locks them into yearlong contracts, so we don't have an accurate picture. However, we've been told that our pricing is more competitive than theirs.

Personal use is totally okay and we'd love to here your feedback!

We do! You can call our endpoints with a "sandbox" header to get mock data. I realize this isn't outlined in our docs--we'll fix that ASAP and I'll comment here when it's done.

Thanks for the feedback; as an early stage startup with two employees, we'll often miss things here and there, so I appreciate the callout for how we can improve our docs. While we may not be established right now and have some work to do, I'm confident we can build an amazing developer experience given time. UtilityAPI might have very detailed docs, but we think the end to end usability is still lacking. This has been the consistent theme we've heard from developers that we've interviewed.

I'm not sure I agree with UtilityAPI being founded by "tech people", though we may have differing definitions on what that means. It seems like most of the high level execs come from the energy industry and don't have software engineering experience.

Could you give examples of the specific details we could add to the website to make it easier for you to onboard?

That makes sense; we'll need to think more about pricing consumer differently than enterprise because we've heard that our pricing is actually quite low for enterprise. Appreciate the perspective!

UtilityAPI and other products are built by energy companies, not tech companies. We've talked to developers who've used these platforms and they consistently mention an extremely poor developer experience; lack of clear documentation, difficulty in building integrations quickly, little to no support, etc. One example: we talked to a paying customer of UtilityAPI who asked for a specific feature, and UtilityAPI asked him to pay for the development costs of it.

We are software engineers by trade and know how to build a really good developer experience. We're focusing on ease-of-use from the start and will build a stellar engineering team that in turn will help us develop a higher quality product.

It's definitely on our roadmap...when we get to it largely depends on the needs of our early customers but know that we have it in mind!

We use a secret manager on our cloud platform for key storage, manually rotate keys (for now), and store encrypted passwords on a separate db.

Ah, I meant plaintext passwords are never persisted in a db anywhere. The only time passwords are decrypted are when they are used to programmatically log in, so they're never stored anywhere except in memory.

Ah, nice! Getting all of Exelon for the cost of one would be quite awesome. We'll dig into it.

Gotcha. Makes sense to keep things simple.

You're not the first person to suggest a blog for marketing purposes...seems like something we should invest in!

Would love to hear about your experience when you do so!

Ah, it's the burger menu with broken links! It shouldn't show up unless the browser window is a certain width, but we'll look into scrapping it completely.

Pelm is free up to 100 API calls and 10 active end users per month! I believe this should be enough to cover the home use case.

I did not; thanks for the heads up!

Correct, we'll have a ComEd integration soon

Thanks for the feedback—we'll have a list of utilities we support up shortly.

Which links in particular are broken/where did you see that tagline? I thought we combed through pretty thoroughly but maybe not.

Great callout. Passwords are encrypted using a 256-bit AES cipher and are never persisted or shown to developers in plaintext. We currently support PG&E and SCE with a ComEd integration landing within the week.

Thanks for the feedback! We had optimism that people would poke around the website more, but I guess we shouldn't assume that.