Yahoo Historical Data - Did they change the URL recently?

I wonder is this is related to recent letters by exchanges to data vendors about charging thousands per API use. This was discussed somewhere. I was told by someone that after a few smart traders discovered how to defeat HFT they lobbied to exchanges and asked them to stop providing data via API or charge very large fees. Now pay attention

I have tested yahoo data and it's mostly flawless. Only occasional problems that were fixed after a few days.

Google and other free data sites have missing days. Try AAPL for example and will find some 0 values in historical data for the open.

I would be willing to pay Yahoo $5/mo for API data. Someone with free time please make a petition website. We have to fight back. ET is a forum that gives us the opportunity to unite when needed to do that.

Or alternatively, go here and complain loud:

https://forums.yahoo.net/t5/Yahoo-Finance-help/Is-Yahoo-Finance-API-broken/m-p/251741#M3163
 
Depending what one's needs are, you can access free EOD data for futures, forex and stocks through Kinetick via NinjaTrader.

http://kinetick.com/NinjaTrader
 
Depending what one's needs are, you can access free EOD data for futures, forex and stocks through Kinetick via NinjaTrader.

http://kinetick.com/NinjaTrader

With the format you have your chart data is mostly useful to your software users. If you or kinetic can offer an API for easy download in various formats for use with analytics (Python, R, etc.) you can attract a large customer base fleeing Yahoo but you must act fast. There are some programming experts who could help you for quick integration, I can think of Yloader.com I am not associated with them but I have used one of their programs for downloading data from various sites.
 
Last edited:
I said it earlier and this is just my opinion. If you want to still use yahoo for OHLC data (I personally will not) then the solution is to data scrape the html. The OHLC is there,
no need to mess around with cookies. After you jump over that hurdle you then face the issue of possible floating point errors due to how they save the OHLC now. As d08 said, you also face data accuracy issues for ex. dividend adjustments..ect..ect...

The data was once in descending date order. Now I think you would need to do a date sort to get the data right. I don't think the JSON has the dates ascending or descending. It might actually be jumbled. I would need to take a closer look but the investment in time is not worth it with yahoo. They might change their minds next week and come up with new URI structures....waste of time IMHO

{"date":1494855000,"open":68.13999938964844,"high":68.4800033569336,"low":67.56999969482422,"close":68.43000030517578,"volume":31530300,"unadjclose":68.43000030517578},{"date":1494595800,"open":68.61000061035156,"high":68.61000061035156,"low":68.04000091552734,"close":68.37999725341797,"volume":18714100,"unadjclose":68.37999725341797},{"date":1494509400,"open":68.36000061035156,"high":68.7300033569336,"low":68.12000274658203,"close":68.45999908447266,"volume":28789400,"unadjclose":68.45999908447266},{"date":1494423000,"open":68.98999786376953,"high":69.55999755859375,"low":68.91999816894531,"close":69.30999755859375,"volume":17977800,"unadjclose":69.30999755859375},{"date":1494336600,"open":68.86000061035156,"high":69.27999877929688,"low":68.68000030517578,"close":69.04000091552734,"volume":22858400,"unadjclose":69.04000091552734},{"date":1494250200,"open":68.97000122070312,"high":69.05000305175781,"low":68.41999816894531,"close":68.94000244140625,"volume":18566100,"unadjclose":68.94000244140625},{"date":1493991000,"open":68.9000015258789,"high":69.02999877929688,"low":68.48999786376953,"close":69,"volume":19128800,"unadjclose":69},{"date":1493904600,"open":69.02999877929688,"high":69.08000183105469,"low":68.63999938964844,"close":68.80999755859375,"volume":21749400,"unadjclose":68.80999755859375},{"date":1493818200,"open":69.37999725341797,"high":69.37999725341797,"low":68.70999908447266,"close":69.08000183105469,"volume":28928000,"unadjclose":69.08000183105469},{"date":1493731800,"open":69.70999908447266,"high":69.70999908447266,"low":69.12999725341797,"close":69.30000305175781,"volume":23906100,"unadjclose":69.30000305175781},{"date":1493645400,"open":68.68000030517578,"high":69.55000305175781,"low":68.5,"close":69.41000366210938,"volume":31954400,"unadjclose":69.41000366210938},{"date":1493386200,"open":68.91000366210938,"high":69.13999938964844,"low":67.69000244140625,"close":68.45999908447266,"volume":39548800,"unadjclose":68.45999908447266},{"date":1493299800,"open":68.1500015258789,"high":68.37999725341797,"low":67.58000183105469,"close":68.2699966430664,"volume":34971000,"unadjclose":68.2699966430664},{"date":1493213400,"open":68.08000183105469,"high":68.30999755859375,"low":67.62000274658203,"close":67.83000183105469,"volume":26190800,"unadjclose":67.83000183105469},{"date":1493127000,"open":67.9000015258789,"high":68.04000091552734,"low":67.5999984741211,"close":67.91999816894531,"volume":30242700,"unadjclose":67.91999816894531},{"date":1493040600,"open":67.4800033569336,"high":67.66000366210938,"low":67.0999984741211,"close":67.52999877929688,"volume":29770000,"unadjclose":67.52999877929688},{"date":1492781400,"open":65.66999816894531,"high":66.69999694824219,"low":65.44999694824219,"close":66.4000015258789,"volume":32522600,"unadjclose":66.4000015258789},{"date":1492695000,"open":65.45999908447266,"high":65.75,"low":65.13999938964844,"close":65.5,"volume":22299500,"unadjclose":65.5},{"date":1492608600,"open":65.6500015258789,"high":65.75,"low":64.88999938964844,"close":65.04000091552734,"volume":26992800,"unadjclose":65.04000091552734},{"date":1492522200,"open":65.33000183105469,"high":65.70999908447266,"low":65.16000366210938,"close":65.38999938964844,"volume":15155600,"unadjclose":65.38999938964844},{"date":1492435800,"open":65.04000091552734,"high":65.48999786376953,"low":65.01000213623047,"close":65.4800033569336,"volume":16689300,"unadjclose":65.4800033569336},{"date":1492090200,"open":65.29000091552734,"high":65.86000061035156,"low":64.94999694824219,"close":64.94999694824219,"volume":17896500,"unadjclose":64.94999694824219},


