Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fetch data from the Tiingo API with a getSymbols.tiingo() method. #220
This enables package users to download historical OHLC, Adjusted OHLC,
Tiingo also provides fundamentals, mutual fund information, aggregated news feeds, crypto, and a 5 minute delay quote system, though this implementation includes no provision for downloading them.
I've been searching for good free data online and Tiingo appears to be not bad! Possibly, good! A big thing for me was that they clearly lay out the methodology for adjustments and give you the data to verify the adjustment. See the bottom of this page
The rate limits are reasonable for good free data. If I need more then I'll be fine with paying $10 bucks a month.
There is also a websocket API which would be cool to use, though I didn't feel like learning how to use that.
I was making this for myself and thought to submit a PR in case you wanted it. It's essentially just a copy/paste of Paul's Alpha Vantage code
So after pulling about 6K stocks from Tiingo I can say the data quality seems pretty good! Running some basic tests there were only about 50 OTC penny stocks which had oddities. Two stocks had negative adjusted values though the unadjusted looked fine. I still need to do a deeper dive, but as of now I think the quality is nice and would be good for users of quantmod.
This is Rishi - founder of Tiingo. The way our system works is that we combine 3-5 data providers for each ticker. We've done this because we've found every vendor misses splits, dividends, or gets the closing values incorrect. We also do this because some vendors have outages. We have a system that runs suites of tests on every data point to help track errors. The additional benefit is that we can keep track of which vendors are good/not-so-good and swap them out.
In the case of Steve's checks - yes we found one vendor was giving us negative values and removed them awhile ago for other reasons. Our systems were able to squash most of the negative values, but a few got through - so 19 of our 60,000 tickers had these values. We've since applied a check and removed those values, so going forward it will not be an issue.
Sometimes we feel like historians - tracking down a merger that happened 10-15 years ago and correcting for issues. And when we do manually override points, we keep an audit log with all the notes from our calculation.
The point of Tiingo is to build the data quality mechanism we always wanted when quant trading. It's taking time but because of the quant community we're rolling through :) Thanks all and thanks @SteveBronder for the PR!
Thanks for the contribution; this is a great start! I need to get an update to CRAN within a couple weeks, and I plan to include this. I'm going to make a few changes, including making @SteveBronder the author instead of Paul.
I'm also going to add an
@tiingo, is there a way request only the unadjusted values, or only the adjusted values? Adding that functionality would be useful for me, and would lower user bandwidth. It would also allow users to calculate the adjusted prices themselves, which should allow them to get greater accuracy with lower bandwidth. Also, is there a documented example of an "over-the-limit" response? I couldn't find one on your website, and I would like to provide users an informative error if they hit a limit. Thanks!
Thanks all for the hard work. @joshuaulrich - would you mind if we implemented this via allowing users to pass the columns they would like? That way we could make this use case more general, and to get just unadjusted prices we could pass the following:
I'm partial to this method as it can allow a more general use case.
Let me know if this would work!
I made an API Token that you can use which will return a usage error:
Of course - the community building this helps us tremendously. Please keep letting us know what we can do.
The ?columns parameter has been added.
To get the data as CSV, append &format=csv, e.g.
Hope this helps!
@joshuaulrich Yes, absolutely it should be a non-200 error code; however, we found that for some platforms, the data may not render in CSV format if an error response is received, so the user could be left with an error with no descriptive message. It was a difficult decision we had to make, and ultimately we decided to keep the message as a 200 response, even with error, so the user could receive some feedback on corrective action. I'm hesitant to change the behavior any time soon as I don't want to break anybody's code without sufficient notice or a LTS migration plan.
I understand the solution is not technically ideal, but generally, we made it a policy that JSON is our preferred method to deliver data, but many people wanted the data in CSV format so we obliged. For some of our APIs, like the crypto one, CSV loses data because we cannot nest or relate data in together. As we are expanding data sources, JSON will be our preferred method because of the flexibility.
Thanks to you and Steve for working on this.
@tiingo That's completely understandable, and I assumed something like that was happening. I wanted to verify, just in case. I also share your reservations about potentially breaking user code, so I'll figure out a work-around.
I would like to talk with you about a few ideas I have. If you're interested, you can reach me via email. My address is in the
Joshua, adjusted close price is different when i get it via different methods.. in getsymbols, adjusted close is actually adjusted open..
riingo <- riingo_prices(c("IBM"), start_date = "2018-04-21", end_date = Sys.Date(), resample_frequency = "daily")