Privacy

Version 2026-08-31-r13 · read against the terms on 2026-09-01

1. What is stored, and why

Data	Why it exists
Your email address	To send the verification link, to recover a lost key, and to identify the account.
A hash of your API key, plus its first 14 characters	To authenticate requests and to attribute usage. The key itself is never stored — it is shown once and cannot be recovered, only replaced.
Per-request records: which endpoint, when, how many milliseconds, how many credits	Quota accounting, and knowing which endpoints are worth improving. Linked to the key hash, not to your email.
Your plan and monthly quota	To enforce the limit you were issued.
What the response said about a calculation: how many warnings it carried, their labels, the confidence value, whether the rate was current, whether the figure was an upper bound, and whether an unresolved report had been received that the rate did not match the utility's filed sheet. Linked to the key hash, not to your email	So that what RateGrid told you about a figure can still be produced years later, when a homeowner shown that figure asks. None of your inputs is recorded here — no load profile, no address, no coordinates, and not the calculated figure itself. The warning labels describe the tariff, which is a public filing, not you or your customer. The table has no column that could hold anything else.
Terms acceptance: the version and hash of the document, the time, and the IP address it came from	To record what you agreed to and when. Without the IP the record is materially weaker as evidence.
Signup and password-reset tokens	Single-use, and they expire in 30 minutes.
Optionally, what you told us you are building	Only if you filled in that field. It is used to decide which utilities to add next.
Coverage requests: the utility you searched for and did not find, with the source IP	To prioritize coverage, and to stop one person retyping from looking like ten prospects. Giving an email here is optional.
If you register a webhook: the URL you gave us, when it was created, a number saying which of our signing keys yours was derived from, and the reason the most recent delivery failed	To send you source.changed when a tariff document we watch on your behalf moves. Your signing secret is not on this list, because we do not keep it. It is derived from a key held outside the database whenever a delivery is signed, shown to you once at registration, and never stored or returned — so there is no copy of it in our database or in any backup of it, and we cannot tell you what it is if you lose it. Make a new endpoint instead. The key number is stored so that if we ever change our signing key, your existing secret goes on working until you choose to register again; it says nothing about your secret and does not help anyone reconstruct it. If we retire the key yours came from, we stop sending to that endpoint rather than sign with a key you cannot check, and the delivery record below says so. A URL can itself disclose something about your systems, so give us one you are content for us to hold.
A record of each delivery attempt: which endpoint, when, the status code, and the error or the reason it was not sent	So that “we sent it” is checkable rather than asserted, and so you can see why nothing is arriving without asking. Kept for 90 days, then deleted.
Short-lived rate-limit counters keyed by IP and endpoint	To stop one address exhausting the service. Deleted after 24 hours.
Your email address in the server log, on a handful of paths	Signup and reset attempts that are refused — an address already registered, a banned address, a rate limit reached — and email delivery failures, are logged with the address so the refusal can be diagnosed. Nothing you send to a calculation endpoint is logged; see section 2.

2. What is not stored

This is the part worth being precise about, because the calculation endpoints receive the most sensitive thing you send.

• Consumption data is not retained. Load profiles, PV production profiles, monthly kWh figures and hourly interval data sent to /calculate, /compare, /solar, /battery and /sizing are used to produce the response and then discarded. The usage record notes that you called an endpoint, not what you sent to it.
• Your API key is not stored. Only a hash and a short prefix.
• Request and response bodies are not logged. Password reset links in particular are deliberately kept out of the server log, because a recovery token in a log file is an account takeover for anyone who can read logs.
• No cookies are set, by us or by anyone else. There is no analytics package, no tag manager, no advertising pixel, and no third-party JavaScript anywhere on this site.
• No payment card details ever reach this service — see section 4.

3. What leaves the server

/resolve turns an address or a latitude and longitude into the utility that serves it, and that takes lookups this service cannot do on its own:

• The U.S. Census Bureau's public geocoder (geocoding.geo.census.gov) receives the address you supply, and returns coordinates and a county. If you call with coordinates instead, they are sent to the same geocoder to identify the county — unless you supply the county yourself, in which case nothing is sent.
• The U.S. Geological Survey's elevation service (epqs.nationalmap.gov) receives those coordinates, but only when the county is one whose baseline territories are split by elevation. More than half are not, and for those no request is made.
• The National Laboratory of the Rockies, formerly the National Renewable Energy Laboratory (developer.nlr.gov), receives those coordinates on every call, to identify which utility serves the point. Only the utility name is used; the rates returned alongside it date from 2012 and are discarded.

Each of these requests leaves this service and is handled under that agency's own terms. Neither the address nor the coordinates are stored here. The elevation result is held in memory, keyed on the coordinates rounded to five decimal places and nothing else — no address forms part of that key, and it does not survive a restart.

Those three are the only places anything you send to /resolve is sent on to. They are not the only parties that see anything at all: the host necessarily carries every request; your email address reaches an email provider when a message is sent to you; and mail you send to support@rategrid.dev reaches the provider that runs that mailbox, along with whatever you chose to put in it. Sending and receiving are two different providers, and section 4 names both. If you would rather not share a location, skip /resolve and pass a tariff label to the calculation endpoints directly — they never need to know where you are, and none of them makes an outbound call.

4. Subprocessors

This is the complete list of third parties that receive anything, what each one gets, why, and where it is processed. Nothing is left off it. No subprocessor is added without notice — see below the table.

