The Form 35-APP Files Dataset is a closed historical archive of every EDGAR submission of Form 35-APP and its amendment Form 35-APP/A — the residual application channel under Rule 20(e) of the Public Utility Holding Company Act of 1935 ("PUHCA 1935"). Each record represents one accession-numbered EDGAR submission filed by a registered public utility holding company or one of its subsidiaries to give the Securities and Exchange Commission notice of an intra-system or related-party transaction that fell outside the scope of standardized PUHCA application forms (such as U-1, U5S, U-9C-3, or U-13-1). The dataset spans the entire EDGAR era of PUHCA filings, from October 1995 through the repeal of PUHCA 1935 on February 8, 2006 under Title XII of the Energy Policy Act of 2005, and is therefore a finite, non-growing corpus rather than an ongoing time series. Records are distributed as monthly ZIP containers, with each accession's parsed metadata.json header packaged alongside the original ASCII/SGML document attachments from the EDGAR submission.
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:
Form 35-APP is the EDGAR form designated "Statement on proposed transaction where no application is prescribed [Rule 20(e)]" under PUHCA 1935. Registered public utility holding companies and their subsidiaries used it to notify the Commission of intra-system or related-party transactions that fell outside the scope of standardized PUHCA application forms and that the filer believed could be effected without obtaining a substantive Commission order. The form's title invokes Rule 20(e) of the General Rules and Regulations under PUHCA — the rule that contemplates statements of proposed transactions for which no other form of application is prescribed. The 35-APP/A variant is the amendment counterpart, used to correct, supplement, or supersede a previously filed 35-APP.
In practice the documentary content carried by 35-APP filings is broader than a literal Rule 20(e) "no-application-prescribed" statement: filers also use this submission slot to deliver the certificates, "past tense" opinions of counsel, and post-transaction reports required by Rule 24 (which governs reports on transactions consummated under prior PUHCA orders) and other operative PUHCA rules. The bodies of 35-APP documents therefore frequently caption themselves as Rule 24 certificates or Rule 24 reports, even though the EDGAR form code is 35-APP. The content is uniformly narrative, legal, and prose-driven rather than financial-statement-driven: identification of the parties and their PUHCA status, description of the transaction, the cited rule basis, supporting exhibits, signatures, and an opinion of counsel.
PUHCA 1935 was repealed by the Energy Policy Act of 2005, with the repeal taking effect on February 8, 2006, and Form 35-APP became obsolete at that point. The dataset's accession universe therefore spans the EDGAR era of PUHCA filings only — from October 1995 through the form's discontinuation in early 2006 — and is intrinsically small and non-growing. The dataset is distributed as monthly ZIP containers under form-35app-files/<YYYY>/<YYYY>-MM.zip, each containing the per-accession sub-folders that are the unit of analysis.
A single record in the Form 35-APP Files Dataset is one EDGAR submission of either a Form 35-APP statement or a Form 35-APP/A amendment, materialized on disk as one accession-numbered folder. The folder name is the 18-digit EDGAR accession number with dashes stripped (for example 000002342601500021/ for accession 0000023426-01-500021). Inside that folder the dataset places a parsed metadata.json header file plus every non-image document attachment that accompanied the original EDGAR submission, preserved in its original ASCII/SGML form. Records are grouped into monthly ZIP containers under form-35app-files/<YYYY>/<YYYY>-MM.zip, each of which decompresses to a single top-level folder named after the month; the unit of analysis, however, is always the per-accession sub-folder, not the container.
Each record folder consists of two layers:
metadata.json, that captures the EDGAR submission header in JSON form: form type, accession identifier, filing date, links to canonical EDGAR copies, the list of submitted documents, and the filer/registrant entity blocks..txt file that retains the EDGAR SGML <DOCUMENT> envelope around an ASCII text body. These are the substantive papers of the filing — the principal 35-APP statement or Rule 24 certificate, the opinion of counsel, board resolutions, and any other text material the filer attached at submission.There is no separate cover-page artifact, no rolled-up "complete submission text file" extracted to disk, and no XBRL/schema/extension files. The dataset preserves only the per-document attachments plus the parsed JSON header. Image attachments (GIF, JPEG, scanned graphics, signature-page scans) are excluded by design.
Every document file in a record is a plain-ASCII EDGAR SGML wrapper of the form:
1
<DOCUMENT>
2
<TYPE>35-APP
3
<SEQUENCE>1
4
<FILENAME>rule24102301.txt
5
<DESCRIPTION>RULE24102301
6
<TEXT>
7
UNITED STATES
8
SECURITIES AND EXCHANGE COMMISSION
9
Washington, D.C. 20549
10
... narrative body, signatures, opinion of counsel ...
11
</TEXT>
12
</DOCUMENT>
The relevant conventions are:
<TYPE> mirrors the form type or exhibit type (35-APP for the principal statement, an exhibit-type tag for ancillary papers).<SEQUENCE> is a 1-based ordering within the submission.<FILENAME> matches the file's on-disk name.<DESCRIPTION> echoes the human-readable description carried in metadata.json.documentFormatFiles[].description.<TEXT> and </TEXT> is plain ASCII, not HTML; tabular content, where present, is laid out in fixed-column ASCII.<PAGE> tokens on their own lines, which downstream consumers should treat as soft form-feeds rather than markup.The narrative typically opens with the SEC caption block ("United States / Securities and Exchange Commission / Washington, D.C. 20549"), followed by a docket caption identifying the application or proceeding (often by underlying File No., e.g. File No. 70-9905), the rule under which the certificate or statement is filed, and the names of the applicants. From there it identifies the filer and any co-applicants, recites the PUHCA status of each party, describes the transaction or post-transaction state of facts, cites the operative rule and any related Commission release (e.g. "Public Utility Holding Company Act Release No. 27453"), and closes with a signature block. An opinion of counsel — frequently the Rule 24 "past tense" opinion — is most often appended to the same document file rather than uploaded as a separate <DOCUMENT>.
The metadata.json file is the parsed representation of the EDGAR submission header. The fields present in the dataset are:
formType — either 35-APP or 35-APP/A. The canonical EDGAR form code.accessionNo — the dashed 18-character EDGAR accession number (e.g. 0000023426-01-500021); the on-disk folder name is the same string with dashes removed.linkToFilingDetails — canonical EDGAR URL pointing at the filing's primary document detail page.description — the human-readable form description, which for this dataset reads "Form 35-APP — Statement on proposed transaction where no application is prescribed [Rule 20(e)]".linkToTxt — URL for the rolled-up "complete submission text file" on EDGAR (<accessionNo>.txt). The file itself is not extracted into the record folder.filedAt — ISO-8601 timestamp with timezone offset (e.g. 2001-10-24T00:00:00-04:00). Only the calendar date is meaningful: the time component is always 00:00:00 because EDGAR did not record sub-day filing times for this form during its active period.documentFormatFiles[] — an ordered array describing each submitted document, plus a trailing entry for the rolled-up complete-submission file. Each entry carries sequence (string, 1-based; the rolled-up entry uses a single space " " rather than a number), size (file size in bytes, as a string), documentUrl (canonical EDGAR URL), description (free-text label assigned by the filer, often an upper-case echo of the filename root such as RULE24102301, plus the literal label Complete submission text file for the rolled-up entry), and type (the document's <TYPE> tag, mirroring the form type for the principal document, an exhibit type for ancillary documents, and a single space " " for the rolled-up entry).entities[] — one or more filer/registrant blocks. Fields commonly populated are companyName (with a parenthetical role suffix such as (Filer)), cik, irsNo, fileNo (the PUHCA file number, conventionally beginning with 031- for 35-APP filers), filmNo, sic (industry code together with its SEC label, e.g. 4911 Electric Services), stateOfIncorporation (two-letter state code), fiscalYearEnd (an MMDD string such as 1231), act (the literal string 35, denoting PUHCA 1935), type (mirrors formType), and a tickers[] array enumerating the entity's outstanding ticker symbols. Because 35-APP filers are typically large operating utilities with multiple classes of preferred stock, a single filer block can list many tickers spanning the various preferred-stock series, even though the filing itself has nothing to do with equity trading.id — opaque 32-character hexadecimal identifier assigned per record.seriesAndClassesContractsInformation[] — present in the schema but always an empty array for this dataset; this is a mutual-fund concept that does not apply to PUHCA filings.linkToHtml — canonical EDGAR URL for the filing's HTML index page (-index.htm).linkToXbrl — present in the schema but always an empty string for this dataset.dataFiles[] — present in the schema but always empty.Although the dataset preserves Form 35-APP as wrapped SGML/ASCII text rather than as a fielded form, the narrative within the principal document tends to follow a recognizable order:
File No. 70-9905), the form-of-application reference (e.g. "Application of Northeast Utilities on Form U-1"), and the operative rule under which the certificate or statement is filed (often "Rule 24" or "Rule 20(e)").<DOCUMENT> blocks.<PAGE> marker. For Rule 24 certificates this is the "past tense" opinion of counsel addressed to the Commission, opining on corporate authority, valid issuance of relevant securities, and compliance with applicable state and federal law.Where additional exhibits do appear as separate <DOCUMENT> envelopes, each is its own file in the record folder with its own <TYPE>, <SEQUENCE>, <FILENAME>, and <DESCRIPTION> header.
A 35-APP/A record is structurally identical to a 35-APP record — same folder layout, same metadata.json schema, same SGML document envelope — but its formType is 35-APP/A. The narrative body of an amendment typically opens with a recital identifying the prior 35-APP being amended (by accession number or by PUHCA file number) and then either restates the underlying statement in full or supplies only the changed pages or paragraphs. Amendments do not supersede or remove the prior record from the dataset; both the original 35-APP and any 35-APP/A continuations are present as independent accession folders.
Within each record folder, the dataset includes:
metadata.json.<DOCUMENT> envelope and its sub-tags (<TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>, <TEXT>), so that filename, description, and document type can be recovered without re-fetching the EDGAR copy.The dataset deliberately omits:
<accessionNo>.txt) that EDGAR exposes for each submission. That artifact is referenced from documentFormatFiles[] and from linkToTxt for traceability but is not extracted to disk; only the individual per-document .txt files are.linkToXbrl and dataFiles[] are correspondingly empty in every record.Form 35-APP's content requirements were essentially stable across its EDGAR lifetime. Rule 20(e) and the form's instructions were not materially amended between October 1995 and the form's discontinuation, so the parties / statutory-analysis / exhibits / signature / opinion sequence and the typical exhibit set remained consistent. The single material structural event affecting the form is its termination: the Energy Policy Act of 2005 repealed PUHCA 1935 effective February 8, 2006, after which Form 35-APP was retired and no further 35-APP or 35-APP/A submissions were accepted on EDGAR. The dataset therefore has a hard right boundary at early 2006 and a finite total record count rather than a growing time series.
Form 35-APP was an ASCII/SGML form throughout its EDGAR existence. EDGAR's optional HTML filing regime, introduced in the late 1990s, was used inconsistently for PUHCA forms and did not displace plain-text submission for 35-APP; the form was retired before EDGAR's later HTML and inline-XBRL mandates would have applied. Document bodies in this dataset are therefore uniformly ASCII text wrapped in the EDGAR SGML <DOCUMENT> envelope, with <PAGE> markers as the only intra-body structural device.
metadata.json.accessionNo carries the dashed canonical form. Any join between filesystem layout and metadata must normalize the punctuation.documentFormatFiles[].sequence is typed as a string and can take the value " " (a single space) for the rolled-up complete-submission entry; the same is true of the type field on that entry. Integer parsing of sequence must tolerate whitespace and skip the trailing pseudo-document.documentFormatFiles[] entry pointing to the complete submission text file does not correspond to any file on disk; only entries whose documentUrl resolves to a per-document filename will have a counterpart in the record folder.entities[].tickers reflects the filer's full universe of outstanding equity tickers (often dominated by preferred-stock series for utility filers) and is not specific to the transaction described in the filing; it should not be treated as a transaction-level identifier.35-APP document rather than uploading separate <DOCUMENT> blocks, so the count of .txt files in a folder is a poor proxy for the number of substantive exhibits.accessionNo, fileNo, filmNo, and id. Deduplication, where appropriate, must be performed on document content rather than on accession identifiers.filedAt carries an ISO-8601 timestamp but the time portion is always midnight in the filer's offset; only the date should be used for chronological analysis.metadata.json together with the SGML <DOCUMENT> header sub-tags.35-APP/A) coexist with their underlying 35-APP records, reconstructing the full state of a proposed transaction may require collating an original record with one or more amendment records by filer CIK, PUHCA file number, and chronology.Form 35-APP filers are limited to two related groups inside a PUHCA 1935 registered system:
The legal filer is the registered system entity signing the application. Counterparties, lenders, joint-venture partners, and other affiliated participants in the underlying transaction appear in the filing but are not themselves the 35-APP filer.
During the EDGAR era, the eligible population was small — registered systems such as American Electric Power, Southern Company, Entergy, New England Electric System, Allegheny Energy, GPU, Cinergy, and Northeast Utilities, together with their subsidiaries. Section 3 exempt holding companies, intrastate utilities, independent power producers, and stand-alone investor-owned utilities not controlled by a registered holding company had no obligation to file Form 35-APP.
Form 35-APP is event-driven, not periodic. The trigger is a proposed transaction by a registered holding company or subsidiary for which no other PUHCA application form is prescribed, filed under Rule 20(e) of PUHCA 1935.
Rule 20(e) is the residual application channel. When a transaction fits a prescribed form — Form U-1 for securities issuances and acquisitions, Form U-9C-3 for short-term financing, Form U-13-1 for service-company arrangements, and similar U-series forms — the system uses that form. When the transaction still requires SEC authorization or a declaration under PUHCA but does not map to any prescribed form, the applicant submits Form 35-APP, describing the proposed action, identifying the parties, and attaching exhibits sufficient for the Commission to act.
Typical 35-APP triggers include intra-system reorganizations, non-standard intra-system transfers, atypical financings or guarantees, formation of special-purpose subsidiaries, and other PUHCA-jurisdictional actions outside the standardized U-series.
A Form 35-APP/A is filed by the same registered company to amend a pending application — to revise the transaction description, supplement exhibits or financials, respond to SEC staff comments, correct errors, or update terms before the Commission acts.
Filing timing is governed entirely by when the underlying transaction is contemplated. There is no annual, quarterly, or fiscal-period cadence.
Form 35-APP belongs to the discontinued PUHCA 1935 application family. The most useful comparisons are the other U-prefixed PUHCA forms, the 35-APP/A amendment variant, and the post-repeal FERC analogs that absorbed this regulatory function in 2006. Exchange Act and Investment Company Act filings are sometimes confused with PUHCA filings but operate under different statutes and are not substitutes.
Form 35-APP/A (amendment). Same form family, same docket. A 35-APP/A restates, supplements, or corrects a previously filed 35-APP, often to add exhibits, address staff comments, or revise transaction terms. The distinction is procedural: the original initiates the application; the amendment modifies it on the same accession lineage. Both are included in this dataset because they cannot be analyzed in isolation.
Form U-1 (Application or Declaration under PUHCA). The closest substantive neighbor. U-1 was the standard application vehicle for transactions enumerated under PUHCA sections 6, 7, 9, 10, and 12 (issuance and sale of securities, acquisitions, intra-system financings, service-company arrangements). Form 35-APP is the residual application under Rule 20(e), used only when a transaction requires SEC authorization under PUHCA but does not fit any prescribed form, including U-1. U-1 captures the bulk of routine PUHCA transactions; 35-APP captures the long-tail and atypical matters that fall outside every other application form.
Form U5S (Annual Report of Registered Holding Companies). A system-wide annual report describing holding-company structure, intercompany transactions, service-company billings, and consolidated financial position. Thematic overlap with 35-APP, but U5S is periodic, retrospective, and structural, while 35-APP is event-driven, prospective, and transactional. A 35-APP authorizes a specific deal in advance; U5S documents what occurred across the system over a year.
Form U-9C-3 (Quarterly Report by Registered Holding Companies). Quarterly periodic report on investments and intra-system financings under PUHCA. Like U5S, it is retrospective and not a substitute for 35-APP, but it can supply financial context surrounding an authorized transaction.
Form U-13E-1 (Application by Mutual Service Company). Used by mutual or subsidiary service companies seeking PUHCA section 13 approval of organization, operations, or service contracts. Narrower and more standardized than 35-APP. A 35-APP would only be used in the residual case where even U-13E-1 did not fit the proposed service-company arrangement.
Other U-forms (U-3A-2, U-57, U-R-1, U-12-IB, U-6B-2, etc.). Each is narrowly drawn for a specific PUHCA provision (exemption statements, holding-company registration, specific securities or borrowing reports). Form 35-APP differs from all of them by being explicitly defined as the Rule 20(e) catch-all: it exists so transactions outside every enumerated U-form still have an authorization pathway.
PUHCA 1935 was repealed February 8, 2006 by the Energy Policy Act of 2005, which transferred holding-company oversight to FERC under PUHCA 2005. Form 35-APP and the rest of the U-form family were discontinued at the SEC with no successor form on EDGAR. Functionally analogous filings now live in FERC's docketing systems:
These FERC filings are not in EDGAR and are not part of this dataset; they are mentioned only to clarify where post-2006 activity moved.
Securities Act and Exchange Act filings (S-1, 10-K, 10-Q, 8-K) by utility holding companies. Many PUHCA registrants were also Securities Act issuers and Exchange Act reporting companies. Those filings disclose information to investors about a public issuer; they are not authorization requests. A single transaction may appear as a prospective Rule 20(e) authorization on Form 35-APP and, separately, as a retrospective 8-K event or MD&A discussion in a 10-K. Statute, audience, legal posture, and content rules differ; these filings complement rather than substitute for 35-APP.
Investment Company Act filings (N-1A, N-CSR, N-series). PUHCA and the 1940 Act are sometimes grouped because both regulate corporate structures, but the filer populations do not overlap (registered investment companies and their advisers vs. registered utility holding-company systems), and the content (portfolio holdings and fund operations vs. utility-system structure and financing) does not align. Treat as a negative contrast only.
Schedules 13D/13G and Forms 3, 4, 5. Exchange Act beneficial-ownership and insider-transaction filings. They concern equity ownership in public issuers and do not authorize transactions or address PUHCA holding-company structure. No content overlap with 35-APP.
Three properties make Form 35-APP distinct in the EDGAR landscape: it is transaction-specific and prospective rather than periodic; it is the Rule 20(e) residual application within the PUHCA 1935 family, invoked only when no other U-form applies; and it belongs to a closed regime (October 1995 through early 2006) with no SEC successor, since post-2006 analogs moved to FERC. U-1 is the comparison for standardized PUHCA applications, U5S and U-9C-3 for periodic holding-company reporting, 35-APP/A for amendments to the same docket, and FERC Section 203 / Form 60 for the modern equivalent function outside SEC EDGAR.
The Form 35-APP Files Dataset serves a narrow and historical user base, anchored on three record elements: the transaction description, the entities[] block listing filer and counterparty holding-company affiliates, and the SGML body containing board resolutions, agreements, and financial exhibits.
Researchers writing on the 70-year arc of federal holding-company supervision and the SEC-to-FERC handoff use the corpus as primary source for the statute's final decade. They mine the description field to characterize the residual transactions still being noticed under Rule 20(e), intra-system service contracts, minor reorganizations, asset transfers, and financings outside the U-1 / U5S / U-13 framework, and read the SGML legal recitations explaining why Rule 20(e) was used instead of a numbered application. Output: journal articles, dissertations, and book chapters on regulatory transition history.
Corporate historians reconstructing the predecessor chains of present-day electric and gas holding companies use 35-APP records to fill late-1990s and early-2000s gaps in intra-system transaction chronology. They parse entities[] to identify filer, named subsidiary, and counterparty, and pull effective dates, consideration, and asset descriptions from the exhibits. Output: corporate-genealogy memos, family-tree diagrams, and sourcing footnotes linking current operating subsidiaries to documented PUHCA-era transactions.
Records and reference staff at the federal agencies that inherited PUHCA responsibilities, plus law-library staff serving the energy bar, use the dataset to answer historical inquiries without re-pulling accessions one by one from legacy EDGAR. They use the metadata JSON (form type, accession, CIK, filing date) to confirm a Rule 20(e) statement's existence and date, and ship the bundled TXT exhibits as the complete original submission. Workflow: reference response, FOIA-style document production, and citation verification.
Litigators handling rate cases, prudence reviews, intercompany-pricing disputes, environmental successor-liability claims, and contract fights turning on PUHCA-era transactions use 35-APP filings to reconstruct the regulatory paper trail. They cite the description for what was represented to the SEC, the entities[] block to establish signatory and bound affiliates, and the SGML exhibits (board resolutions, agreements, opinions of counsel, financial schedules) for arguments on authorization, consideration, and successor obligations. Output: exhibit lists, deposition binders, and brief citations.
Corporate secretaries and regulatory-affairs staff at present-day utility holding companies maintain institutional files on every PUHCA-era authorization touching their corporate family. They use the dataset as an indexed off-site copy of their own historical 35-APPs and those of acquired predecessors, anchored on entities[] filer identity and the exhibits documenting transaction terms. Supports state PUC discovery responses and successor-by-merger representations in current financing documents.
Engineering teams building exhaustive EDGAR mirrors and form-type taxonomies need every code represented, including discontinued and low-volume ones, so downstream filters on formType do not silently drop rows. They register 35-APP and 35-APP/A in their schema, use the accession-level files to verify their pipeline handles pre-2006 SGML submissions, and treat the corpus as a regression fixture for parser coverage and completeness checks.
The dataset supports a small set of concrete archival, legal, and engineering workflows tied to the closed PUHCA 1935 era (October 1995 through February 8, 2006).
Corporate-genealogy researchers and in-house regulatory counsel use 35-APP records to fill intra-system transaction gaps in the late-1990s and early-2000s history of today's investor-owned utilities. The workflow is to filter metadata.json.entities[].cik for the parent and its acquired predecessors, group hits by entities[].fileNo (the 031- PUHCA docket) and filedAt, and then extract the transaction recital, dollar amounts, and exhibit list from the SGML body of the principal 35-APP document. The output is a chronological exhibit set documenting each authorized intra-system asset transfer, service-company arrangement, or financing that flows into a current corporate-family diagram.
Data engineers maintaining exhaustive EDGAR mirrors register 35-APP and 35-APP/A as first-class form codes so that downstream filters on formType do not silently drop them. The corpus is small enough to serve as a regression fixture: pipelines are exercised against the pre-2006 ASCII SGML envelope (<DOCUMENT>, <TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>, <TEXT> with embedded <PAGE> tokens), and the documentFormatFiles[] whitespace-sentinel sequence values and trailing rolled-up pseudo-document are used to verify parser tolerance. Output: a form-type taxonomy and parser test suite that demonstrably handle the full historical EDGAR surface.
Regulatory historians and academics writing on the 2006 SEC-to-FERC handoff use the corpus as primary source for the statute's final decade. The workflow parses the description field plus the rule-citation lines in the body (Rule 20(e) versus Rule 24, with associated "Public Utility Holding Company Act Release No." references) to characterize what residual transactions registered systems were still noticing in the run-up to repeal. Cross-referenced against post-2006 FERC Section 203 and Form 60 dockets, this supports journal articles and book chapters describing exactly which authorization functions migrated, which lapsed, and which were absorbed by other statutes.
SEC and FERC records staff and law-library reference desks serving the energy bar answer historical inquiries from the dataset rather than re-pulling accessions individually from legacy EDGAR. A typical request — "produce every Rule 20(e) statement filed by CIK X between 2001 and 2003" — is resolved by filtering metadata.json on entities[].cik, formType, and filedAt, then shipping the per-accession folder (parsed header plus the verbatim SGML .txt exhibits) as the complete original submission. The linkToFilingDetails and linkToHtml URLs are returned alongside for citation verification.
Litigators in rate cases, prudence reviews, intercompany-pricing disputes, and environmental successor-liability claims use 35-APP filings to establish what was represented to the Commission and which affiliates were bound. The workflow cites the description and the substantive recital paragraphs for the representations made; uses entities[] (companyName, cik, stateOfIncorporation, fileNo) to identify the signatory holding company and any co-applicants; and pulls the appended opinion of counsel, board resolutions, and exhibit schedules from the SGML body for arguments on corporate authority, consideration, and successor obligations. Output: deposition binders, exhibit lists, and brief citations anchored on accession number and PUHCA file number.
Because amendments coexist with their underlying filings as independent accession folders, reconstructing the final state of a proposed transaction requires joining records across the docket. Researchers group records by entities[].cik plus entities[].fileNo, sort by filedAt, and read the amendment's opening recital (which typically names the prior accession or PUHCA file number) to determine whether the 35-APP/A restates the statement in full or supplies only changed paragraphs. The output is a single consolidated transaction record per PUHCA docket, suitable for citation in regulatory memos and corporate-history footnotes.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-35app-files.json
This endpoint returns dataset metadata along with the list of available container files. The response includes the dataset name, description, last update timestamp, earliest sample date (1995-10-01), total records, total size, covered form types (35-APP and 35-APP/A), container format (ZIP), and content file types (TXT, JSON). It also provides the full dataset download URL and a containers array listing each monthly container file with its key, size, record count, last updated timestamp, and direct download URL. This endpoint does not require an API key. Polling this endpoint is the recommended way to detect which containers were modified in the most recent refresh and to decide which files to re-download.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-6a7a-9833-f949efe3c461",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-35app-files.zip",
4
"name": "Form 35-APP Files Dataset",
5
"updatedAt": "2026-04-16T08:56:32.420Z",
6
"earliestSampleDate": "1995-10-01",
7
"totalRecords": 17,
8
"totalSize": 93916,
9
"formTypes": ["35-APP", "35-APP/A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["TXT", "JSON"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-35app-files/1995/1995-10.zip",
15
"key": "1995/1995-10.zip",
16
"size": 12483,
17
"records": 2,
18
"updatedAt": "2026-04-16T08:56:32.420Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-35app-files.zip?token=YOUR_API_KEY
Downloads the full dataset as a single ZIP archive covering all 35-APP and 35-APP/A filings from October 1995 through the form's discontinuation in February 2006. Because the complete dataset is small, a one-shot download is practical for most use cases. This endpoint requires an API key.
Download Single Container: https://api.sec-api.io/datasets/form-35app-files/1995/1995-10.zip?token=YOUR_API_KEY
Downloads one monthly container ZIP instead of the full archive. Replace the year and month segments with any container key returned by the index API (path pattern form-35app-files/<year>/<year>-<month>.zip). This endpoint requires an API key.
The dataset covers Form 35-APP — the EDGAR form designated "Statement on proposed transaction where no application is prescribed [Rule 20(e)]" under the Public Utility Holding Company Act of 1935 — together with its amendment variant Form 35-APP/A. Both form codes are included as first-class records.
One record is one EDGAR submission of either a Form 35-APP statement or a Form 35-APP/A amendment, materialized on disk as one accession-numbered folder. Each folder contains a parsed metadata.json header file plus every non-image document attachment from the original EDGAR submission, preserved in its original ASCII/SGML form.
Filers were limited to two related groups within a PUHCA 1935 registered system: registered holding companies under Section 5 of PUHCA 1935 (corporate parents owning ten percent or more of the voting securities of an electric or retail gas utility company and not qualifying for a Section 3 exemption), and the subsidiary companies of those registered holding companies. Section 3 exempt holding companies, intrastate utilities, independent power producers, and stand-alone investor-owned utilities not controlled by a registered holding company had no obligation to file.
Filing was event-driven, triggered by a proposed transaction by a registered holding company or subsidiary for which no other PUHCA application form was prescribed. The dataset is a closed historical corpus: PUHCA 1935 was repealed by the Energy Policy Act of 2005 effective February 8, 2006, after which Form 35-APP was retired. The dataset spans October 1995 through that repeal and is not growing.
The dataset is distributed as monthly ZIP containers under the path pattern form-35app-files/<YYYY>/<YYYY>-MM.zip. Inside each container, every record folder contains a metadata.json header file plus one or more .txt files that retain the EDGAR SGML <DOCUMENT> envelope around an ASCII text body. There are no XBRL, HTML, or image files in the dataset.
Form U-1 was the standard PUHCA application vehicle for transactions enumerated under PUHCA sections 6, 7, 9, 10, and 12 (securities issuance, acquisitions, intra-system financings, service-company arrangements). Form 35-APP is the residual application under Rule 20(e), used only when a transaction required SEC authorization under PUHCA but did not fit U-1 or any other prescribed form. U-1 captures the bulk of routine PUHCA transactions; 35-APP captures the long-tail and atypical matters.
No. Form 35-APP and the rest of the U-form family were discontinued at the SEC with no successor form on EDGAR. Holding-company oversight transferred to FERC under PUHCA 2005, where functionally analogous matters are handled as FERC Section 203 applications under the Federal Power Act and FERC Form 60 annual reports for centralized service companies. Those FERC filings live in FERC's docketing systems and are not part of this dataset.