Filing Full-Text Search API

Searches across the full text of EDGAR filings and their attachments are served by the /full-text-search endpoint. To find every filing that mentions a particular company name or product, put the term (or its exact phrase enclosed in double quotes) into the query field and set the date range to start at the beginning of coverage. The dataset covers all EDGAR filings and exhibits filed since 2001, so the value of startDate should be 2001-01-01 and endDate should be today's date.

Leave formTypes and ciks unset so that no form-type or filer filter is applied — that way every form type and every filer, active or delisted, is considered. Each response returns up to 100 matching filings in the filings array along with a hit count in total.value and total.relation, and you walk through results by incrementing page until you have collected everything you need.

To flag potential going-concern language in periodic reports, search the full text of filings on the /full-text-search endpoint and look for the exact phrase wherever it appears. The value of query should be the phrase substantial doubt enclosed in double quotes, which requires both words to appear in that order anywhere in the filing or its exhibits.

To restrict the match to annual and quarterly reports, the value of formTypes should be the list ["10-K", "10-Q"], which causes the search to ignore every other EDGAR form type. The response lists matching documents in the filings array along with the filer's CIK (cik), ticker (ticker), the form (formType), the document type (type) — useful for separating the main report from its exhibits — and the source URL on SEC.gov (filingUrl).

Material-weakness disclosures appear as small variations of a common phrase inside the filing text, so the /full-text-search endpoint is the right tool. Build the query value as the alternative phrasings joined together — for example the phrase identified material weakness and the phrase identified a material weakness, each enclosed in double quotes, combined as alternatives so that a document matches when any one of them is present. The capitalized boolean OR keyword is what expresses that alternative relationship inside the query string.

Leave formTypes open if you want every disclosure (including 8-Ks announcing the finding and amendments) or narrow it to ["10-K", "10-Q"] if you only care about periodic reports. The matched documents are returned in the filings array, each with its accession number (accessionNo), filing date (filedAt), and source URL (filingUrl) so you can read the surrounding context on SEC.gov.

To restrict a full-text search to one filer, hit the /full-text-search endpoint and pass the company's CIK in the filter list. The value of ciks should be an array containing that single CIK as a string, for example ["0001318605"] for Tesla — leading zeros are optional, so ["1318605"] works as well. Only filings and exhibits whose filer matches that CIK are then scored against the query term.

If you only have a ticker or a company name rather than a CIK, resolve it first through the Mapping API at /mapping/ticker/<TICKER> or /mapping/name/<NAME>, take the cik from the response, and use that value in the ciks array of the full-text search request.

Form-type filtering on the /full-text-search endpoint is controlled by the formTypes parameter, which takes an array of EDGAR form-type strings. To keep only current reports and annual reports, the value of formTypes should be ["8-K", "10-K"] — every other form type (10-Qs, S-1s, proxy statements, registration statements, and so on) is then dropped from the result set.

The filter is exact-match on the form-type string, so amendments like 10-K/A or 8-K/A are not included unless you list them explicitly. To include amendments as well, expand the array to ["8-K", "8-K/A", "10-K", "10-K/A"].

The query parameter on the /full-text-search endpoint joins space-separated terms with an implicit AND, so listing several words next to each other in the value already requires all of them to be present somewhere in the filing or its exhibits. For example, the value of query should be SpaceX Elon to retrieve filings that contain both SpaceX and Elon in any order, anywhere in the document.

The same rule applies when mixing single words and quoted phrases — for example the value of query can be Tesla followed by the quoted phrase model x to require both the word Tesla and the exact phrase model x to appear together. Matching is case-insensitive, so capitalization in the query does not affect what is matched.

To match documents that contain at least one phrase out of a list of alternatives, build the query value on the /full-text-search endpoint as those phrases joined with the capitalized boolean OR keyword. Each phrase is enclosed in double quotes so its words must appear in that order; for example a query made up of the phrase qualified opinion and the phrase In our opinion, except for, joined as alternatives, retrieves filings that contain either phrase.

The OR keyword must be uppercase — lowercase or is treated as a literal word to search for. You can chain more than two alternatives the same way, and you can mix alternatives with required terms by leaving non-alternative terms space-separated, since space-separated terms are still joined by an implicit AND.

