SEC EDGAR API Guide: Fetching Filings Programmatically

What EDGAR actually gives you

EDGAR (Electronic Data Gathering, Analysis, and Retrieval) is the SEC's public filing system. Every electronically filed disclosure the agency accepts is published there, free, with no API key and no registration. That includes the forms most useful to traders and agent builders: quarterly 13F holdings reports (due 45 days after quarter end, required of institutional managers above the $100 million threshold in covered US equities), Form 4 insider transactions (due within 2 business days of the trade), Schedule 13D activist stakes (within 5 business days), Form 3 initial insider statements (within 10 days of becoming an insider), and Form 5 annual catch-ups (within 45 days of fiscal year end). If those forms blur together, the practical differences are covered in 13F vs 13D vs 13G vs Form 4.

Two identifiers organize everything. The CIK (Central Index Key) identifies a filer. The accession number, an 18-digit dash-separated ID, identifies a single filing, and it is the atomic unit of provenance: any claim about a holding should trace back to one. Tickers are not first-class citizens. The SEC publishes a ticker-to-CIK mapping file (company_tickers.json), but the holdings inside a 13F are keyed by CUSIP, not ticker, which is its own resolution problem (see what a CUSIP is and why it matters). The official starting point for the structured endpoints is the SEC's EDGAR API documentation, and for 13F-specific questions the SEC's 13F FAQ is the canonical reference.

The endpoints that matter

EDGAR is really several surfaces stacked on one archive. Here is the map most pipelines end up using:

The CIK must be zero-padded to ten digits on data.sec.gov, and every request needs a User-Agent that identifies you:

# Filing history for Berkshire Hathaway (CIK 1067983)
curl -H "User-Agent: yourname [email protected]" \
  "https://data.sec.gov/submissions/CIK0001067983.json"

The submissions response hands you accession numbers and a primary document name. From there you construct an Archives URL (strip the dashes from the accession number to get the directory) and fetch the documents themselves. Each filing directory also exposes an index.json listing its files. Read it. Do not guess document names; the reason is in the traps section below.

Rate limits and the fair access policy

There is no API key, but there are rules, and they are enforced. The SEC's fair access guidance, published at Accessing EDGAR Data, currently documents a limit of ten requests per second and requires a declared User-Agent with contact information. Anonymous or bursty clients get throttled or blocked outright, which usually surfaces as a wall of 403 responses halfway through a crawl. The practical posture: treat ten per second as a ceiling rather than a target, add exponential backoff, cache everything you fetch, and prefer index files over hammering per-filing URLs.

The load pattern matters more than the limit. Filings cluster hard around statutory deadlines. The 2026 13F deadlines are February 17, May 15, August 14, and November 16, and managers tend to file on or very near the last permitted day, so an ingestion pipeline sees a trickle for weeks and then a flood in a single afternoon (the full calendar is in 13F filing deadlines for 2026). Design for the flood: queue accessions from the index, drain the queue at a polite rate, and accept that on deadline day your freshness lag is governed by the rate limit times the backlog, not by your code. EDGAR also has no SLA. It is a disclosure system, not a market data product, and occasional slowness or maintenance is something your retries simply have to absorb.

Index files: the bulk workhorse

For anything beyond a handful of companies, you stop calling per-company endpoints and start walking index files. Each quarter, the full-index directory carries form.idx (sorted by form type), company.idx (by company name), and master.idx (pipe-delimited, the easiest to parse). A parallel daily-index tree lists what was filed each day, which is what an incremental pipeline actually polls.

The files come with quirks of their own: header preambles you must skip, fixed-width columns in some variants, and company names that can contain your delimiter. The robust pattern is a recurring sweep of the daily index, a diff against the accession numbers you have already ingested, then fetching only the new filings within the rate limit. The index is also where amendments first appear, and they appear without ceremony: a 13F-HR/A or a Form 4/A is just another row. Whether that amendment restates the original filing, extends it, or supersedes it entirely is not the index's problem. It is yours, and it is the single most common place homegrown EDGAR pipelines quietly go wrong.

