Where every number in this API comes from, how fresh it is, how we normalize it, and exactly where our coverage stops. This page exists so you never have to take "clean data" on faith.
Every fact this API serves traces back to the SEC's own EDGAR system (data.sec.gov and www.sec.gov), specifically its structured data:
| Dataset | SEC source | Format |
|---|---|---|
| Income / balance / cash-flow statements | Company Facts API (/api/xbrl/companyfacts/) and bulk companyfacts | XBRL (structured) |
| Insider transactions (Forms 3/4/5) | Company submissions index + the filing's ownership document | Ownership XML (structured) |
| 13F institutional holdings | Company submissions index + the filing's information table | 13F information-table XML (structured) |
| Schedule 13D/13G (5%+ ownership) | Company submissions index + the filing document | Structured XML (modern filings only -- see below) |
| Cross-company screening / concept rank | Frames API (/api/xbrl/frames/) | XBRL (structured) |
We never scrape or parse rendered HTML. If a filing type or era only exists as legacy HTML/text (older 13D/G, pre-XBRL financials), we don't attempt to extract it -- see the coverage floors below. Nothing in this pipeline uses an LLM to read or summarize a filing; every field is a value the filer tagged themselves, re-shaped into one consistent schema.
Two different kinds of "lag" are in play, and it's worth keeping them separate: filing lag (how long after a real-world event the SEC's own deadline lets a company wait before filing) and ingest lag (how quickly our pipeline picks up a filing once it's public). Ingest lag is small and under our control; filing lag is set by SEC rules and is not something any data vendor -- us included -- can shrink.
| Dataset | Filing lag (SEC deadline) | Ingest lag (ours) |
|---|---|---|
| 10-Q financials | ~40–45 days after quarter-end (varies by filer size) | Picked up by the daily incremental job the day it posts to EDGAR's daily index. |
| 10-K financials | ~60–90 days after fiscal year-end (varies by filer size) | Same daily incremental job. |
| Insider trades (Forms 3/4/5) | Generally within 2 business days of the transaction, by law | Daily incremental job, plus cache-aside fetch on first read for a company we haven't seen. |
| 13F institutional holdings | ~45 days after quarter-end | Per-manager: on first read. Whole-quarter: a separate bulk backfill job, run per quarter. |
| Schedule 13D/13G | Event-driven (within days of crossing the 5% threshold), not periodic | Cache-aside fetch on first read for an issuer. |
In plain terms: even a "fully up to date" pull from this API reflects filings that were themselves already stale by the time they were required to be filed -- most sharply for 13F (up to 45 days old the moment it's published). This is a structural property of how the SEC's own reporting deadlines work, not a limitation specific to us.
Form 13F is a quarter-end snapshot of long holdings. It is not a transaction feed, and the SEC does not require managers to report individual trades through it. Any "buy" or "sell" you see from this API's activity endpoints is derived: we fetch a manager's (or issuer's) holdings for two consecutive quarters and diff them ourselves, classifying each position as new / added / reduced / exited / unchanged based on the share-count change between the two snapshots.
13F-HR/A supersedes an original 13F-HR); we keep the latest-filed version as current.value across that boundary must account for the shift themselves.Every activity/holdings response from the API carries these points in a machine-readable caveats field. If you republish or display this data, carry that caveat forward -- see the acceptable-use terms.
The SEC requires companies to tag their financial facts with standard US-GAAP XBRL tags, but doesn't require every company to use the same tag for the same concept -- "revenue" alone shows up under at least four different standard tags across real filers, before you even get to company-specific "extension" tags. Our mapping table (normalize/mapping.py) keys a small set of stable canonical concepts (revenue, net_income, total_assets, ...) to an ordered list of candidate GAAP tags; for each company and period, we take the first candidate that has a value.
Every line we return keeps its exact source tag (source_tag) and whether it was a non-standard company "extension" tag (is_extension), so you can audit exactly what we mapped from -- we never hide the original tag behind the clean field name.
Restatements are kept, not overwritten. The same company/period can appear in more than one filing with a different value (a restatement); we keep every version, tagged with its filing accession and filed date, and the latest-filed one wins for "current" views.
Some structural gaps are real, not tagging bugs, and we say so rather than force a number: banks don't file income statements shaped like commercial companies' (no gross_profit, no operating_income in the usual sense), and some retailers don't tag a discrete gross_profit line even though they compute it internally. Those come back as absent, not a fabricated zero.
SEC EDGAR filings are U.S. federal government records and are in the public domain -- we don't claim ownership over the underlying facts, only over our normalization, schema, and infrastructure. As of our last check (2026-07-07), we found no explicit SEC restriction on redistributing this public data, consistent with its public-domain status.
Open item, not yet closed: SEC fair-access and redistribution terms are scheduled to be re-verified in the week of launch, since guidance can change and "last checked" isn't the same as "confirmed current." Treat the paragraph above as accurate as of the date stated, not as a permanent guarantee -- this line will be updated once that re-check happens.
We do rate-limit our own access to SEC's servers (see our SEC fair-access compliance) and identify every request with a descriptive User-Agent, per SEC's developer guidance.