EDGAR full-text search API: query every SEC filing

Every endpoint on this page was live-probed on 2026-07-29 by the Aidenix Atlas catalog.

What is EDGAR full-text search?

EDGAR full-text search is a keyless SEC endpoint that searches the text inside filings rather than their metadata, and it answers questions no company database can. In our data — the Aidenix Atlas catalog, endpoint live-probed on 2026-07-29 — a single query for «quantum annealing» returned 147 documents across the entire SEC corpus, narrowed to 40 when filtered to 8-K reports and 16 when limited to 2026. Three things make it different from the rest of EDGAR:

• It searches filing text, so you can find every company that mentioned a technology, a competitor, or a risk.
• It needs no API key and no registration — one GET, JSON back.
• It ships undocumented aggregations that return the industry, form-type and company distribution of your matches in the same response.

Key facts at a glance

A key-facts table is the 60-second version of this page. In our data: no key, 4 filter parameters, 4 aggregation facets, one hard ceiling at 10,000 documents. Every row from our own probe run of 2026-07-29, according to the Aidenix Atlas catalog logs:

How do you query EDGAR full-text search?

An EDGAR full-text query is one GET with a phrase in q, and every refinement is another query parameter. According to our probe of 2026-07-29:

# SEC returns 403 without a declared User-Agent carrying a contact address
curl -A "Your Company research contact@example.com" \
  "https://efts.sec.gov/LATEST/search-index?q=%22quantum+annealing%22&forms=8-K"

We ran the unfiltered version of that query on 2026-07-29 — 147 documents — and here are the top 3 results exactly as returned:

The four filters compose, and each one narrowed the same phrase in our probe run:

• forms=8-K cut 147 documents to 40 — form filtering is the cheapest precision gain available.
• startdt=2026-01-01&enddt=2026-07-29 cut it to 16, which turns the endpoint into a change detector.
• ciks=0001907982 scopes the search inside one company; the phrase «quantum» returned 1,179 documents for that single filer.
• from=100 walks the result set 10 records at a time. Full parameter list: the EDGAR full-text access card.

Why is the result count sometimes a lie?

The total in an EDGAR full-text response is exact or capped, and the response tells you which — in a field almost nobody reads. In our probe of 2026-07-29, the rare phrase «quantum annealing» came back as {"value":147,"relation":"eq"}, while the common phrase «quantum computing» came back as {"value":10000,"relation":"gte"}. Those are not both counts:

• relation: "eq" — 147 is the real number of matching documents.
• relation: "gte" — there are at least 10,000; the true total is unknown and unavailable.

The ceiling is not just a display limit, and we verified where it bites. Paginating the same query, from=9900 returned a full page of 100 records; from=10000 returned nothing at all. In our data the accessible window is exactly 10,000 documents per query, no matter how many actually match. The workaround is to slice the query until every slice reports eq:

• Split by date: run the same phrase quarter by quarter, then sum exact counts.
• Split by form: forms=10-K alone returned 867 documents for «quantum computing» — an exact number where the unfiltered query gave only a floor.
• Split by filer: apply ciks when you already know the universe of companies you care about.

What do the undocumented aggregations return?

An aggregation facet is a distribution of your matching documents, returned in the same response at no extra cost. In our data, EDGAR ships 4 of them that the public documentation never mentions: entity_filter, form_filter, sic_filter and biz_states_filter. That turns a search endpoint into a free market-research primitive. According to our probe of 2026-07-29, the phrase «quantum computing» returned 10,000+ documents whose form distribution came back like this, unedited:

Read that table before you trust any naive keyword count, because it is the trap of full-text search on a technology term. The top two form types — NPORT-P and 13F-HR — are fund holdings reports, not company disclosures. The phrase is showing up because investment funds list quantum-computing stocks among their positions, and the top entity in the same response was EQ Advisors Trust with 699 documents: an annuity fund, not a technology company. Filtering to forms=10-K or 8-K is what separates companies talking about the technology from funds holding it.

What can EDGAR full-text search not do?

A full-text index is a document search, not a company database, and in our data it has 4 walls worth knowing before you build on it. Of the nearly 4,000 sources the Aidenix Atlas catalog tracks, this one is among the most capable free routes and still cannot do the following:

• No totals above 10,000 — verified above; slice the query or accept a floor.
• No relevance you control — there is no scoring parameter, so precision comes from filters alone.
• No private companies — the corpus is SEC filings, so a company that never filed is simply absent.
• No structured financials — for reported numbers use the XBRL routes covered in our SEC EDGAR API guide.

Frequently asked questions

Is the EDGAR full-text search API free? Yes, and keyless. The only client requirement is a declared User-Agent header naming you and a contact address; SEC returns 403 without one, which reads as a block but is their fair-access rule rather than rate limiting.

How far back does full-text search go? The full-text index covers filings from 2001 onward, which is shallower than EDGAR itself — the filing archive reaches back to 1994. For pre-2001 documents you search metadata and fetch the document, rather than searching its text.

Can I use it to track competitor mentions? Yes, and the date filters are what make it practical. In our probe, adding a 2026 date range cut a 147-document result to 16 — small enough to review by hand, which is the difference between a monitoring job and a research project.

How we verify these claims

Our verification method is a live probe, not a citation chain — every count, sample and limit on this page comes from requests we sent ourselves on 2026-07-29. What the probe run covers, in our data:

• Endpoint liveness: the route answered HTTP 200, out of the nearly 4,000 sources the Aidenix Atlas catalog tracks.
• Live samples: the D-Wave result rows and the form distribution are unedited API output.
• Limits found by testing: the 10,000-document wall came from paginating until the endpoint went empty, not from documentation.
• Freshness contract: when a source drifts, the probe fleet flags it and this page gets re-verified — the «last probed» date above is that promise.

Source facts from the Aidenix Atlas catalog, probed 2026-07-29. Found an error? The catalog re-probes on every report.