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.
I don't doubt your intentions but these guarantees don't hold their weight relative to the sensitivity of the data that you will safeguard. Despite the process happening programmatically, developers will still have access to the backend where this occurs. Who has access to this backend? What's stopping any of your engineers from peeking at the database where the credentials are stored? Is this data encrypted at rest and transit? What sort of information is this process logging to either first-party and third-party services? Will the code be audited? What sort of compliance certifications are you planning to obtain?
Maybe you do have answers to these questions so if you do I suggest that you communicate how credentials are properly safeguarded. The guarantees that you mention in this comment don't inspire confidence as a) they can't be taken at face value b) makes me doubt you are taking the due diligence required to manage this data.
Take a look at these examples of companies supporting their claimed guarantees:
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 should be written down somewhere! I glanced through the website and I couldn't find any mention of the security/safety measures taken other than the UI screenshot where it says "securely connect your utility account".
If I were interested in purchasing this service I would want to know how much I can trust you with my credentials. Perhaps having a page or section in the docs that explain the security measures would be an improvement. There are other ideas in another comment similar to this one.
You could let the utility companies, which users already "trust" evaluate and then recommend/sign-offs on your engine? Or just have the utility embed your engine and bill them?
While I respect your current intentions, I cannot take you at your word in perpetuity because I understand the pressures that come from:
1. Running such a business as an entrepreneur.
2. Running such a system as an engineer.
As an entrepreneur, are you promising your customers clean data regardless of the source? Are you promising AI magic? Are you promising a maximum failure rate?
From an engineering standpoint, how will you deal with portals changing their frontends and breaking your scrapers at any time?
I cannot know what you will do in response to these pressures, but I do know that the temptation will exist to build a system that puts a human in the loop to manually collect data from portals, to manually evaluate scrapers, to manually sift through the data and figure out what kind of Machine Learning models you can use to make your business function more effectively.
Have you considered sending users to the website to update payment information? Or if not, do you perform the PCI auditing process for your handling of payment information through your systems?
I don’t personally need the answers to these pair of questions, but I wanted to put them on your radar if they’re not already. I trust Plaid far enough to scrape account providers for me, but I do not trust Plaid far enough to provide Plaid my payment details — even if Plaid could theoretically construct them, that’s just not the relationship I want with a data conduit provider.
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.
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.
I think UtilityAPI was founded by "tech people" as well. I wonder if you have any specific examples or comparisons that would make me want to use your service over a well-established company?
I work in the energy industry, and while I would love to just try out your service for comparison, I don't have the time. Your site is very lacking in details.
Also, you said you know how to build a "really good developer experience" without "lack of clear documentation", but the most basic endpoint you have for collecting energy usage intervals (https://pelm.readme.io/reference/get_accounts-account-id-int...) does not have a good example for the data you return for a 200 response; I can't tell what the actual data will look like! You state it's tuples with `(timestamp, value)` but do not show an actual example with tuples in your docs. Compare that to UtilityAPI's docs for the same type of endpoint (https://utilityapi.com/docs/api/intervals) which have a very detailed example.
I would say you have some work to do, but good luck! I would love to see multiple good alternatives for collecting energy utility data.
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?
The founders may have energy industry experience - which is what you want, since it's the operating domain and they'll have industry information and contacts that 'outsiders' won't - but they seem to have a pretty strong development team: https://utilityapi.com/team.
The founder is pretty active on hn[1]. And coincidentally, his most recent comment is about why it makes sense to work at an energy company as part of market research.
I would have the docs much more specific on the results that you'll get back. I think from the looks of it, you're using some automated doc builder which takes your internal specs for the endpoint (like the OpenAPI spec or whatever) and outputs "examples" and the other doc pages.
Here is what you have now for an example response body, which is very lacking:
I think your docs could use a TON of manual refactoring after you output them from the automated tool OR you need to put a lot more details in the spec so that your automated tool will have better results.
For instance:
* What is "unit"? I assumed it's electrical units, but if that is the case, it doesn't make much sense to me, because that's not an account-level detail but rather a request detail (I should be able to add a param to the request to get Watts, Kilowatts, or whatever units I want each time).
* The "address" is also sketchy, because it is just a string field, so how do I parse that? will each "line" of the address be separated by a newline, or something else?
* The spec for "intervals" is a list of lists of strings, which is a weird way to output `(timestamp, value)` tuples; I would want to see that specified a bit better as well. I would expect either tuples of numbers (float, int, whatever) or something like a mapping with the meter numbers, timestamps, units, values, etc. specified like this (timestamps could be UTC seconds or (preferably) ISO strings):
Some of this is implementation details, but format and documentation matters a LOT for this stuff, if you're providing a data API as a service.
That's all just from one endpoint. If you have 2 employees, I would look into hiring a technical doc writer as your 3rd if you're trying to build an "amazing developer experience" and also talking to more commercial customers who might use your product to run large data pipelines for energy controls and such. To me, the documentation is like a canary in a coal mine, and I wouldn't even attempt to use your product as-is because it would take me time to fool around with it to even see what formats the data is in and there is no differentiator from your product and others that makes me want to do that work.
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!
The pricing feels really steep. For a consumer app where the API is called twice a day, it is almost 7 dollars per month alone. This is just for one user. At this price point it means this is inaccessible for anything other than enterprise apps.
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!
Do you have a developer sandbox with some example data? It's not feasible for the developer to create accounts with different providers if some are across the country.
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.