To drop documents that contain an unwanted term, prefix that term with a hyphen (or use the capitalized NOT keyword immediately before it) inside the query value on the /full-text-search endpoint. For example, a query that requires software while excluding hardware is written as software followed by hardware prefixed with a hyphen — the result is filings that mention software but not hardware.

The exclusion applies to whichever term immediately follows the hyphen or the NOT keyword, and you can use it together with quoted phrases — for instance keeping the going-concern phrase substantial doubt (in double quotes) while filtering out filings that also mention opinion is expressed the same way.

Wildcard expansion on the /full-text-search endpoint is done by appending an asterisk to the stem inside the query value. For example, the value of query should be gas* to match documents that contain gas, gasoline, gases, and any other term that starts with gas.

The asterisk only works at the end of a term — it cannot be placed at the beginning or in the middle of a word, and it cannot appear inside a quoted exact phrase. To combine a wildcard with other constraints, mix it with normal terms or quoted phrases in the same query, for example gas* together with the quoted phrase Sacramento CA to require both a gas-stemmed term and that exact phrase.

Date filtering on the /full-text-search endpoint is controlled by the startDate and endDate parameters, both formatted as yyyy-mm-dd. The value of startDate should be the first day of the window (for example 2024-01-01) and the value of endDate should be the last day (for example 2024-03-31); both bounds are inclusive and apply to the filing's publication date on EDGAR.

If you omit one or both, the endpoint defaults to the last 30 days — startDate defaults to 30 days ago and endDate defaults to today. The filing date that comes back in each result (filedAt) uses the same yyyy-mm-dd format, which lets you sanity-check that the matches fall inside the window you requested.

Each call to the /full-text-search endpoint returns at most 100 matching documents inside the filings array, and additional pages are fetched with the page parameter. The value of page should be a string-encoded number — 1 returns documents 1 through 100 (the default), 2 returns 101 through 200, 3 returns 201 through 300, and so on.

The number of pages available is bounded by total.value: when total.relation is eq, divide that value by 100 (rounding up) to get the last meaningful page; when total.relation is gte, the total is capped at 10,000 and so is the highest page you can usefully request (page 100). Beyond that the endpoint will not return more results for the same query.

The /full-text-search endpoint returns at most 10,000 documents per search query — when more filings match, total.relation comes back as gte and total.value is 10000, and the endpoint will not paginate past those 10,000 hits. To collect every match for a broad query, split it into smaller searches whose result sets each fall under the cap.

The most natural split axes are the date range and the filer list. Narrow the startDate/endDate window — for example one month or one quarter at a time — and run the same query for each window, advancing the window until the entire period of interest is covered. Alternatively, partition by filer by issuing separate requests with one or a few CIKs each in the ciks array. After each request, check that total.relation is eq and total.value is below 10,000 — if it is still gte, narrow the window further before paginating.

The /full-text-search response carries the hit count in a total object with two fields: total.value and total.relation. When total.relation is eq, the value of total.value is the exact number of matching documents and is less than 10000, so you know exactly how many filings exist for the query.

When total.relation is gte, the value of total.value is 10000 and the true match count is at or above that number — the endpoint will not enumerate documents beyond the first 10,000. Treat that as a signal that the query is too broad and split it into smaller searches, for example by narrowing the date window in startDate/endDate or by listing specific filers in ciks.

The /full-text-search endpoint supports two authentication styles: the API key can be appended to the URL as a token query parameter, or it can be carried in an Authorization HTTP header. To keep the key out of the URL, use the header-based style and omit the token parameter entirely.

The API key itself is the one shown in your sec-api.io user profile, and it is the same value regardless of which of the two authentication styles is used.

Searches on the /full-text-search endpoint already scan the entire filing content including all attachments, so any term placed in query is matched against the body of the primary document and the full text of every exhibit at the same time. You do not need any extra parameter to enable this — by default a press release filed as EX-99.1 or a material contract filed as EX-10.1 is indexed alongside the parent 8-K or 10-Q.

