The Form DEFS14C Files Dataset is a complete, accession-keyed collection of definitive Schedule 14C information statements filed on EDGAR for corporate actions effected in connection with a special meeting of shareholders. Each record is one EDGAR submission of Form DEFS14C — a definitive (final, non-preliminary) information statement filed under Section 14(c) of the Securities Exchange Act of 1934 and Regulation 14C — packaged as an accession-numbered folder containing a metadata.json header file and the filer-submitted document files. The filer is always the issuer whose securities are registered under Section 12 of the Exchange Act; the form is generated when holders of a majority of voting power have approved a corporate action by written consent and a special meeting accompanies that consent, so non-consenting holders must be informed rather than solicited. The dataset begins on 1 July 1995, when mandatory EDGAR submission was phased in for Schedule 14C, and is delivered as monthly ZIP containers organized by year and year-month.
Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.
Dataset Index JSON API
Download the entire dataset as a single archive file.
Download Entire Dataset:
Download a single container file (e.g. monthly archive) from the dataset.
Download Single Container:
The dataset is restricted strictly to filings whose formType equals "DEFS14C". The closely related preliminary form PRES14C and the amendment forms DEFS14C/A and PRES14C/A are not included; the merger-specific definitive form DEFM14C, the consent-only form DEF 14C, the proxy-track form DEFS14A, and the supplemental DEFA14C are also out of scope and live in their own form-type collections. Each record corresponds one-to-one with an EDGAR accession number such as 0000948830-01-500577, keyed on disk by the eighteen-digit dashless form of that number (for example 000094883001500577). The record unit is the filing as a whole, not an individual exhibit, an extracted section, or a normalized data row.
Form DEFS14C is the definitive information statement that an issuer must distribute to shareholders when corporate action has already been authorized by the written consent of holders of a majority of the voting power, so that a formal proxy solicitation under Section 14(a) is not required, but where Section 14(c) and Regulation 14C nevertheless mandate that the issuer inform non-consenting shareholders of the action — and where that action is being effected in connection with a special meeting rather than purely by non-meeting written consent. The form is filed on Schedule 14C, which incorporates a defined subset of Schedule 14A items by reference. Schedule 14C's required content has remained substantially stable since 1995; the same anchor disclosures — description of the action, voting-securities information, beneficial-ownership table, mandatory no-proxy legend, signature — persist across the full historical window. The dataset is distributed in ZIP container format, with the underlying file types limited to TXT (the filer-submitted SGML-wrapped document files) and JSON (the parsed EDGAR header).
A single record is one complete EDGAR submission of Form DEFS14C, packaged as an accession-numbered folder that holds a metadata.json header file alongside the filer-submitted document files. Each record corresponds one-to-one with an EDGAR accession number such as 0000948830-01-500577, and is keyed on disk by the eighteen-digit dashless form of that number.
The body of a DEFS14C is dominated by the legend "WE ARE NOT ASKING YOU FOR A PROXY AND YOU ARE REQUESTED NOT TO SEND US A PROXY," required boilerplate that distinguishes the document from a proxy statement. Substantive content typically includes the issuer's name, address, and contact information; an introductory statement that the action was approved by written consent in lieu of a meeting; a description of the corporate action being effected (most commonly a charter amendment, name change, reverse or forward stock split, increase in authorized shares, recapitalization, reincorporation, equity compensation plan adoption or amendment, or a Rule 13e-3 going-private transaction); the record date and the number of voting securities outstanding; a beneficial-ownership table for directors, officers, and 5%+ holders; identification of the consenting majority and the size of its holdings; any item-specific disclosures pulled into Schedule 14C from Schedule 14A (interest of certain persons in matters acted upon, financial information where the action requires it, dissenters' or appraisal rights, and similar); and a closing signature by an authorized officer of the issuer.
The dataset is distributed as a hierarchy of monthly ZIP containers, organized by year and year-month. A container key takes the form YYYY/YYYY-MM.zip (for example 2001/2001-12.zip). Inside the ZIP, a single year-month folder (e.g. 2001-12/) holds one subfolder per filing, each named with the eighteen-digit dashless accession number. Each accession folder contains exactly two kinds of files:
metadata.json file containing the parsed EDGAR header and a manifest of documents in the submission. This file is always present..txt for older plain-text filings, or .htm/.html for newer HTML-based filings), occasionally accompanied by sibling files for exhibits.The file-types found in the dataset are TXT and JSON; image files (GIF, JPG, and other GRAPHIC-type entries that may have been part of the original EDGAR submission) are excluded. Document filenames are chosen by the filer (odyssey.txt, for example) rather than by a fixed convention, so downstream consumers must read the manifest in metadata.json rather than assume a deterministic filename. The accession folder name uses the dashless eighteen-digit form, while the accessionNo field inside metadata.json uses the canonical dashed form (0000948830-01-500577); both refer to the same filing and are useful for joining the on-disk path to header metadata.
metadata.json is a flat JSON object that mirrors the parsed EDGAR submission header. Its top-level fields are:
formType — always the string "DEFS14C" for records in this dataset.accessionNo — the canonical dashed accession number, e.g. "0000948830-01-500577".filedAt — ISO-8601 timestamp with timezone offset for when the filing was accepted by EDGAR, e.g. "2001-12-21T00:00:00-05:00".periodOfReport — the date the filing pertains to, typically the effective date of the corporate action or the record date for the information statement, e.g. "2001-12-05".description — a human-readable filing description such as "Form DEFS14C - Definitive information statement for special meeting".linkToFilingDetails — the EDGAR URL of the primary document.linkToTxt — the EDGAR URL of the merged complete-submission text file.linkToHtml — the EDGAR URL of the filing index page (-index.htm).linkToXbrl — empty string for DEFS14C; the form is not subject to XBRL tagging.dataFiles — empty array for DEFS14C; no structured data files are associated with this form type.seriesAndClassesContractsInformation — generally empty; populated only for fund-style filers that use EDGAR's series/class machinery.id — an internal hex identifier (md5-style) for the record, e.g. "c7c41b5ad924fee2799e8a3754e135d6".documentFormatFiles — array of one entry per document in the submission (see below).entities — array of one entry per filer / co-filer (see below).Each documentFormatFiles[] element describes one document with the fields sequence (numeric position within the submission as a string, e.g. "1"), size (byte length as a string, e.g. "10509"), documentUrl (the EDGAR URL), description (filer-supplied document title), and type (the EDGAR document-type label such as "DEFS14C" for the primary document or an exhibit code like "EX-99.1"). EDGAR additionally emits a "complete submission text file" pseudo-entry covering the merged submission; this row uses a single space " " for both sequence and type and points at the <accession>.txt URL on EDGAR. The merged file itself is not redistributed inside the ZIP — only the per-document files are packaged.
Each entities[] element describes one party to the filing as parsed from the EDGAR header. Fields include companyName with role suffix in parentheses (e.g. "ODYSSEY MARINE EXPLORATION INC (Filer)"), cik, irsNo, fileNo, filmNo, stateOfIncorporation (two-letter code), fiscalYearEnd (MMDD, e.g. "0228"), act (the Exchange Act, "34", for Schedule 14C filings), sic (SIC code with text description, e.g. "7389 Services-Business Services, NEC"), type (the role-specific filing-type label, normally "DEFS14C"), and tickers (array of associated trading symbols, possibly empty). The array is plural because Schedule 14C filings can list co-filers — most commonly the issuer alone, but occasionally a parent and subsidiary or multiple registrants involved in the transaction.
The substantive content of the information statement lives in the document file(s) referenced by documentFormatFiles[]. In nearly all DEFS14C filings the primary document is a single SGML-wrapped text file using the standard EDGAR document envelope:
1
<DOCUMENT>
2
<TYPE>DEFS14C
3
<SEQUENCE>1
4
<FILENAME>odyssey.txt
5
<DESCRIPTION>ODYSSEY MARINE - DEFINITIVE INFORMATION STATEMENT
6
<TEXT>
7
... body of the information statement ...
8
</TEXT>
9
</DOCUMENT>
The header tags (<TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>) are the standard document-level metadata that EDGAR places ahead of the body; the <TEXT> block holds the rendered information statement. In older filings the body is plain ASCII with column-aligned tables and fixed-width formatting; in newer filings the <TEXT> block contains HTML markup with embedded <table> elements and inline styles, in which case the document file may carry an .htm/.html extension while remaining wrapped in the same SGML envelope.
Where a filing carries amendments or exhibits, additional sibling documents appear in the same accession folder, each as its own SGML-wrapped file with its own <TYPE> tag. Common ancillary types include EX-99.1 and similar exhibit codes for materials referenced by Schedule 14C — for example, copies of charter amendments, fairness opinions, equity-plan documents, or merger agreements. These appear as separate document files rather than being concatenated into the primary information statement. Image exhibits (graphics, scanned signatures, logos) are stripped from the dataset, so any GRAPHIC-type entries that EDGAR carried are absent from the on-disk record even when their existence is implied by the original submission.
Within the <TEXT> block, a typical DEFS14C body proceeds in roughly the following order:
Each record packages the parsed EDGAR header (as metadata.json) together with the filer-submitted text/HTML document files for the information statement and any non-image exhibits. The merged complete-submission text file — EDGAR's concatenated .txt rendering of the entire submission — is referenced by URL in metadata.json (and also surfaces as a row in documentFormatFiles[] with blank sequence and type), but it is not duplicated inside the ZIP.
.txt file is not packaged.linkToXbrl is empty and dataFiles is an empty array; these fields exist for schema consistency rather than because the form carries XBRL content.Content-side variation across the historical window is driven by the nature of the underlying action: a Rule 13e-3 going-private transaction layers in extensive Schedule 13E-3 disclosures and fairness materials, and an equity-plan action introduces plan-benefits tables and the plan document itself as an exhibit. The presentation format has evolved meaningfully. Filings from the late 1990s and early 2000s are predominantly plain ASCII inside the SGML <DOCUMENT> wrapper, with column-aligned tables drawn in monospaced text. From the mid-2000s onward, filings progressively shifted to HTML inside the same SGML wrapper, with <TEXT> blocks containing real <table> markup, inline styles, and embedded structural HTML — though the outer EDGAR document envelope and the metadata.json schema remain identical. DEFS14C is not subject to XBRL tagging requirements, so the structured-tagging era that reshaped Form 10-K and Form 10-Q filings did not alter this form's content layer.
accessionNo field (canonical dashed form) refer to the same filing; treat the folder name as the join key into metadata.json.documentFormatFiles[] to identify the primary information statement and any exhibits, rather than relying on filename patterns or extensions.documentFormatFiles[] array typically contains one row per real document plus one row for the EDGAR "complete submission text file" pseudo-entry. The pseudo-entry is recognizable by its blank sequence and type (both " ") and by pointing at the <accession>.txt URL on EDGAR. That pseudo-entry's target file is not packaged inside the ZIP.entities[] array can hold more than one party. The role suffix in parentheses on companyName ((Filer), (Subject), etc.) disambiguates each party's role when joining or grouping by issuer.seriesAndClassesContractsInformation, linkToXbrl, and dataFiles are reliably empty for DEFS14C records and should be treated as schema slots rather than informative fields.<DOCUMENT> boundaries, capture the header tags, and read between <TEXT> and </TEXT> to obtain the body. The body itself may then require either monospaced-text parsing (older filings) or HTML parsing (newer filings).Each record in the Form DEFS14C Files Dataset is a definitive information statement on Schedule 14C filed on EDGAR by an issuer (the registrant itself) whose securities are registered under Section 12 of the Securities Exchange Act of 1934. The "S" in the form code denotes that the underlying corporate action is being effected in connection with a special meeting of security holders, distinguishing it from the more common DEF 14C, which typically covers annual-meeting-related actions or pure written-consent actions taken without any meeting.
The filer is always the issuer. Controlling shareholders, acquirers, directors, and officers may be described in the information statement, but they are not filers of Schedule 14C. Their separate disclosure obligations, where applicable, run through Schedule 13D/13G, Schedule 13E-3, or Section 16 forms.
Out of scope: foreign private issuers (exempt from Regulation 14C under Rule 3a12-3), Section 15(d)-only filers, voluntary filers, and issuers without Section 12 registration. Open-end funds and most registered investment companies use the N-series forms instead.
The trigger is event-driven, not periodic. A DEFS14C is generated when:
In practice, a DEFS14C appears on EDGAR at least 20 days before the action is consummated, and at least 10 days after any required PRE 14C.
DEFS14C sits inside a tight cluster of Section 14 shareholder-communication filings. Its closest neighbors are the other Schedule 14C variants, the parallel Schedule 14A proxy filings, the Schedule 13E-3 going-private overlay, and event-driven Form 8-K reports. Boundaries between them turn on five axes: preliminary vs definitive, consent vs proxy solicitation, special meeting vs no meeting, primary vs supplemental, and shareholder communication vs market disclosure.
Both are definitive Regulation 14C information statements used when majority holders have already approved an action by written consent and no proxies are solicited. The split is the meeting trigger: DEF 14C is filed when the action is merely noticed to non-consenting holders with no meeting; DEFS14C is filed when a special meeting accompanies the consent. DEFS14C therefore adds meeting logistics (date, place, agenda) on top of the standard 14C disclosures. DEF 14C is the much larger population; DEFS14C is the special-meeting carve-out.
PRE 14C is the preliminary version reviewed by SEC staff at least ten calendar days before mailing; DEFS14C is the definitive version actually distributed to shareholders. Textually the two can be near-identical, but only DEFS14C is the operative communication. Use PRE 14C to study staff comment cycles and pre-mailing revisions; use DEFS14C to study what shareholders received. Note that PRE 14C covers both meeting and no-meeting preliminary 14C filings, so it is the upstream pair for both DEF 14C and DEFS14C.
DEFM14C is the definitive 14C information statement specifically for merger transactions; DEFS14C is the special-meeting variant for any qualifying consent-authorized action. The two overlap when a merger also involves a special meeting, and the choice between labels is partly filer election. DEFM14C content is merger-specific (background, fairness opinions, merger agreement, appraisal rights); DEFS14C is structurally agnostic to action type and defined solely by the special-meeting trigger. Non-merger special-meeting actions appear only under DEFS14C.
DEFA14C captures additional definitive 14C materials filed alongside a primary information statement: press releases, investor presentations, Q&A scripts, follow-on letters. It does not stand alone and accretes around a DEF 14C, DEFM14C, or DEFS14C. DEFS14C is the primary information statement itself. To reconstruct the full record for a special-meeting transaction, read the DEFS14C together with any DEFA14C supplements from the same window.
DEFS14A and DEFS14C are mirror filings for special meetings under different Exchange Act sections. DEFS14A is filed under Section 14(a) when proxies are actively being solicited and includes a proxy card and full solicitation apparatus. DEFS14C is filed under Section 14(c) when consent has already been obtained from majority holders and no solicitation occurs; there is no proxy card. Disclosure content overlaps heavily (action description, record date, principal holders, exhibits), but the determining question is whether votes are still being collected.
Form 8-K is an event-driven current report under Section 13 or 15(d), filed promptly to disclose specified material events to the market (mergers, charter amendments, changes in control, director departures, asset sales). DEFS14C is a shareholder communication under Section 14(c) for an action approved by written consent and tied to a special meeting. The same transaction routinely generates both: an 8-K announces the consent or signing to the market on a 4-business-day clock, while the DEFS14C provides the formal information statement to holders. The 8-K is short and item-coded; DEFS14C carries the full Schedule 14C disclosure apparatus.
Schedule 13E-3 is the transaction statement required under Rule 13e-3 for going-private transactions by an issuer or affiliate. It is an overlay, not a substitute. When a going-private transaction is communicated through Regulation 14C with a special meeting, the issuer files both a DEFS14C and a Schedule 13E-3, often on a combined cover. Schedule 13E-3 adds going-private-specific items (purposes, alternatives, fairness determinations, reports and opinions, related-party interests) absent from Regulation 14C. In this dataset, the 14C information-statement content is captured directly; the 13E-3 content, when filed jointly, typically appears as embedded or combined disclosure but remains governed by its own regime.
DEFS14C/A is the amendment form for a previously filed DEFS14C, used to correct errors, update meeting details, or respond to post-definitive staff feedback. The amendment is a separate EDGAR accession and does not replace the original. Final operative disclosure must be reconstructed from the DEFS14C plus any DEFS14C/A that follows. This dataset is scoped to the DEFS14C form type itself; amendments flow through the corresponding amendment dataset.
DEFS14C is defined by the intersection of three conditions: definitive (not preliminary), Section 14(c) consent regime (no proxy solicitation), and a special meeting of shareholders. Drop the special meeting and it becomes DEF 14C; flip definitive to preliminary and it becomes PRE 14C; switch consent to solicitation and it becomes DEFS14A; restrict to a merger and it may file as DEFM14C; layer on a going-private transaction and Schedule 13E-3 attaches; treat the event as market disclosure rather than holder communication and it becomes an 8-K. Supplements (DEFA14C) and amendments (DEFS14C/A) extend the record but do not replace the DEFS14C itself when the research question concerns the formal special-meeting information statement delivered under Regulation 14C.
DEFS14C filings document corporate actions already authorized by majority written consent, so the dataset clusters around controlled companies, going-private steps, charter amendments, reverse splits, and parent-subsidiary roll-ups. A narrow set of professional users works with these records, each focused on different sections: cover-page metadata, the description of the action, principal-holder tables, record-date mechanics, appraisal-rights notices, and exhibits.
Transactional lawyers drafting 14C statements for controlled-company clients use the corpus as a precedent library. Because 14C is rarer than 14A and follows different mechanics (no solicitation, Rule 14c-2 twenty-day waiting period, distinct cover-page certifications), counsel pull comparable filings to calibrate language for the action description, board-process narrative, fairness discussion, and dissenters'-rights notice. They search by transaction archetype (reverse split, authorized-share increase, charter amendment, asset sale, name change, going-private merger) and reuse the Schedule 14C item responses and exhibits (consent forms, charter amendments, fairness materials).
Governance teams at controlled issuers, holding companies, and majority-owned subsidiaries benchmark written-consent practice across peers with similar capital structures. They study how comparable filers describe the consenting block, document the record date, calculate voting power, and disclose dual-class arrangements. The principal-holder table, voting-securities description, and consent-procurement narrative drive internal templates, board memos on Section 14(c) timing, and policy notes for handling future consent-driven actions.
Deal lawyers, financial advisors, and integration teams working on squeeze-outs, short-form mergers, and parent-subsidiary roll-ups focus on DEFS14C filings that overlay with Schedule 13E-3. When a controller uses written consent for a going-private transaction, the 14C carries the 13E-3 disclosure burden: purposes and reasons, fairness determination, financial-advisor reports, and appraisal mechanics. Advisors mine the dataset for comparable structures, filing-to-effectiveness timelines, fairness-opinion summaries in exhibits, and the specific language supporting controller fairness determinations.
Analysts treat DEFS14C filings as deal-confirmation events. Since consent is already executed at definitive filing, the document signals that the action will close after the Rule 14c-2 waiting period. Desks extract the record date, effective date, exchange ratio or cash-out price, and share-conversion mechanics to size positions, backtest historical consent-driven events, and build watchlists of controlled-company structures likely to produce future 14C events.
Counsel evaluating fiduciary-duty challenges to controlled-company actions, freeze-outs, and going-private mergers use the dataset to study disclosure quality. They examine whether the statement adequately describes the controller's interest, the board's process, special-committee negotiation, the fairness analysis, and the appraisal notice. Comparing a challenged filing against historical peers supports arguments about omitted facts or boilerplate disclosure. The principal-holder section, board-process description, and appraisal language are the load-bearing inputs.
Proxy advisors and stewardship groups benchmark 14C disclosures against 14A peers when scoring controlled-company governance. Because no vote is solicited, the question is whether disclosure quality matches what a contested electorate would have received. Teams compare the action description, board process, related-party treatment, and equity-plan or charter-amendment exhibits to inform house views on dual-class and controlled-company structures.
Corporate-finance and law-and-economics researchers studying minority-shareholder protection, controlled-company behavior, and consent-based decision-making use the corpus to build event samples. DEFS14C is an unambiguous marker of controller-driven action, useful for studying squeeze-out premia, charter-amendment frequency, dual-class governance, and disclosure differentials between 14A and 14C events. Structured metadata supports panel construction; the information statement body supports textual analysis of disclosure tone, length, and content.
Engineers ingest the EDGAR submission packages to feed entity resolution, corporate-action monitoring, and event-tagging systems. The metadata JSON supplies accession identifiers, CIK linkage, and filer attributes; the TXT documents supply the raw statement and exhibits for parsing into structured fields (record date, meeting date, action type, voting-securities table, exhibit inventory). The bounded, well-typed corpus also serves as a training set for classifiers that distinguish 14C from 14A, flag going-private overlays, and extract effective dates.
Teams building retrieval-augmented generation systems and disclosure-summarization tools use DEFS14C as targeted training and evaluation data for the narrow subdomain of consent-based corporate actions. Paired metadata and full text let developers test extraction of structured fields (issuer name, CIK, action type, record date, mailing date) and benchmark summarization on dense legal sections such as appraisal notices, fairness determinations, and dissenters'-rights mechanics.
DEFS14C users cluster around controlled-company governance, consent-based corporate actions, and the legal mechanics distinguishing information statements from proxy solicitations. Drafting counsel and in-house teams use the corpus as precedent; deal advisors and litigators study controller-driven transactions; event-driven desks time closings; researchers and engineers treat the corpus as a clean, bounded sample. Across roles, the same record components (action description, principal-holder table, record and effective dates, appraisal notice, exhibits) drive most workflows.
Concrete workflows the Form DEFS14C Files Dataset supports.
Building a precedent library for consent-driven action descriptions. Transactional counsel drafting a special-meeting information statement (reverse split, authorized-share increase, charter amendment, name change, asset sale) pull DEFS14C filings filtered by entities[].sic and action archetype, then read the body of the primary <TYPE>DEFS14C document to compare board-process narratives, Schedule 14C item responses, and dissenters' rights language. Exhibit documents (EX-99.1 and similar) supply boilerplate-quality charter amendments, consent forms, and fairness materials for reuse.
Constructing an event sample of controller-driven going-private transactions. Researchers and M&A advisors filter the corpus for DEFS14C filings whose body text triggers Rule 13e-3 disclosure (purposes and reasons, fairness determination, financial-advisor reports). The filing-level filedAt, periodOfReport, and parsed effective dates inside the information statement build a panel of controller-driven freeze-outs, joined to issuer identifiers via entities[].cik for matching to market data and ownership history.
Timing closings for event-driven and merger-arbitrage desks. Because a DEFS14C signals that majority consent is already executed, desks treat each new accession as a deal-confirmation event. Pipelines monitor the monthly YYYY/YYYY-MM.zip containers for new filings, extract the record date, meeting date, exchange ratio or cash-out price, and share-conversion mechanics from the body, and feed the Rule 14c-2 twenty-day waiting period into closing-date estimates and position sizing.
Auditing controlled-company disclosure quality for stewardship and litigation. Proxy advisors and plaintiffs' counsel compare a challenged DEFS14C against historical peers on the principal-holder table, controller-interest disclosure, special-committee narrative, and appraisal notice. The beneficial-ownership and consenting-majority sections, paired with entities[].stateOfIncorporation and SIC code, support like-for-like benchmarking on governance scores or disclosure-omission claims.
Training and evaluating extraction models for narrow consent-based filings. RegTech and LLM teams pair metadata.json (issuer name, CIK, accession, filing date) with the SGML-wrapped primary document to train classifiers that separate DEFS14C from DEF 14C, DEFS14A, and DEFM14C, and to extract structured fields — record date, mailing date, action type, voting-securities counts, exhibit inventory. The bounded form-type scope and consistent envelope make the corpus a clean evaluation set for summarization of fairness determinations and appraisal mechanics.
Mapping parent-subsidiary roll-ups and dual-class structures. Engineers iterate the entities[] array across records to find filings with multiple co-filers (parent plus majority-owned subsidiary, or multiple registrants in a short-form merger), then link issuer CIKs into a graph of controlled-company relationships. Combined with the action description in the body, this produces a longitudinal map of squeeze-outs, reincorporations, and recapitalizations executed via written consent.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-defs14c-files.json
This endpoint returns dataset metadata (name, description, last update timestamp, earliest sample date, total records, total size, form types covered, container format, and content file types), the download URL for the full dataset archive, and the list of individual container files with per-container size, record count, updated timestamp, and download URL. Use it to monitor which containers were refreshed in the most recent update run and decide which containers to pull on a day-by-day basis. This endpoint does not require an API key.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6a15-a33d-bf0b38772f23",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-defs14c-files.zip",
4
"name": "Form DEFS14C Files Dataset",
5
"updatedAt": "2026-04-16T08:25:22.951Z",
6
"earliestSampleDate": "1995-07-01",
7
"totalRecords": 91,
8
"totalSize": 2539311,
9
"formTypes": ["DEFS14C"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["TXT", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-defs14c-files/2026/2026-04.zip",
15
"key": "2026/2026-04.zip",
16
"size": 312844,
17
"records": 4,
18
"updatedAt": "2026-04-16T08:25:22.951Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-defs14c-files.zip?token=YOUR_API_KEY
Downloads the complete dataset as a single ZIP archive covering all DEFS14C filings from July 1995 to the present. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-defs14c-files/2026/2026-04.zip?token=YOUR_API_KEY
Containers are organized by year and month (<year>/<year>-<month>.zip), allowing you to download a single monthly archive instead of the full dataset. The exact list of available containers, including their key paths and downloadUrl values, is provided in the dataset index JSON above. This endpoint requires an API key.
The dataset covers Form DEFS14C — the definitive Schedule 14C information statement filed under Section 14(c) of the Securities Exchange Act of 1934 and Regulation 14C, used when a corporate action approved by majority written consent is being effected in connection with a special meeting of shareholders. The dataset is restricted to formType == "DEFS14C"; preliminary (PRES14C), amendment (DEFS14C/A), no-meeting (DEF 14C), merger-specific (DEFM14C), and proxy-track (DEFS14A) variants are excluded.
One record is one complete EDGAR submission of Form DEFS14C, packaged as an accession-numbered folder containing a single metadata.json header file alongside the filer-submitted document files. Each record corresponds one-to-one with an EDGAR accession number such as 0000948830-01-500577, keyed on disk by the eighteen-digit dashless form of that number.
The filer is always the issuer — a domestic operating company (or, occasionally, a closed-end investment company) whose securities are registered under Section 12(b) or 12(g) of the Exchange Act. Smaller reporting companies and controlled issuers dominate the population because the Section 14(c) route requires a controlling shareholder or insider block capable of approving action by written consent. Foreign private issuers, Section 15(d)-only filers, voluntary filers, and open-end funds are out of scope.
The trigger is event-driven, not periodic. Under Rule 14c-2, the definitive information statement must be filed on or before the date it is first sent to holders, and must be sent at least 20 calendar days before the earliest date the corporate action may be taken — typically the special meeting at which the action is effected. Where preliminary review applies, a PRE 14C must be filed at least 10 calendar days before the definitive copies are first mailed.
The dataset begins on 1 July 1995, when mandatory EDGAR submission was phased in for Schedule 14C, and runs through the present. Earlier paper-format equivalents predate electronic filing and are not in EDGAR.
Records are delivered as monthly ZIP containers keyed YYYY/YYYY-MM.zip. Inside each accession folder, the file types are TXT (the SGML-wrapped primary information statement and any non-image exhibits, sometimes carrying .htm/.html extensions for HTML-bodied filings) and JSON (the parsed EDGAR header in metadata.json). Image files (GIF, JPG, and other GRAPHIC-type entries) and the merged complete-submission text file are excluded.
Both cover definitive Regulation 14C information statements filed when majority holders have already approved an action by written consent and no proxies are solicited. The split is the meeting trigger: DEF 14C is filed when the action is merely noticed to non-consenting holders with no meeting, while DEFS14C is filed when a special meeting accompanies the consent and therefore adds meeting logistics (date, place, agenda) on top of the standard 14C disclosures. DEF 14C is the much larger population; DEFS14C is the special-meeting carve-out.
No. DEFS14C is not subject to XBRL tagging requirements, which is why the linkToXbrl field is an empty string and dataFiles is an empty array on every record. These fields exist for schema consistency across SEC datasets rather than because the form carries inline XBRL content.