Why raw EDGAR is harder than it looks

Fetching is a weekend project. Correctness is not. The traps, roughly in the order they will find you:

Filer-controlled file naming. The 13F information table is XML, but its filename is whatever the filer chose. Some of the largest managers publish it under a bare numeric filename with no hint of its contents. Pipelines that pattern-match filenames silently freeze on exactly the filers you care about most. The only safe approach is reading the filing's index.json and verifying the document content itself.

Identifiers. 13F holdings are CUSIPs. Form 4s are keyed by issuer CIK. Nothing hands you tickers, and the mapping shifts as securities change. Entity resolution (manager to fund to filing chain) is a standing project, not a one-time script.

Amendments and supersession. A Form 4/A should replace its original; a 13F amendment can be a restatement or an addition, and real-world usage of those flags is messy. Naive ingestion double counts positions, which is one reason aggregate 13F numbers from different pipelines rarely agree (more on the inherent limits in how accurate 13F data really is).

Format drift. EDGAR spans decades. Older filings are plain text or loose HTML, and even modern XML varies in namespace and structure across filer software.

Options are not longs. 13F put and call positions are flagged separately and must never be summed into a long book. A famous manager's large put position will otherwise render as his top bullish bet.

No point-in-time view. EDGAR serves documents, not a database. Reconstructing what was knowable as of a given date means archiving every version yourself.

From raw filings to one clean call

Honest framing: if you need one company's filing history occasionally, raw EDGAR plus the rules above is genuinely all you need, and it costs nothing. The build-versus-buy line appears when you want cross-filer aggregates, resolved identifiers, amendment handling, and history. That normalization labor is what Arkolith sells. Our Q1 2026 13F dataset covers 1,824 institutional filers, 1.87 million long positions, and $53.7 trillion in reported value, with 51,000+ insider transactions tracked, and every datapoint carries provenance back to its EDGAR accession number so an agent can cite a source instead of inventing one (why that matters for LLMs is covered in stopping AI from hallucinating market data).

# List covered institutional filers
curl -H "Authorization: Bearer YOUR_KEY" "https://arkolith.com/api/v1/funds"

# Resolve a name or ticker across funds, managers, and holdings
curl -H "Authorization: Bearer YOUR_KEY" "https://arkolith.com/api/v1/search?q=NVDA"

# Holdings for one filer by CIK
curl -H "Authorization: Bearer YOUR_KEY" "https://arkolith.com/api/v1/funds/1067983/holdings"

The same normalized data backs human-readable pages, for example institutional ownership of NVDA and Berkshire Hathaway's filing-by-filing portfolio, so you can eyeball what your code returns. Agents can skip REST entirely and connect over MCP. Setup for both paths is in the quickstart.

Frequently asked questions about the SEC EDGAR API

Is the SEC EDGAR API free to use?

Yes, completely. There is no key, no registration, and no usage fee. The costs are operational: you must declare a User-Agent, respect the fair access rate limits, and do all parsing, identifier resolution, and amendment handling yourself.

What is the EDGAR rate limit?

The SEC's published fair access guidance currently documents ten requests per second per client, with a User-Agent that identifies you and includes contact information. Exceeding it, or crawling anonymously, gets you throttled or blocked. Treat it as a ceiling, and lean on index files to keep request volume down.

How do I find a company's CIK number?

The SEC publishes a ticker-to-CIK mapping file (company_tickers.json), and EDGAR's company search accepts names and tickers directly. Remember that a CIK identifies a filer, not a security: one manager can file for many funds, and the holdings inside those filings are keyed by CUSIP rather than ticker.

Does EDGAR provide real-time filing alerts?

No, there is no push API. The standard approach is polling the daily index or a filer's submissions JSON within the rate limits. For most use cases that is fine: a Form 4 already arrives up to 2 business days after the trade itself, so a few minutes of polling latency is rarely the bottleneck.

This article explains public filings and data concepts. It is not investment advice.