Some of the most useful public data needs no key, no account and no browser. You can get it with one HTTP call. The hard part was never fetching it. The hard part is knowing what the number actually means, because both of the datasets below are routinely quoted as something they are not.
FINRA daily short volume
FINRA publishes a plain text file every trading day listing, per symbol, how much of that day's volume printed on the short side. It is free and it updates daily.
Here is GME across five sessions in early August, as a share of total volume:
Aug 3 79.76%
Aug 4 72.55%
Aug 5 65.09%
Aug 6 61.83%
Aug 7 58.71%
A steady decline, and the kind of shape you only see if you pull the daily file rather than the headline number.
Now the trap. This is short volume, not short interest. They get used interchangeably all the time and they measure different things. Short interest is a standing position, the number of shares currently sold short and not yet covered, and FINRA publishes it twice a month. Short volume is a flow measure for one session.
A 79% reading does not mean 79% of the float is sold short. A large part of daily short volume comes from market makers who take the other side of a buy order and flatten out minutes later. The position never persists. If you build a signal on short volume while describing it as short interest, you are modelling intraday liquidity provision and calling it bearish conviction.
Both numbers are useful. They are not substitutes.
OSV vulnerability advisories
OSV.dev aggregates security advisories across npm, PyPI, Go, Maven, crates.io and more, and serves them over a free API. Give it a package and a version, get back every advisory that matches.
I ran three pinned versions of the kind that sit in a lockfile nobody has touched in two years:
lodash 4.17.15
django 3.2.0
express 4.17.1
That returned 70 published advisories, 24 of them rated High or Critical. Django 3.2.0 on its own accounted for 6 Critical and 15 High, including a SQL injection.
Two traps here.
First, roughly a third of the advisories carried no severity rating at all. Not "low", but absent. If your code does if (severity === 'HIGH') you silently drop those rows, and if you coerce a missing severity to zero you will report a clean scan that is not clean. Keep them null and count them separately.
Second, an advisory matching your version does not prove your code reaches the vulnerable function. A CVE in a parser you never call is real but not urgent. Version matching gives you a triage list, not a verdict, and treating it as a verdict is how teams end up ignoring the whole report.
The field worth building on is firstPatchedVersion. It turns a wall of CVE ids into the one upgrade that clears them, which is the difference between a report and a task.
The pattern
Both of these are official sources, both are free, both are one request away, and both have a headline number that means something narrower than it looks. The work is not in the fetch. It is in the footnote.
I package these as pay per row actors on Apify if you would rather not maintain the plumbing: Short Selling Data Tracker for the FINRA file and Open Source Dependency Vulnerability Scanner for OSV. I ship a new one every few days, so the catalog is bigger by the time you read this.
What is a dataset you have seen confidently misread in production?
Top comments (0)