SEC Filings API: What Agents Actually Need

What should an SEC filings API return?

An SEC filings API should return the filing record and the evidence needed to trust it. The minimum useful response includes the form type, filer CIK, accession number, accepted timestamp, filing URL, parsed fields, amendment relationship, and a clear statement of what the filing can and cannot prove.

For an AI agent, that source packet matters more than a polished summary. A model can write a paragraph from almost anything. It can only cite the filing when the API gives it a stable evidence trail.

Arkolith's production database had 4,078,951 filing events with the newest accepted record at 2026-08-17 14:29:29 UTC. The same production stats showed roughly 84.2 million holdings rows, 9.9 million insider transaction rows, and 4.1 million source-record rows. Those numbers are the reminder: the fetch is small compared with the archive, parse, resolve, and provenance work.

Is the SEC EDGAR API already enough?

The SEC's own EDGAR Application Programming Interfaces page says data.sec.gov provides RESTful JSON APIs without authentication or API keys. It also says the current API set includes submissions history by filer and XBRL financial-statement data, with JSON structures updated throughout the day as submissions are disseminated.

That is enough when your job is narrow: pull one company's submissions JSON, inspect a 10-K, or fetch XBRL facts for one issuer. The official data.sec.gov landing page is the right starting point for that work.

The build-versus-buy line appears when the caller needs normalized cross-filer data. EDGAR gives you documents. A research system still has to decide which file inside an accession is the information table, whether a Form 4/A supersedes an earlier ownership record, how a CUSIP maps to a ticker, and whether a filing has enough source context to support a downstream claim.

Which SEC filing types matter most for agents?

Agents need filing data that answers a research question, not a mirror of every EDGAR document. The practical first set is 13F holdings, Forms 3/4/5 insider ownership, Schedule 13D and 13G beneficial ownership, and company periodic reports when the workflow needs financial-statement facts.

The SEC Form 13F FAQ says institutional investment managers must file Form 13F if they exercise investment discretion over $100 million or more in Section 13(f) securities. A 13F API can answer who reported owning a stock, what changed versus a comparable filing, and which accession proves the number. It cannot prove a live trade or a short position.

For insiders, the SEC's Insider Transactions Data Sets page says the data sets are extracted from XML-based Forms 3, 4 and 5. The SEC's officers, directors and 10% shareholders guidance says Section 16 insiders must report most transactions within two business days on Forms 3, 4 or 5. That clock makes Form 4 useful for monitoring, but it still does not prove illegal insider trading.

What makes filing data hard after the fetch?

The hard part is turning legal documents into a source-backed data contract. EDGAR is public, but public does not mean normalized.

Four problems show up quickly:

1. Filing directories are not uniform. You often need the accession directory and its file index before you can find the right table or XML document.
2. Identifiers are form-specific. A 13F holding is keyed by CUSIP, while a Form 4 ownership report carries issuer and reporting-owner fields.
3. Amendments change meaning. A corrected 13F or Form 4 can replace an earlier record, add a missing line, or create a narrow correction.
4. Filing clocks are not event clocks. A transaction date, report period, filing date, and accepted time can all be different.

That is why the SEC EDGAR API guide and 13F holdings API are separate jobs. The first explains how to fetch the raw source. The second explains what a normalized holdings workflow should return.

How should an API expose source proof?

An SEC filings API should make provenance first-class. Put the source URL next to the number, not in a footnote that disappears when an agent summarizes the response.

For Arkolith, that means source records, accession numbers, accepted dates, and evidence links travel with the answer. The public 13F data layer is the institutional-holdings surface. The Form 4 data layer is the insider-transaction surface. The live MCP catalog API listed 40 tools on August 17, 2026, including capital-change, fund, holdings, search, insider, signal, and provenance tools.

The useful API answer is therefore not "NVDA has many institutional holders." It is a narrow packet: which filer, which period, which accession, which accepted time, which comparable prior filing, which parsed rows, and what the record excludes.

When should you use REST, MCP, or raw EDGAR?

Use raw EDGAR when you need a small number of primary records and can tolerate writing your own parser. Use REST when your application already knows the endpoint and arguments. Use MCP when the caller is an AI agent that should discover tools, choose one, call it, and cite the source in the same workflow.

The SEC fair-access page, Accessing EDGAR Data, documents a current maximum request rate of 10 requests per second. Respecting that limit is table stakes. It does not solve parsing, amendment handling, entity resolution, or source-bound answers.

What is the first workflow to test?

Start with one ticker and one question that needs a source trail. A good test is: "What changed in reported ownership, and which filing proves it?"

In Arkolith, the fastest product-shaped test is the capital-change brief workflow. It combines current 13F ownership and qualifying Form 4 context, then returns the coverage limits and SEC evidence behind the answer. You can start from /connect, mint an evaluation key, and call the same data over MCP or REST.

For background before testing, use MCP versus REST API, how to track institutional ownership changes, how to track insider transactions, and stopping AI from hallucinating market data. The point is not to make the agent sound confident. The point is to make every confidence-bearing sentence traceable.

Frequently asked questions about SEC filings APIs

Is an SEC filings API free?

The official SEC EDGAR APIs are free and do not require an API key. The cost starts when you need normalized fields, amendment handling, identifiers, history, source records, and a production system that can answer across many filers.

What is the difference between EDGAR and a filings API?

EDGAR is the public filing system and source archive. A filings API is an interface over those records. The best APIs preserve EDGAR evidence while adding parsing, search, joins, accepted-time cursors, and safe error semantics.

Can a filings API show live trades?

No. A filing reports what the form reports on its own clock. A 13F is quarterly and delayed. A Form 4 is usually due within two business days for Section 16 insiders. Neither should be described as a real-time trading feed.

What should an AI agent require from filing data?

Require the form type, accession number, accepted time, source URL, parsed fields, coverage boundary, and error state. If the API returns only prose, the agent has no reliable evidence packet to cite.

Should I use MCP or REST for SEC filing workflows?

Use REST for deterministic application code. Use MCP when an agent needs to discover tools and decide which filing workflow to call. The data contract should match in both places: same source links, same clocks, same limits.

This article explains public filings and data workflows. It is not investment advice, legal advice, tax advice, or a recommendation to buy or sell any security.