The SEC EDGAR API: What It Offers and Where It Falls Short

The SEC gives developers free, documented access to EDGAR data through a set of JSON APIs, no account or key required. That access is genuinely good for a government source, but it comes with real limits: the data is organized by filing and by XBRL fact, not by business question, so some common tasks still require a lot of parsing. This guide covers what the official EDGAR APIs provide, how fair access works, and where the gaps are.

What the SEC EDGAR API actually is

"The EDGAR API" usually refers to a handful of JSON endpoints under data.sec.gov, separate from the main www.sec.gov filing archive:

Alongside these, the raw filing archive at www.sec.gov/Archives/edgar/data/... holds the original documents: the filed HTML, XML and exhibits for every submission, which the JSON APIs reference by accession number but do not replace.

Fair access: the rules you have to follow

The SEC does not require an API key, but it does require you to identify yourself and stay within its fair access limits. Every request needs a descriptive User-Agent header, typically a company or application name plus a contact email, and the SEC publishes guidance that requests should stay under roughly 10 requests per second to avoid being blocked. There is no published daily quota beyond that rate guidance, but there is also no service level agreement: the SEC can and does change behavior without the kind of notice a commercial API vendor would give.

Filing history: the submissions endpoint

The submissions endpoint is the closest thing to a general purpose filing index. For a given CIK, it returns the company's name, former names, SIC code, fiscal year end, and a filings.recent block with parallel arrays for form type, filing date, accession number and a few other fields for the company's most recent filings. Companies with a long filing history get the rest in paginated additional files referenced in the same response.

That structure is efficient, but it is per-company. There is no single endpoint to ask "show me every 8-K filed with item 1.05 last week across all companies" or "show me every Form 4 filed by officers today." You either poll submissions for companies you already track, or work from the EDGAR full text search or the daily and quarterly index files, and reconstruct the filtering yourself.

XBRL facts: deep, but inconsistent across companies

The companyfacts, companyconcept and frames endpoints expose structured financial data pulled directly from each company's XBRL tagging, in the US GAAP or custom taxonomy the filer used. This is powerful: you can pull a specific line item, like revenue or total assets, across many quarters for one company, or across every company that reported a given concept in a given period.

The catch is that XBRL tagging is set by each filer, not standardized for easy cross-company comparison. Two companies can report conceptually similar line items under different tags, with different scaling or different member dimensions, so building a clean side by side comparison across companies still takes real normalization work on top of the raw facts.

Full text search: broad, but recent

EDGAR full text search covers the text of filings and exhibits filed since 2001, letting you search for exact phrases across form types, date ranges and specific filers. It is a genuinely useful discovery tool, for example finding every 10-K that mentions a specific risk phrase in a given quarter.

It does not cover filings before 2001, and it searches text, not structured fields: it can tell you that a phrase appears in a filing, but not pull out a specific numeric value from the surrounding table the way an XBRL query can.

Where the official API leaves gaps

The official EDGAR APIs are strong on filing history and XBRL, but several common developer tasks are left as "go parse the filing yourself":

• Insider trading (Forms 3, 4, 5). These are filed as individual XML documents per transaction. There is no endpoint that returns, say, every open market purchase by a company's officers over the last month as rows.
• 13F holdings. Each 13F's information table is its own XML document per manager per quarter. Comparing holdings across managers or quarters means downloading and parsing many filings.
• 8-K item classification. The submissions endpoint tells you a filing is an 8-K, but not which item numbers it covers. That requires reading the filing itself.
• Real-time notification. There is no push or webhook mechanism. Watching for new filings means polling the index files or full text search yourself, and building your own deduplication and backoff.
• Identifier mapping. The SEC does not maintain a current, ongoing CIK to CUSIP mapping service, which matters because many institutional datasets, including 13F holdings, key on CUSIP rather than CIK or ticker.

Working with the data instead of around it

For straightforward lookups, calling the official endpoints directly is often the right choice; they are free, well documented, and have no usage cost. For the tasks above, filtered, cross-company queries over insider trades, 13F holdings or 8-K items, SecFeed parses the same underlying filings once and exposes them as queryable rows, so you do not have to rebuild that parsing yourself:

curl "https://secfeedapi.com/v1/filings?query=formType:\"8-K\" AND items:\"1.05\"&size=10" \
  -H "Authorization: Bearer YOUR_API_KEY"

from secfeed import Client

sf = Client("YOUR_API_KEY")
filings = sf.filings('ticker:AAPL AND formType:"10-K"')
for f in filings:
    print(f["formType"], f["filedAt"], f["accessionNo"])

Both approaches read from the same public EDGAR data. The choice is whether you want to parse filings yourself or query already structured rows, and nothing stops you from mixing the two: pulling raw XBRL directly from the SEC for one task and using a structured API for cross-filing search on another.

Frequently asked questions

Do I need an API key for the SEC's own EDGAR API?

No. The SEC's JSON APIs under data.sec.gov do not require registration or a key. You do need to send a descriptive User-Agent header identifying your application or company, and you should stay under the fair access guidance of roughly 10 requests per second.

What happens if I exceed the SEC's rate limit?

The SEC's fair access policy warns that exceeding the guidance can result in your requests being throttled or blocked. There is no published official appeals process for a block, so the safer approach is to throttle your own requests well under the limit and add caching so you are not re-fetching the same data repeatedly.

Can I get real-time alerts for new SEC filings from the official API?

Not directly. The SEC's APIs are pull based: you query them, they do not push to you. Getting near real-time notice of new filings means polling the index files, EDGAR full text search, or a third party stream that already does that polling, such as SecFeed's server-sent events stream at /v1/stream.

Does the EDGAR API give me parsed financial statements?

It gives you XBRL facts, which are the underlying numbers with their tags, not a formatted income statement or balance sheet. Turning those facts into a standard set of statement line items requires mapping the tags used in each filing, since different filers can tag conceptually similar items differently.

Is the EDGAR full text search the same as searching all SEC filings ever made?

No. Full text search covers filings and exhibits submitted since 2001. Older filings exist in the EDGAR archive and can be retrieved by accession number, but they are not covered by full text search.