Thank you for a tip! yes,the data is still there and can be scrapped from HTML page,but i'm stuck on date format. any idea how to "decode" it? what is this? "date":1492090200

Thanks!
 
tried IB's daily. no go. couple hours coding just to see this after first requests:

what a world we are living in...no free, decent,reliable source of simple daily data for publicly traded securities..fuck..
 

Attachments

  • ib_hist.JPG
    ib_hist.JPG
    62 KB · Views: 81
This Amibroker developer is a genius, I know. He probably figured out a way to make the data requests look like they come from a browser, not an API. But Yahoo can terminate that too anytime. If Amiquote can work with Kinetic it would be great, NinjaTrader and Amibroker can benefit from this unfortunate situation with Yahoo API.

You don't need to be a genius for that as it just comes down to cookies, I could manage to do it with Python. But that's quite irrelevant as the Yahoo data is unusable as of now, the adjustments are all over the place - so if you're okay with trading with charts that have 50%, 100%, 400% gaps on it that didn't actually take place, be my guest. I've moved to IB for now despite the fact that their pacing rules are insane - they treat the biggest data request the same as a tiny EOD one.
 
Thank you for a tip! yes,the data is still there and can be scrapped from HTML page,but i'm stuck on date format. any idea how to "decode" it? what is this? "date":1492090200

Thanks!

That's an unix timestamp, it's literally the seconds from 1st January 1970.

tried IB's daily. no go. couple hours coding just to see this after first requests:

what a world we are living in...no free, decent,reliable source of simple daily data for publicly traded securities..fuck..

I looked at one of those examples and it's not wrong. 1/12/17 AKP close is lower because that's the closing auction which happened at 16:02, the low prices are only recorded up to 16:00. That's actually the correct way to do things. If it makes you feel better, you can adjust the low to that close.
 
Last edited:
That's an unix timestamp, it's literally the seconds from 1st January 1970.



I looked at one of those examples and it's not wrong. 1/12/17 AKP close is lower because that's the closing auction which happened at 16:02, the low prices are only recorded up to 16:00. That's actually the correct way to do things. If it makes you feel better, you can adjust the low to that close.
Thanks d08 for format explanation ! I also looked into time and sales and manually compared some of those days with yahoo and google. Lows on them are equal to close in case of AKP. So I ended up with exact same thing you recommended above. If close 《 low then low =close. Pace limitations are pain in a butt. Another unanswered question that puzzles me is a huge difference in volume reported by IB and yahoo (yahoo and google match between each other). Anyone Can explain it? It's almost ×2 in many cases on liquid securities like QQQ
Thanks!
 
Back
Top