Subprocessor	Role	What it receives	Region
Fly.io	Application hosting and the database volume	Everything necessarily passes through the host. Web server access logs record the requesting IP address, the path and the response status — the ordinary record any web server keeps.	United States (Chicago)
U.S. Census Bureau geocoder	Address to coordinates and county	Only the address you pass to /resolve, or the coordinates when you pass those without a county. See section 3.	United States
National Laboratory of the Rockies (formerly NREL)	Coordinates to serving utility	Only the coordinates, on every /resolve call. See section 3.	United States
U.S. Geological Survey elevation service	Elevation for split baseline territories	Only the coordinates, and only for counties split by elevation. See section 3.	United States
Resend (resend.com)	Sending verification, reset and account messages	Your address, and the content of the message sent to you. Resend keeps delivery logs and message metadata for its own operations.	United States. Resend stores account data, logs and message metadata in the United States regardless of the region a message is routed through.
Fastmail (fastmail.com)	The mailbox behind support@rategrid.dev	Mail you choose to send to that address, and the replies to it: your address and whatever you put in the message. The access and deletion requests in section 6, the reports in section 8 and account deletion requests all arrive this way, so a request of that kind sits in this mailbox until it has been dealt with. Nothing you send to the API reaches it — no consumption data, no address or coordinates, no API key, and no part of the database.	United States. The account is set to Fastmail's US data region, where the primary copy and its replica are both held. Fastmail Pty Ltd is an Australian company subject to Australian law, and states that it answers lawful requests from authorities the same way whichever region stores the data. It is the only subprocessor in this table not incorporated in the United States, which is why that is said here rather than left to be discovered.
Stripe	Payment processing	Only if paid plans are ever enabled and you buy one. Stripe handles the card; card numbers never reach RateGrid. At the time of writing no paid plan is on sale and no payment details are collected from anyone.	United States

Before a new subprocessor is added, notice goes to the email address on every verified account, and this table is updated with the new entry, at least 30 days before it starts receiving anything. If a replacement has to be made faster than that — because a provider fails, or is terminated for cause — notice goes out as soon as the change is made and says why it could not wait. Every subprocessor is engaged under written terms no less protective than section 11.9 of the terms, which is the commitment the data processing addendum makes at 3.1(h).

Separately from the lookup described in section 3, RateGrid downloads the National Laboratory of the Rockies' public utility rate database to compare against its own encoded rates. That is an outbound fetch of a public dataset into local storage, and nothing you send forms part of it.

Personal data is not sold, rented, traded, or handed to advertisers or data brokers. It would be disclosed if a law or a valid legal order required it.

5. How long it is kept

• Signup and reset tokens: 30 minutes, single use.
• Rate-limit counters: deleted after 24 hours.
• Account and usage records: kept while the account exists, because they are what enforces your quota.
• Terms acceptances: kept while the account exists and for two years after it closes, then deleted. Two years is the one-year limit in section 22.5 of the terms plus a further year, so the record outlives the last claim that could be made on it and then stops existing.
• The tariff archive — every version of every utility rate document ever fetched — contains no personal data at all. It is public regulatory filings.

6. What you can do

• Kill a key immediately: POST /keys/revoke with the key. No email round-trip, no waiting.
• Replace a lost key: /keys/reset issues a new one and revokes the old.
• Ask what is held about you, or ask for it to be deleted: email support@rategrid.dev. Requests are currently handled manually rather than by a self-service button, so allow a few days. Deleting an account removes the key records, the usage history, and the address from those records. One thing survives: the record that you accepted the terms, and that record contains your email address. It has to. The address is the only thing tying an acceptance to a person, so a record stripped of it would prove that somebody agreed and never which body — which is the one question the record exists to answer. It is kept for the period in section 5 and then deleted with the address in it. Deletion applies to the live database; the volume is backed up daily and backups are kept for 30 days, so a deleted record persists in them until it ages out.

7. How it is protected, and what happens if that fails

These are stated plainly, as specific things that are true, rather than as a security posture:

• Traffic is served over TLS. Nothing is accepted over plain HTTP.
• Your API key is stored as a hash and a 14-character prefix, never in full, so a copy of the database does not yield a working key.
• Request and response bodies are never logged. This is enforced by a test that walks every module and fails the build if a request-path module configures a logger without a stated reason.
• Access to production data is restricted on a least-privilege basis to those who require it to operate the service. It is not available to anyone who does not.

If there is a breach. If RateGrid determines that a security incident has resulted in someone acquiring personal information it holds about you, or contained in what you sent, it will email the address on your account without undue delay and in any event within 72 hours of that determination — saying what is known, what is affected, and what is being done, and following up as more becomes clear. Notice will not be held back to finish the investigation first. This sits on top of the notification duties that state law imposes anyway; it does not replace or narrow them. Section 25.5 of the terms is the same commitment in contractual form.

8. Age

RateGrid is a tool for building software. Nothing about it is designed to attract or appeal to children, and no age is collected or inferred — the only personal detail required to open an account is an email address.

The Terms of Service require account holders to be at least 18. Accounts are not knowingly issued to anyone under 18, and personal information is not knowingly collected from anyone under 18. If you believe an account has been issued to someone under 18, email support@rategrid.dev and it will be removed along with the data held for it.

9. Changes

If this notice changes, the version above changes with it. Material changes affecting people with accounts will be sent by email.

10. Contact

Questions, access requests, deletion requests, and anything else about this notice: support@rategrid.dev.

← back