Hi Ovo,
I wondered whether the API that powers your live and historical usage page in the account menu is something you could look into opening up a bit so we can freely access our raw data and also perhaps it may stimulate some interesting community projects?
Best answer by g-de
Updated on 14/08/25 by Abby_OVO
Tim_OVO: “We love seeing the innovative ways our customers are using tech to help monitor and manage their energy usage. It’s inspiring us to think about ways to do energy differently. We know some customers have been using some of the application programming interface (APIs) behind our public facing services. While we’re OK with that, we do need to make you aware of a couple of things.
These APIs are designed to be used by OVO teams only, and aren't public facing. There are some downsides to using APIs that aren't for the public, and we wanted to let you know what these are. Behind the scenes, OVO uses APIs to share and update information between systems that power your bills and your online account. This is done in partnership with Kaluza, the tech company that’s part of the OVO family. They’ve built the billing platform designed to put our customers in the driving seat of their energy usage.
These internal APIs are intended for use by Kaluza and its clients, who are energy retailers like OVO, rather than customers. Because of this, there’s no support for them being used anywhere else, which means they may be discontinued with no notice when we update our products and services.
OVO Energy and Kaluza need to be able to monitor these APIs, and may block access if there's any problems in the future.
We know some customers may have put time and effort into developing solutions that use these API. So, now that you know the risks, we want to hear from you on how you’re using the APIs and the problems you’re solving with your DIY approach.
Is there anything you’d like to see from OVO to help you monitor and manage your energy better? Leave a comment below to tell us.”
can you help me understand if the links above allow users to access raw data as if from an API?
I can certainly give it a go.
Firstly, big thanks to Timmo and other contributors for developing the library. All thanks go to them and links to buy them a coffee for their effort can be found on PyPi or GitHub:
https://pypi.org/project/ovoenergy/
https://github.com/timmo001/ovoenergy
I assume the way the library was developed this was to reverse engineer the My OVO website. That is, browse the website as normal and and monitor the traffic to see what OVO URLs and APIs it uses. Assuming this is the case, one of these URLs (get account IDs) already seems to be different but the library is still working for the moment. The APIs being used are not officially supported outside of the website, so first, a warning that any changes to the My OVO website may break the library.
For anyone using Python, you should be able to include the ovoenergy library and look at https://github.com/timmo001/ovoenergy/blob/master/ovoenergy/cli.py for how to use it.
For replicating this in other languages, the process seems to be as follows:
{
"username": "...",
"password": "...",
"rememberMe": true
}From the response, save the cookies to use in all future requests.
You can also get monthly or half-hourly usage using the following URLs similar to step 3:
As mentioned above, if this is wanted for Home Assistant, the integration was added in version 0.114 (https://www.home-assistant.io/integrations/ovo_energy/).
Unfortunately the data only goes up to the end of the previous day as OVO no longer provide real-time data:
I have recreated the deployment zip file and uploaded it to GitHub
/Mike
+7I have just checked and the checkbox to include the .net runtime was not checked.
That’s great. That might save a few scratched heads.
I now realize I’d forgotten what the utility was supposed to do, so please excuse my stupidity. I rather thought that once the database was up to date I could select a period - a single month, say, and get a CSV with just that month’s data.
I see that you’ve converted the timestamps to local time. I’m not sure that’s the best idea, even though many users would prefer it. OVO have at last got it more or less right with their own display of half-hourly data after I grumbled for years about how wrong it was. My own preference is for year-round consistency, working always in UTC. That way, I don’t see inconsistencies like only 46 entries for 30 March 2025. I’ll be watching come 26 October ...
Thanks for the feedback
+7The first few lines of yesterday’s for me:
|
|
[From https://smartpaymapi.ovoenergy.com/usage/api/half-hourly-local/nnnnnnn?date=2025-10-09]
The times are UTC, so the first node is midnight GMT.
Thanks, looking at that json data I can see that the OVO API is not sending us the timestamps properly formatted as UTC because they should then be "2025-10-09T01:29:59.999Z", note the Z is missing from their data.
I will have a think about how to best cope with that.
/Mike
{
"electricity": {
"data": [
{
"consumption": 0.3,
"interval": {
"start": "2025-10-09T00:00:00.000",
"end": "2025-10-09T00:29:59.999"
},
"unit": "kwh"
},
{
"consumption": 0.308,
"interval": {
"start": "2025-10-09T00:30:00.000",
"end": "2025-10-09T00:59:59.999"
},
"unit": "kwh"
}
]
},
"gas": {
"data": [
{
"consumption": 0,
"interval": {
"start": "2025-10-09T00:00:00.000",
"end": "2025-10-09T00:29:59.999"
},
"unit": "kwh"
},
{
"consumption": 0,
"interval": {
"start": "2025-10-09T00:30:00.000",
"end": "2025-10-09T00:59:59.999"
},
"unit": "kwh"
}
]
}
}Not sure where to go from here...
+7Interesting. Early last year, I made a post about British Summertime’s effect on OVO’s data. It included this:
| OVO’s system retrieves the current time zone from the device operating system. If this isn’t set properly (e.g. to UTC + 00:00 with daylight savings time applied automatically), then the usage pages won’t necessarily show the correct local timings. |
My Windows is set like this:
Is yours the same?
My equivalent page (i.e. the ‘placeholder’ before the day’s data have been retrieved) starts at 23:00, so there’s probably something in your machine set differently. It might be within the coding environment even though Windows is set up rationally (!)
PS Which incantation did you utter to get your JSON so nicely formatted and posted?
It might well be that the program needs to add some information to the http client when calling the API
On my phone just now I had to switch to desktop mode to see the three dots
Just found that the three dots menu also shows up if I rotate my phone...
I am pretty sure that it's the same as yours.
I get the same on both my work laptop (Windows 10) and my my home laptop (Windows 11)
Regarding the JSON that you posted a snippet of, was that from your browser or from the dump folder of my program?
/Mike
This is what my daily usage looks like on the website on my phone, as you can see it correctly starts at 00:00 BST
Is the difference an electric only quirk???
If I remember correctly you are electric only customer.
The OVO website calls
https://smartpaymapi.ovoenergy.com/usage/api/half-hourly-local/nnnnnnn?date=2025-10-09
Which gives the date stamps in UTC
Whereas my app calls
https://smartpaymapi.ovoenergy.com/usage/api/half-hourly/nnnnnnn?date=2025-10-09
Which gives the date stamps in local
Quite clearly the -local version is wrongly named I would have called it -utc
For those enquisitive people you can switch my app from local timestamps to UTC by changing AppSettings.json from this
{
"LoginUri": "https://my.ovoenergy.com/api/v2/auth/login",
"TokenUri": "https://my.ovoenergy.com/api/v2/auth/token",
"AccountsUri": "https://api.eu1.prod.kaluza.com/graphql/1",
"MonthlyUri": "https://smartpaymapi.ovoenergy.com/usage/api/monthly/{0}?date={1}",
"DailyUri": "https://smartpaymapi.ovoenergy.com/usage/api/daily/{0}?date={1}",
"HalfHourlyUri": "https://smartpaymapi.ovoenergy.com/usage/api/half-hourly/{0}?date={1}",
"DumpData": "true"
}to this
{
"LoginUri": "https://my.ovoenergy.com/api/v2/auth/login",
"TokenUri": "https://my.ovoenergy.com/api/v2/auth/token",
"AccountsUri": "https://api.eu1.prod.kaluza.com/graphql/1",
"MonthlyUri": "https://smartpaymapi.ovoenergy.com/usage/api/monthly/{0}?date={1}",
"DailyUri": "https://smartpaymapi.ovoenergy.com/usage/api/daily/{0}?date={1}",
"HalfHourlyUri": "https://smartpaymapi.ovoenergy.com/usage/api/half-hourly-local/{0}?date={1}",
"DumpData": "true"
}It might be prudent to delete/rename the file {accountNo}.db from the folder C:\ProgramData\OvoData before trying this out.
/MIke
Just done an experiment using the endpoint “api/half-hourly” vs “api/half-hourly-local” and I have found that my program is over writing some of the values.
api/half-hourly (which gives local time)
| First Period Start | Last Period Start | Count |
|---|---|---|
| 2025-03-29 00:00:00 | 2025-03-29 23:30:00 | 48 |
| 2025-03-30 00:00:00 | 2025-03-30 22:30:00 | 46 |
| 2025-03-31 00:00:00 | 2025-03-31 23:30:00 | 48 |
As you can see for the last change over date two readings have been over written.
api/half-hourly-local (which gives UTC)
| First Period Start | Last Period Start | Count |
|---|---|---|
| 2025-03-29 00:00:00 | 2025-03-29 23:30:00 | 48 |
| 2025-03-30 00:00:00 | 2025-03-30 22:30:00 | 48 |
| 2025-03-31 00:00:00 | 2025-03-31 23:30:00 | 48 |
So I would recomend altering the appsettings.json as follows
"HalfHourlyUri": "https://smartpaymapi.ovoenergy.com/usage/api/half-hourly-local/{0}?date={1}",
+7
We have several sources of usage data, and they all have their own way of presenting the figures. This can make it easy for the unwary to get waylaid if data from different sources are mixed up. I did a comparison some time ago to illustrate how the same dataset called up by date can produce really different results:
Of these, the only really accurate one is n3rgy - the meter time-stamps each half-hour bucket as it becomes full and moves on to the next, so the one that starts filling up at midnight is labelled 00:30. The various utilities then apparently change the time stamps to what they think the end-user wants.
We’ll find out soon what happens at the end of summertime. I think they’ve got it about as good as can be expected. During GMT, there’s no need for the weird first-hour entry on a placeholder page before the day’s data have been retrieved.
Just thought I’d double check - is there any way to get the data for this property’s smart meter from the last 400 days as has been mentioned by some previously? (Or any X number of days, as opposed to just for this account)
Thank you!
I am currently working on the code to get the last 400 reading for this account.
Not sure how you would get readings for an account that is not yours.
Please explain further
+7… is there any way to get the data for this property’s smart meter from the last 400 days as has been mentioned by some previously… as opposed to just for this account?
The OVOData utility retrieves the data stored by OVO in the user account. It doesn’t know or care which meter originally recorded the data. The last 400 days’-worth will of course be included in the All Time dataset so long as the account is old enough.
You may have read that a SMETS2 smart meter records both a daily snapshot of the register readings at midnight and every half-hour’s usage, storing the former for 30 days and the latter for 400 days. Old records are deleted to make space for new ones.
Some third-party utilities can access the meter’s usage data store with the customer’s permission. The ones I use - Bright and n3rgy - limit data retrieval to three months’-worth, but they might be persuaded to download the whole lot if you ask them nicely.
+7I’ve just re-read
Sneak preview of the internal state of my progress to obtaining the last 400 meter readings.
As you can see the kalzula endpoint is returning 450 meter readings
If I search for "source": "SMART_METER" in the raw json from the endpoint I can see that there are 800 smart meter reads the other 50 electricity records have either "source": "INDUSTRY" or "source": "MANUAL_READ_CUSTOMER"
As I have been a resident at my address for much longer that 400 days I am unable to coment on the ability to get other peoples meeter readings.
This might be a GDPR issue which OVO / kaluza need to sort out.
/Mike
Thanks for clarifying that this is not possible.
(As an aside, the reason I asked was that we’ve moved to a property with a heat pump, no gas, which is entirely new for us. We’ve noticed that our daily usage, according to the data, has increased significantly in the last 3 months, but as far as we can tell, our power usage habits haven’t changed enough to justify this increase. So I thought it might be useful to see historical data to compare, roughly, if other people in this property had similar increases at times.
I mention the heat pump as I thought initially this was the culprit of the additional energy usage, perhaps we weren’t using it properly or it was faulty, but looking at the half-hourly data, I don’t think this is the cause of the spikes in energy usage).
Sorry for the long post and thanks for your answers!
Just done an experiment using the endpoint “api/half-hourly” vs “api/half-hourly-local” and I have found that my program is over writing some of the values.
api/half-hourly (which gives local time)
| First Period Start | Last Period Start | Count |
|---|---|---|
| 2025-03-29 00:00:00 | 2025-03-29 23:30:00 | 48 |
| 2025-03-30 00:00:00 | 2025-03-30 22:30:00 | 46 |
| 2025-03-31 00:00:00 | 2025-03-31 23:30:00 | 48 |
As you can see for the last change over date two readings have been over written.
api/half-hourly-local (which gives UTC)
| First Period Start | Last Period Start | Count |
|---|---|---|
| 2025-03-29 00:00:00 | 2025-03-29 23:30:00 | 48 |
| 2025-03-30 00:00:00 | 2025-03-30 22:30:00 | 48 |
| 2025-03-31 00:00:00 | 2025-03-31 23:30:00 | 48 |
So I would recomend altering the appsettings.json as follows
"HalfHourlyUri": "https://smartpaymapi.ovoenergy.com/usage/api/half-hourly-local/{0}?date={1}",
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
OVO Energy Ltd, registered office 1 Rivergate Temple Quay Bristol, BS1 6ED, company no. 06890795 registered in England and Wales.
OVO (S) Gas Limited is registered in England and Wales (Company No. 02716495) at 1 Rivergate, Temple Quay, Bristol, BS1 6ED.
OVO (S) Gas Limited is part of OVO Group Ltd
