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:
@X10 you might be best starting a separate thread for tracking that down, but I’m not sure you will get the level of granularity you need from this data.
The API only gives information to the same level as the website. It’s a limitation of the smart meters.
If you have an in home display (IHD), you may be able to use it to track it down. Theses usually show near-real time energy usage (usually only a delay of a few seconds at most). If you notice high power usage, you can turn suspect devices off to see if it drops.
If you want more granular information you could look into other mechanisms of energy monitoring such as smart plugs or CT clamps. Smart plugs are useful in not requiring any electric work doing, but you would have to put them on various suspect appliances or move it between appliances. CT clamps are handy for being able to monitor a full circuit, or working for devices which are hard-wired, but that usually involves putting them inside the consumer unit which means finding a professional to do it.
Today I have just checked what the two Half Hourly APIs for Sunday 2025-10-26 (BST to GMT switch over day) are returning and electricity results are as follows
usage/api/half-hourly-local (GMT endpoint ???)
usage/api/half-hourly (local time endpoint ???)
gas results seem to be all present
Just released a new version to
https://github.com/MikeWilliams-UK/My-Ovo-Data/releases/latest
This version has an enhanced main screen and the ability to obtain YOUR meter readings
+7Thanks again, Mike. Retrieving readings will be a welcome bonus for many.
I can’t get this version to work. I log in successfully and select the electricity account. A few moments later, the app crashes. There’s nothing interesting in the OVOData log, but this is from Event Viewer:
Application: OvoData.exe |
Is this enough for you to find and squash the fault? There’s more where that came from!
It looks like the code to Add the new tables did not work.
Can you try renaming your database (which should exist in C:\ProgramData\OvoData) to something other than [accountnumber.db]
Then try again as this should re-build it from scratch
/Mike
Just tried that myself and I have located the issue.
One of my scripts (to update the database) had Unix Line endings instead of Windows line endings
Not sure how that happened ???
Fixing it now ...
/Mike
New version released https://github.com/MikeWilliams-UK/My-Ovo-Data/releases/tag/V1.0.6
/Mike
+7Brilliant swift reaction again 👍
Off to test - watch this space 👀
[EDIT some time later]
The Hh usage data all turned up after chugging away for 25 minutes. That’s lightning-fast on my dodgy 4G LTE Internet connection, retrieving 150,000 lines of data.
Meter readings also turned up, but incomplete. Looking at the tables in the DB, your code doesn’t seem to be handling multi-register readings well. The MeterRegisters table is incomplete, and if that’s used in some way to drive the MeterReadings selection, it’s not surprising that many fall by the wayside.
If you need sample files from my multi-register electricity-only account to see what needs to be selected, shout and I’ll get them to you.
Yes it would help greatly if you could zip up and PM me the meter readings json.
It IS very possible that your JSON is organised slightly different to mine.
I am on a flat daily rate, whereas you are on E7 (according to you signature) and yours data probably has differently organised JSON.
It's a shame that OVO doesn't have a publicly visible definition of the API.
/Mike
+7
I will try to download it tomorrow when I am on computer. I have downloaded it to my phone, but phone won't open it ...
Just emailed the file to my work address and I can see the data, so you can delete the file
/Mike
+7Just emailed the file to my work address and I can see the data, so you can delete the file ...
Gone. Good hunting 🙂
Import of your meter readings data shows:-
New version at https://github.com/MikeWilliams-UK/My-Ovo-Data/releases/tag/V1.0.7
+7
There are some odd gaps in the record, which I’m sure aren’t the result of the retrieval process. There are three meters involved - non-smart, SMETS1 and SMETS2 - and their designation of registers to peak and offpeak tiers was a bit of a moveable feast over the years. This came to a head when they tried to enrol and adopt my SMETS1 meter on to the DCC; it turned out that DCC would not accept the first tier as offpeak, so we had to swap them over.
I suspect that readings for most of 2018-2022 have been lost from my OVO account. I’m not sure if I have them salted away somewhere. I do certainly have month-end readings for the whole period, so losing the daily ones is no great problem.
Anyway, it’s great to be able to retrieve readings in a useable format along with the usage data. I hope those who download the code show their appreciation!
You are welcome, the extra readings are due to me injecting your JSON file (instead of fetching my readings), which was created yesterday.
I was surprised that so many readings were available as we have previously been told that the system only stores the last 400 readings???
/Mike
+7… we have previously been told that the system only stores the last 400 readings???
Bit of confusion here.
The meter has a datastore which saves (a) 400 days’ Hh usage data and (b) 31 days’ billing data, i.e. midnight snapshots of register readings etc. Suppliers will normally send a request for the previous day’s records once a day, so 48 Hh bucket contents and readings for each register.
It’s then up to suppliers what they do with these data, but OVO seem to salt everything away in the customer’s account. This what your app accesses. Utilities like n3rgy and Bright connect via DCC to the meters themselves to retrieve the contents of their datastores.
I see that the JSON file I shared with you has lots of register details, which OVOData pushes to the DB’s Meter Registers table. There has clearly been some mucking about with these data, because there were periods when the lowest register tier was the offpeak one, a state which DCC chokes on. So I think the R01/02 labels were changed around with no alteration to the underlying data. Theis means that OVO’s (or Kaluza’s) own systems can’t successfully retrieve the data for the upside-down periods. I’ll have another look.
I am leaving OVO in a few days time.
This has led to a new bug raising its head in obtaining the meter readings
// Previous
"accountSupplyPoints": [
{
"startDate": "2014-12-01",
"end": null,
"supplyPoint": {
// Now that I have a exit date
"accountSupplyPoints": [
{
"startDate": "2014-12-01",
"end": {
"date": "2025-11-25"
},
"supplyPoint": { Notice the unexpected formatting of end.date which give an error
Exception thrown: 'System.Text.Json.JsonException' in System.Text.Json.dll System.Text.Json.JsonException: The JSON value could not be converted to System.String. Path: $.data.account.accountSupplyPoints[0].end | LineNumber: 0 | BytePositionInLine: 91.
I have fixed the error.
I will be releasing it later today - providing my testing finds no further issues.
Sadly, I didn't have time to release my "final" version today. That's assuming that I will lose access when my account is closed.
I am hoping to get time to do it tomorrow.
/Mike
Version 1.0.8 released
https://github.com/MikeWilliams-UK/My-Ovo-Data/releases/tag/V1.0.8
PS: After today I will have limited ability to fix issues...
/Mike
+7
Version 1.0.8 released
Thanks as always, Mike. I’ve taken it for a test drive and all seems to be well.
I’m sorry to see you go, but I assume you found a better deal elsewhere. You’re always welcome in these forums whoever has your energy allegiance from time to time.
Au revoir, and bonne chance!
On a side note, does anyone know if there is any way to tell if the data being retrieved is estimate or actual readings?
I ask only as I just found out that our meter has not been sending data to OVO for over 2 months, but there have also been days where it dropped before that too (we have a SMETS1). Mike’s tool has half-hourly reads for our entire account, so I just wondered if there is some easy way to tell which are estimates and which are actual.
Or, based on some of the recent discussion just above about 400 days worth of data being stored, are these actual readings that didn’t get sent to OVO?
I’m a little confused and would appreciate any clarity, if anyone knows.
Thank you!
/Mike
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