Each hit in the filings array represents one matched document. The form type of the parent filing is in formType (for example 10-Q), and the document type of the matched piece is in type (for example EX-10.1 for an exhibit or 10-Q for the main report), which lets you tell whether the search matched the body of the filing or one of its attachments.

To match a city or location name on the /full-text-search endpoint, put the location in double quotes inside the query value so that the words are required to appear together in the right order. For example, the value of query should be the phrase Sacramento CA in double quotes to find filings that contain that exact phrase, and the phrase San Francisco CA in double quotes for San Francisco.

Locations often appear in more than one common form, so you can broaden the search by listing alternative phrasings — for example the exact phrase Sacramento CA and the exact phrase Sacramento, California joined with the capitalized boolean OR keyword inside the query value. The match is case-insensitive, but the words inside each quoted phrase must appear adjacent and in that order.

Earnings press releases are typically filed as exhibits to 8-K current reports, and the /full-text-search endpoint indexes both the 8-K body and its exhibits together. Put the product name or financial term — for example the quoted phrase iPhone revenue — into the query value, and set the value of formTypes to ["8-K"] so that only 8-Ks and their attached press releases are considered.

To focus on recent filings, narrow the window with startDate and endDate in yyyy-mm-dd form, or leave both unset to fall back on the default last-30-days window. In the filings array, look at type to separate the main 8-K (8-K) from the press-release exhibit (EX-99.1), and follow filingUrl to read the exhibit on SEC.gov.

Litigation discussions show up in periodic reports (10-Ks, 10-Qs), in 8-Ks announcing new actions, and in exhibits, so the /full-text-search endpoint can cover all of them in a single query. Build the query value to combine the party's name as a quoted phrase with litigation vocabulary — for example the quoted phrase Acme Corporation joined with the words lawsuit, complaint, or litigation as alternatives (using the capitalized boolean OR keyword between them), which requires the party name and at least one of the litigation terms to appear together.

If you want to focus on the filer that is discussing the lawsuit (as opposed to filings by the party itself), set ciks to that filer's CIK. To survey only periodic reports, set formTypes to ["10-K", "10-Q"]; to surface litigation announcements as they happen, use ["8-K"] instead. Each match in the filings array carries the filer's CIK (cik), the form (formType), and the SEC.gov URL (filingUrl) for review.

To build a time series of mentions on the /full-text-search endpoint, hold the search term constant and slide the date window across the period of interest. Put the phrase in query (for example the quoted phrase generative AI, in double quotes so the words stay adjacent), and run a series of requests where startDate and endDate each cover one window — for example one month or one quarter — advancing both forward in yyyy-mm-dd steps until you reach today.

For each window, the response gives a count of matching documents in total.value (with total.relation set to eq when the count is exact). Aggregating those counts across windows gives the trend over time. If a window's total.relation comes back as gte, the window is too broad and should be split further; if you also want the underlying documents, paginate each window with page and collect the filings array.

To restrict a topic search to a peer set on the /full-text-search endpoint, list every peer's CIK in the ciks array and put the topic in query. For example, the value of ciks should be an array such as ["0000320193", "0000789019", "0001652044"] for Apple, Microsoft, and Alphabet, and the value of query should be the topic itself — a single word, a quoted exact phrase, or a list of alternative phrases joined with the capitalized boolean OR keyword.

Leading zeros in the CIK strings are optional, and formTypes can be set alongside to narrow further to periodic reports or current reports. Each hit in the filings array carries the filer's CIK (cik), name (companyNameLong), and ticker (ticker), which lets you group the matches by peer once the results come back.

The /full-text-search endpoint only accepts CIKs in its ciks filter, so when you have a ticker or a company name, resolve it to a CIK first using the Mapping API. Hit /mapping/ticker/<TICKER> to map a ticker (for example TSLA) to company details, or /mapping/name/<NAME> to look up by company name; both return an array of companies with the matching cik for each.

Take the cik value from the Mapping API response and pass it in the ciks array of the /full-text-search request. If a ticker has belonged to multiple entities over time (one currently listed and one delisted), the Mapping API returns each separately, and you can include every relevant CIK in ciks to cover the full history.

