Distill Markets API
An agent-native financial data layer built on an owned SEC pipeline. Fundamentals and raw XBRL facts, point-in-time history with the version and restatement record behind it, institutional (13F) ownership, insider activity, sector capital-cycle analytics, financial-health ratios, quality and distress scores, screening, macro, and SEC filing events, computed from SEC filings we ingest ourselves, behind a single API key. REST and MCP-native.
MCP Server
Hosted at mcp.distillmarkets.com. Point any MCP client at the URL with your key; nothing to install.
REST API
Typed JSON endpoints. One key, scope-gated by tier.
Agent-native
Built for agents and quant workflows, not dashboards.
Overview
All requests are made over HTTPS and return JSON. Authenticate with an API key in the X-Api-Key header. Your plan tier determines which scopes, and therefore which endpoints, your key can access. The Free tier already covers universe screening, sector capital-cycle analytics, macro, SEC fundamentals, insider activity, the largest 13F holders per ticker, SEC filing events, and the delta feed that monitors poll.
Base URL
https://api.distillmarkets.com
Endpoints are versioned under /api/v1, grouped by domain: /api/v1/sec for SEC/XBRL-derived data, /api/v1/macro for macro series, plus ticker search under /api/v1/market.
Quickstart
Grab a free key from the settings page (no card required), then make your first call:
curl https://api.distillmarkets.com/api/v1/macro \-H "X-Api-Key: dmk_your_key_here"
POST /api/v1/sec/screen: on a free key you can screen the entire SEC universe by margins, leverage, R&D, working capital, capex, buybacks and more. The scored metrics, Altman Z and Piotroski among them, need quality:read (Analyst and above); on Free they return null and cannot be filtered on. See Screen Universe under REST API.Measured accuracy
Audited 2026-08-06: independent readers re-derived each sampled value from the filing itself, with our parser output withheld. XBRL fundamentals: 72 of 72 sampled facts exact against the rendered statements (n=72; 12 concepts across 6 era bands, 10-K first prints). Insider Form 4: 29 of 30 transactions exact field by field against the filed XML (n=30; 1 ambiguous by design, 0 errors).
The endpoints below serve the XBRL-era corpus, the pre-2009 text-parsed dataset (its verified tier, on the Pro tier’s pre2009:read scope), and the 13F quarters currently loaded. 13F history reaches back to 2017-03-31. periodEnd for 52/53-week filers is stored month-aligned, about a day off the printed fiscal date, which moves the label and never the value.
$36,537M in the pre-2009 corpus (the original 2009-10-27 10-K) but $42,905M read as-of 2010-06-30 (the 2010-01-25 10-K/A adopting ASU 2009-13/14 was on file by then). Both values are correct for what they represent. Splicing the two corpora across a FY2008–2010 series, using pre-2009 print values on one side of the seam and as-of amended values on the other, reads the accounting-standard adoption as a business event that never happened. Pick one semantics for a series and hold it across the seam; don’t mix sources mid-series.API stability
An agent that loses a field does not get an error. It gets undefined, carries on, and the answer built on it is wrong without saying so. The guarantees below exist because that failure is silent, and because nothing consuming this API reads release notes.
Response shape is additive only
A field served today keeps being served, under the same name and the same type. New behaviour ships as a new field; an existing one is never repurposed. Documented endpoints stay documented.
This is checked rather than intended. The route list and every response field are recorded in snapshots held in the repository, and a removal, rename or retype fails the build before it can reach a release. A change that genuinely cannot be made additively goes to a new version path, and the version it replaces keeps serving for at least six months from the date it is marked deprecated.
Values change under stated rules
Shape is frozen. Values are not, and should not be: companies amend their own filings, and a corpus that ignored that would be wrong on purpose. Three cases, with different guarantees.
Point-in-time reads are reproducible. The as-of endpoints and /api/v1/sec/versions/{ticker} report what was on file at a given date. What was on file at a past date does not change, so the answer does not either. A backtest run today reads the same values when it is re-run next year.
Latest-value reads follow the filings. Fundamentals, events, health and the screener report the most recent filed position. When a company restates, these move. That is the intended behaviour, and it is why the as-of endpoints exist alongside them.
Corrections change values. When we find and fix an error in our own parsing or computation, the affected values change, point-in-time values included. That is the only case in which a point-in-time read returns something different from what it returned before. If a figure you relied on has moved, contact support and we will tell you which correction moved it and when.