A SEC filings API gives software — increasingly, AI agents — structured access to the disclosures public companies file with the SEC: 10-Ks, 10-Qs, 8-Ks, 13Fs, proxies, and the rest. The raw material is public and free on EDGAR, so the question every team building analyst agents eventually asks is: why pay for an API at all? The honest answer is that EDGAR was built to receive and archive filings, not to feed agents — and the gap between those two jobs is exactly what you should evaluate a SEC filings API on.
TLDR:
- EDGAR is enormous and rate-capped: about 4,700 filings a day, 3,000 TB served a year, with automated access limited to 10 requests per second.
- The failure data is measured, not hypothetical: naive retrieval over filings fails 81% of financial questions, and free-text summarization of filings flips investment decisions in 21–53% of cases.
- Evaluate a SEC filings API on seven things: coverage, normalization, citations, section-level retrieval, agent ergonomics, throughput, and benchmarked quality.
What EDGAR gives you — and what it doesn't
Start with the official numbers, because they frame the whole problem:
| EDGAR fact | Number |
|---|---|
| Filings processed | ≈ 4,700 per day |
| Data served to the public | ≈ 3,000 TB per year |
| New filers accommodated | ≈ 40,000 per year |
| Automated access cap | 10 requests/second per user |
Sources: SEC.gov, About EDGAR; SEC.gov, Accessing EDGAR Data. As of July 2026.
Figure 1: EDGAR's scale and its access ceiling. Source: SEC.gov.
Everything on EDGAR is authoritative and free. It is also raw: filings arrive as HTML and XBRL in filer-specific formats, companies are keyed by CIK rather than ticker, and the fair-access policy caps any one user at 10 requests per second across all machines — with a declared User-Agent required. That cap is real: while researching this post, our default fetcher got HTTP 403 from sec.gov until it identified itself. EDGAR is a filing cabinet with rules, not a data feed.
The measured cost of consuming it raw
An agent can, in principle, do everything itself: resolve tickers to CIKs, poll the feeds, download documents, parse, normalize, deduplicate, and cite. The problem is what that pipeline does to answer quality, and it has been measured:
| Failure mode | Measurement |
|---|---|
| Retrieval pipeline over filings (FinanceBench) | GPT-4-Turbo answers 81% of questions incorrectly or refuses; 21% with the right documents in context |
| Free-text summarization of 10-Q MD&A (arXiv:2606.29251) | Flips the bear/neutral/bull decision in 21.3–53.0% of cases vs an 11.0% baseline |
| Dumping full documents into long context (Chroma) | All 18 frontier models tested degrade as input grows; ~300-token focused contexts beat ~113k-token prompts |
Sources: FinanceBench, arXiv:2311.11944 with Patronus AI; When Summaries Distort Decisions, arXiv:2606.29251; Context Rot, Chroma Research.
We've written about both ends of this elsewhere — what compression does to judgment and why model upgrades don't close the gap. The bottleneck isn't reading ability; it's what reaches the model, and how much. A single 10-K's median text grew from ~23,000 words in 1996 to nearly 50,000 by 2013 — tens of thousands of tokens before exhibits. Loading the whole document to extract one number is the path Context Rot punishes; pulling Item 1A as a section costs a fraction of the tokens and sharpens the answer.
Figure 2: The DIY pipeline spends the agent's context and attention before analysis starts.
The seven-point checklist
If you're evaluating a SEC filings API for agent use, these are the questions that separate a document mirror from a data layer:
| # | Criterion | What to ask |
|---|---|---|
| 1 | Coverage & freshness | All form types you need (10-K/10-Q/8-K/13F/proxies)? How fast after EDGAR acceptance? |
| 2 | Normalization | Tickers ↔ CIK resolved? Company names, executives, segments consistent across filings? |
| 3 | Citations | Does every value carry a pointer to the source document and location — or do you re-derive provenance yourself? |
| 4 | Section-level retrieval | Can the agent fetch Item 1A Risk Factors directly, or only whole documents? |
| 5 | Agent ergonomics | MCP server? Markdown/JSON output? Token-efficient responses sized for context budgets? |
| 6 | Throughput | Rate limits that fit a fleet of agents — not EDGAR's 10 req/s shared ceiling. |
| 7 | Benchmarked quality | Is data quality measured against professional providers, or asserted? |
Criteria informed by the failure evidence above; EDGAR constraint from SEC.gov.
Criterion 3 is the one most APIs miss and the one agents need most. An agent's answer is only as trustworthy as its ability to show where each number came from — if citations aren't built into the data, every downstream answer inherits unverifiable provenance. It's also the difference between compression you can audit and compression that quietly changes your judgment.
The test case: horizontal queries
Criteria 4 and 5 have a concrete litmus test: can the agent ask questions across filings, not just retrieve them one at a time? EDGAR is organized by filer, so it answers "what did this fund file?" natively — and almost nothing else.
Take 13F institutional holdings. Each 13F-HR is one fund's table, and institutions filed 33,739 of them in 2025 — ~8,400 a quarter. EDGAR answers "what does this fund hold?" in one document. The question investors actually ask — "which funds hold this ticker, and what changed this quarter?" — means parsing every table filed that quarter into your own inverted index, rebuilt each quarter. A data layer offers both directions as one call: holdings by investor and owners by ticker are the same table read two ways.
Statements work the same way. Filing-oriented access is one company, one period, one document — facts tagged however each filer chose. Normalized statement endpoints let an agent pull one company across quarters, or line companies up side by side, in a single query — and accuracy rises for a dull reason: no hand-stitching of periods and tags, which is where silent errors enter.
Then there's what standard tags miss entirely. The metrics that move stocks — subscribers, deliveries, backlog, segment splits — live in releases and calls, outside the taxonomy; when filers do tag distinctive items they use custom extensions the SEC says reduce inter-company comparability, and EDGAR's cross-company frames API aggregates only non-custom facts. Tag-oriented access is weakest exactly where the differentiated disclosure lives; a data layer extracts it from the documents into cited fields (segment financials, transcripts and documents).
Finally, a time axis. Filers restate: 2025 brought 1,239 amended 13F-HRs, 708 amended 10-Ks, and 1,453 amended 8-Ks. Scrape naively and an agent can cite a number the filer later corrected; a data layer that resolves filings as-amended — and keeps point-in-time snapshots so a backtest sees only what was known then — prevents both mistakes.
Where FocusAlpha sits
FocusAlpha is our answer to this checklist: a SEC filings API built for agents rather than adapted for them. Filings arrive normalized against a source-of-truth ontology, sections are individually retrievable, every value keeps its citation to the underlying document, and agents connect through the API or the MCP server. Filings are one layer of a broader agent-ready dataset — earnings-call transcripts, leadership interviews, and other trusted company communications ship through the same structured interface. And per criterion 7: we benchmark our output against leading industry providers rather than asking you to take data quality on faith.
Whether you build or buy, hold the pipeline to the checklist — the benchmark data says the difference isn't convenience, it's whether your agents' answers survive an audit.
FAQ
What is a SEC filings API?
A programmatic interface for retrieving SEC disclosures — 10-K and 10-Q reports, 8-K events, 13F holdings, proxies — as structured data instead of raw EDGAR documents. For AI agents, the useful ones also normalize entities, expose individual sections, and attach source citations to every value.
Can't my agent just scrape SEC EDGAR directly?
It can — EDGAR is public and free — but it inherits a pipeline: CIK resolution, polling, HTML/XBRL parsing, normalization, and citation tracking, all under EDGAR's 10 requests/second fair-access cap. The measured result of doing this naively is an 81% failure rate on financial questions.
What is SEC EDGAR's rate limit?
The SEC's fair-access policy caps automated access at 10 requests per second per user, regardless of how many machines you use, with a declared User-Agent required. Exceeding it gets your IP temporarily blocked.
What should I look for in a SEC filings API for AI agents?
Seven things: coverage and freshness, entity normalization, built-in source citations, section-level retrieval, agent ergonomics (MCP, structured output), throughput beyond EDGAR's shared cap, and benchmarked data quality. Citations are the most commonly missing and the most important for auditable answers.
Why do retrieval pipelines fail on SEC filings?
Filings are long, filer-formatted, and full of qualifying context. On FinanceBench, a standard vector-store retrieval pipeline led GPT-4-Turbo to fail 81% of questions — while the same model given the right documents failed 21% — and summarizing filings free-text flips investment decisions in 21–53% of cases.
Can I query 13F holdings by ticker instead of fund by fund?
Not from EDGAR — 13F reports are filed per fund, and institutions filed 33,739 13F-HR reports in 2025, so inverting them to "who holds this ticker?" is a quarterly parsing job. A SEC filings API with an inverted holdings index, like FocusAlpha's owners-by-ticker endpoint, returns it in one call.
Does FocusAlpha provide a SEC filings API?
Yes — /v1/filings lists a company's SEC filings with accession numbers and document URLs, and companion endpoints return filing sections, normalized financials, and 13F holdings. Agents can also connect through the MCP server.
What is FocusAlpha?
FocusAlpha is a SEC filings API and agent-ready financial data layer: it turns SEC filings (10-K, 10-Q, 8-K, 13F), earnings-call transcripts, and other trusted company communications into structured, normalized data where every value keeps its citation back to the source document. AI agents connect via API or MCP to research public companies from complete, trusted information.