Each hit in the filings array returned by the /full-text-search endpoint includes the source-document URL on SEC.gov in the filingUrl field. For the main filing body the URL points to the primary document (for example a 10-Q HTML file), and for an exhibit it points directly to that exhibit's file (for example an EX-99.1 press release).

The URL is the same one EDGAR serves, so you can open it in a browser or fetch it directly. Alongside it, accessionNo identifies the full submission on EDGAR and filedAt gives the filing date, both of which can be used to reconstruct or cross-reference the source if needed.

Each entry in the filings array returned by the /full-text-search endpoint carries two type fields: formType identifies the EDGAR form of the parent filing (for example 10-Q or 8-K), and type identifies the specific document inside the filing that matched. When the two are equal — for example formType is 10-Q and type is 10-Q — the hit is the main filing body; when type starts with EX- (such as EX-99.1 or EX-10.1) the hit is an attached exhibit of the parent filing whose form is in formType.

Multiple entries with the same accessionNo can therefore appear in the same response, one for the main document and one for each matched exhibit, allowing you to count the parent filing once and treat its exhibits as separate matches.

On the /full-text-search endpoint, build the query value so that the two competing names are listed as alternatives (joined with the capitalized boolean OR keyword between the two quoted names) and the third name is excluded by prefixing it with a hyphen — or equivalently by placing the capitalized NOT keyword immediately before the third quoted name. The combined effect is that a document must contain at least one of the first two names and must not contain the third.

Both OR and NOT must be uppercase to be treated as operators rather than literal words. The same compositional pattern extends to more than two alternatives or to multiple exclusions placed inside the same query value.

The /full-text-search endpoint defaults startDate to 30 days ago and endDate to today when both are omitted, so a last-30-days search for a specific filer needs only the query and the CIK filter. Set the value of ciks to an array containing that filer's CIK — for example ["0001318605"] for Tesla — and put the term you care about in query, leaving startDate and endDate unset.

The response returns every matching filing or exhibit from that filer over the trailing 30 days inside the filings array, with filedAt confirming each document's filing date.

New EDGAR filings become searchable on the /full-text-search endpoint in less than 60 seconds after they are published on EDGAR. Both the filing body and its exhibits are indexed as part of the same submission, so once the submission is searchable every attachment is matched against query the same way the main document is.

Yes — the /full-text-search endpoint is survivorship-bias free. The index covers every EDGAR filing and exhibit filed since 2001 from both active filers and filers that are no longer active (for example companies that have been delisted, merged away, or otherwise ceased to file). Search results therefore include matching filings from those entities, and each hit carries the filer's CIK (cik) and company name (companyNameLong) so you can identify them regardless of current listing status.

Pagination on the /full-text-search endpoint is driven by the page parameter — each request returns up to 100 hits in filings, and incrementing page by one moves to the next 100. Start with page set to 1, collect the filings array, then issue the same request with page set to 2, 3, and so on, accumulating results as you go.

Stop when either the filings array comes back empty or when you have collected total.value documents — whichever happens first. Note that total.value is capped at 10000 (when total.relation is gte), so for a very broad query you also need to split the search into smaller windows by narrowing startDate/endDate or by filtering on ciks to get past that cap.

To require an exact phrase — including any punctuation it contains — on the /full-text-search endpoint, wrap the whole phrase in double quotes inside query. For example, the value of query should be the phrase In our opinion, except for enclosed in double quotes, which matches documents that contain those words in that order, with the comma in place between opinion and except.

Matching is case-insensitive, and the quoted phrase is treated as a single token sequence, so wildcard asterisks and boolean operators inside the quotes are not interpreted — they are matched literally.

All of these features compose inside a single /full-text-search request. Build the query value as a wildcard stem (for example gas*) followed by two quoted city phrases (Sacramento CA and San Francisco CA) listed as alternatives using the capitalized boolean OR keyword. The wildcard term is required by the implicit AND of space-separated terms, and at least one of the two city phrases must also be present.

Add the form-type filter alongside by setting formTypes to the list of forms you care about, for example ["8-K", "10-Q"]. Date and filer filters compose the same way through startDate/endDate and ciks, and pagination through page works regardless of how complex the query value gets.