The Form S-8 POS Files Dataset is a complete EDGAR corpus of post-effective amendments to Form S-8 employee-benefit-plan registration statements filed under Section 6 of the Securities Act of 1933. Each record is one EDGAR submission of an Form S-8 POS filing, identified by its 18-digit accession number and packaged with its metadata.json index plus every original EDGAR document (cover HTML, EX-5.1 legal opinions, EX-23.x auditor consents, EX-4.x plan documents, and any TXT or PDF attachments). Filers are Exchange Act reporting issuers — domestic corporations, foreign private issuers, and Rule 414 successors — that previously registered employee-plan securities on Form S-8 and are now amending, updating, or deregistering that registration. The dataset spans EDGAR filings from January 1994 to the present, captures both substantive plan amendments and Rule 478 deregistrations, and is distributed as monthly ZIP containers under the form-s8-pos-files/<YYYY>/<YYYY>-MM.zip key.
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 built from Form S-8 POS, the post-effective amendment vehicle for an already-effective Form S-8 employee-benefit-plan registration statement. The original Form S-8 registers securities — overwhelmingly common stock or beneficial interests offered under an employee stock-purchase, equity-incentive, 401(k), or director-compensation plan — that the issuer makes available to employees, officers, directors, or consultants pursuant to a written employee benefit plan. The post-effective amendment ("POS") modifies that already-effective registration after the fact. In practice S-8 POS filings serve three distinct purposes, which the dataset captures intermixed:
Because the amendment operates on a previously declared-effective registration, the filing does not restate the original S-8 in full. It identifies the registration being amended (by 333- file number) and then either restates Part II of the registration statement with updated information or recites a Rule 478 deregistration undertaking. The corpus covers the entire EDGAR filing population for this form type from January 1994 to the present, distributed as monthly ZIP containers in which each filing is one folder named with the dash-stripped accession number.
One record is a single EDGAR submission of a Form S-8 post-effective amendment, identified by its 18-digit accession number. Records are packaged in monthly ZIP containers at form-s8-pos-files/<YYYY>/<YYYY>-MM.zip; each ZIP unpacks to a <YYYY>-MM/ directory holding one folder per filing, named with the dash-stripped accession number. Inside that folder sit exactly one metadata.json index plus the EDGAR documents the registrant uploaded for the submission. Image attachments (GRAPHIC document type) and the consolidated SGML .txt submission wrapper are intentionally not packaged on disk, even though both are still enumerated in the manifest.
Two record shapes dominate.
Bare amendment. metadata.json plus a single cover document whose filename contains an s8pos (or s-8pos) substring — for example tm2525998d8_s8pos.htm, ef20055978_s8pos.htm, or d70492ds8pos.htm. This shape is overwhelmingly common when the POS is a Rule 478 deregistration, since deregistration filings carry no exhibits and incorporate everything else by reference.
Full amendment. The cover document plus one or more exhibit HTML files. The exhibits routinely encountered are:
Document filenames are filer-controlled and follow the house style of whichever filing agent prepared the submission: Donnelley uses a d<job>ds8pos.htm pattern; Toppan Merrill uses tm<job>d<n>_s8pos.htm; EdgarAgents uses ef<job>_s8pos.htm; in-house filers use registrant-named files such as slm09042025forms-8pos.htm. Exhibits typically share the cover document's prefix with an _ex<n> or _ex<nn> suffix (e.g. eh250672770_ex0501.htm, slm09042025ex232.htm).
metadata.json indexmetadata.json is the per-filing index assembled from the EDGAR header plus the document manifest. Its top-level fields are:
formType — always "S-8 POS".accessionNo — the EDGAR accession number with dashes (e.g. "0000950142-25-002359"); the canonical record key.effectivenessDate — YYYY-MM-DD date the amendment becomes effective.filedAt — full filing timestamp as ISO 8601 with offset, e.g. "2025-09-02T16:16:05-04:00".linkToFilingDetails — URL of the primary cover document on EDGAR (the *_s8pos.htm).linkToTxt — URL of the consolidated SGML submission .txt on EDGAR. The dataset does not package this file, but the URL allows retrieval if needed.linkToHtml — URL of the EDGAR submission index page (-index.htm).linkToXbrl — empty for this form type.documentFormatFiles[] — the document manifest (see below).dataFiles[] — empty for this form type.seriesAndClassesContractsInformation[] — empty for this form type.entities[] — registrant and any co-registrants (see below).id — internal 32-character hex identifier.documentFormatFiles[]One entry per attachment in the original EDGAR submission. Each entry carries sequence (string-encoded integer; "1" for the cover, "2", "3", ... for exhibits in filer-declared order, with a single space " " reserved for the consolidated SGML wrapper), size in bytes, the absolute documentUrl on www.sec.gov, a free-text description (often the amendment number, e.g. "AMENDMENT NO. 1"), and type ("S-8 POS" for the cover; "EX-5.1", "EX-23.1", "EX-23.2", "EX-4.2", "GRAPHIC", etc. for exhibits). Because this manifest enumerates the original submission, it includes references to files the dataset deliberately omits (image GRAPHICs and the SGML .txt wrapper); consumers should not assume every manifest entry maps to a file on disk.
entities[]Each entity is the EDGAR header projection of a filer or co-registrant. Fields relevant to interpretation are cik (issuer Central Index Key), fileNo (the 333-... registration number being amended — the join key back to the underlying S-8), act (always "33" for the Securities Act of 1933), companyName (suffixed with (Filer)), fiscalYearEnd in MMDD form, stateOfIncorporation, irsNo, sic (SIC code with descriptive label), filmNo, and tickers[]. Most records carry exactly one entity; co-registrants appear when guarantor subsidiaries or parent holding companies are jointly registering the same plan securities.
Every .htm file in the dataset is wrapped in the EDGAR SGML <DOCUMENT> envelope — the literal contents of the <TEXT> block from the consolidated submission are retained at the top of each file:
1
<DOCUMENT>
2
<TYPE>S-8 POS
3
<SEQUENCE>1
4
<FILENAME>eh250672770_s8pos.htm
5
<DESCRIPTION>AMENDMENT NO. 1
6
<TEXT>
7
<HTML>
8
<HEAD>...</HEAD>
9
<BODY>... full HTML body of the registration statement / exhibit ...</BODY>
10
</HTML>
11
</TEXT>
12
</DOCUMENT>
The five header lines (TYPE, SEQUENCE, FILENAME, DESCRIPTION, <TEXT>) align one-to-one with metadata.json -> documentFormatFiles[], which makes it straightforward to reconstruct the original manifest from the wrapped HTML alone.
The HTML body inside the wrapper takes one of two recurrent shapes.
A substantive POS reproduces the standard Form S-8 registration-statement layout:
POST-EFFECTIVE AMENDMENT NO. [N] TO [FORM S-8 / FORM S-4] UNDER THE SECURITIES ACT OF 1933, followed by the exact registrant name, state or other jurisdiction of incorporation, IRS employer identification number, principal-executive-office address and telephone number, the full title(s) of the employee benefit plan(s) covered, the name and address of the agent for service of process, and a "Copies to:" block listing outside counsel.prospectus.htm; updated prospectus content, where present, is inlined into the cover HTML.Deregistration POS filings share the same cover block but replace Part II with a short DEREGISTRATION OF SECURITIES (or similarly titled) section. This section identifies each underlying S-8 registration number (333-...) being terminated, recites the historical share counts originally registered, states the number of unsold shares being deregistered, and invokes the Rule 478 undertaking from the original S-8 to remove from registration any securities remaining unsold at the termination of the offering. A short signature block follows. Bodies of this shape are typically 24 to 32 kilobytes of HTML with no exhibits.
The dataset includes, per record, the per-filing metadata.json index plus every original EDGAR document for that submission other than image attachments. It explicitly excludes graphic files (logos, signature images, charts uploaded as GRAPHIC document type) and does not package the consolidated SGML .txt submission wrapper, although both remain enumerated in documentFormatFiles[]. Form S-8 plan-information prospectuses delivered to participants under Rule 428 are not filed with the SEC and never appear in the corpus. Documents incorporated by reference from prior filings — most prominently the registrant's most recent Form 10-K, intervening Form 10-Q and Form 8-K filings, and earlier Form S-8 registrations — are referenced by description and accession number in Item 3 of Part II but are not embedded; the underlying Form S-8 being amended must be retrieved separately by joining on cik and fileNo.
The corpus spans EDGAR filings from January 1994 to the present. The file-types found in the dataset are TXT, JSON, HTML, and PDF, distributed unevenly across the timeline:
<DOCUMENT>...<TEXT>...</TEXT></DOCUMENT> envelope. The cover S-8 POS document is a .txt file containing pseudo-tabular ASCII layout for the cover block and registration fee table, the Part II Items in narrative ASCII, and ASCII signature lines. Exhibits are likewise text. PDF copies, when filed, are unofficial supplements to the text submission rather than the primary document..htm) but remain wrapped in the same SGML <DOCUMENT> envelope, which is why every modern .htm in the dataset still begins with the <TYPE>, <SEQUENCE>, <FILENAME>, <DESCRIPTION>, <TEXT> header lines before the <HTML> block.metadata.json. Form S-8 POS has never been subject to structured-data tagging mandates, so document content is HTML or text throughout the timeline; only the wrapped document format changes across years, while the metadata.json schema is consistent.entities[0].fileNo, which carries the specific 333-... registration being amended; accessionNo alone does not identify which underlying S-8 a given amendment targets.fileNo is the join key to the original S-8. To pair a POS record with its underlying registration statement, key on the combination of entities[0].cik and entities[0].fileNo. Conversely, multiple POS records sharing the same (cik, fileNo) represent successive amendments to the same registration.description, not in a structured field. The documentFormatFiles[].description field for the cover document carries human-entered text such as "AMENDMENT NO. 1", "POST-EFFECTIVE AMENDMENT NO. 3", or simply "S-8 POS". There is no structured amendmentNumber field; the count must be parsed from this string or from the cover-block heading inside the HTML body.DEREGISTRATION OF SECURITIES (or equivalent) heading, by the absence of exhibits in documentFormatFiles[], and by the short body length. Substantive amendments include exhibits (typically EX-5.1 plus one or more EX-23.x consents) and a full Part II.<html>-rooted document must skip the leading SGML header lines or strip everything outside <TEXT>...</TEXT> before handing the body to an HTML parser. Conversely, the wrapper is the easiest way to recover TYPE, SEQUENCE, FILENAME, and DESCRIPTION directly from disk without re-reading metadata.json.entities[] has more than one element, the additional entities are co-registrants jointly registering the same plan securities — usually subsidiary guarantors or a parent holdco. Each co-registrant signs the registration statement, and signature blocks are repeated per entity in the cover HTML.(cik, fileNo) join to bring in structured data from related filings when needed.A Form S-8 POS is a post-effective amendment to a previously effective Form S-8 registration statement. The filer is the issuer that originally registered employee-plan securities on Form S-8, or a successor issuer adopting the predecessor's S-8 under Rule 414 of the Securities Act.
The eligible population is narrow and identical to that of Form S-8 itself:
Plan participants are the offerees of the registered securities, not filers. The legal filer is always the issuer.
The S-8 POS regime is built on:
S-8 POS filings are event-driven, not periodic. The recurring triggers are:
S-8 post-effective amendments generally become effective upon filing, consistent with the automatic-effectiveness convention applied to Form S-8. If Commission review is undertaken, effectiveness occurs on a date set by the staff. There is no calendar-based deadline; the filing is made when the underlying corporate, plan, or offering event occurs. Each amendment is signed in conformity with Form S-8 signature requirements and submitted through EDGAR under Regulation S-T.
Form S-8 POS sits at the crossroad of Securities Act post-effective mechanics, employee benefit plan disclosure, and successor-issuer transitions. Several adjacent forms touch the same territory, but each diverges on at least one load-bearing axis: trigger, statute, securities affected, or legal effect. The comparisons below isolate the closest neighbors and clarify when S-8 POS is the right dataset and when another would be.
S-8 is the original short-form 1933 Act registration statement for securities offered under employee benefit plans (options, ESPPs, 401(k) employer-stock funds, RSU plans). It is effective immediately on filing. S-8 POS is the amendment vehicle that operates only after that statement is effective — to update the prospectus, reflect fundamental changes, deregister unsold shares, or carry the registration to a successor under Rule 414. Same plans, same exhibits, same share pools — but S-8 marks the entry point, while S-8 POS captures every later modification, termination, or transition. The original S-8 alone reveals nothing about what happened to the registered shares afterward.
Form POS AM is the sibling post-effective amendment for S-1, S-3, F-1, F-3, and similar offering registrations. The mechanics rhyme — both amend an effective registration — but the underlying offerings, filer behavior, and review posture differ. POS AM typically updates primary or resale offerings to public investors and may sit through Staff review or a delaying amendment. S-8 POS rides the same automatic-effectiveness regime as S-8 itself and generally takes effect immediately or on a stated cover date. Filer populations, securities offered, and effectiveness mechanics diverge sharply; POS AM is not a substitute when tracking employee-plan registrations.
The 424B series consists of Rule 424 prospectus supplements that update an already-effective registration with pricing, takedown, or material updates. They sit alongside the registration statement rather than amending it, cannot change the registered share count, and cannot deregister securities or carry the registration to a new issuer — all things S-8 POS can do. S-8 registrants rarely use 424 supplements at all because the Section 10(a) plan prospectus is delivered outside EDGAR. Form 424 (424B1, 424B2, 424B3, 424B5) captures market-facing prospectus updates for cash offerings; S-8 POS captures legal modifications to plan registrations.
RW is a Rule 477 request to withdraw a registration statement that has not yet become effective, or to withdraw specific pre-effective amendments or exhibits. It pulls a registration before it goes live. S-8 POS overlaps in spirit only when used to deregister unsold securities — but by then the S-8 is already effective on filing, so the issuer is removing remaining shelf capacity rather than aborting the registration. RW is essentially absent in the S-8 context. Endpoints of employee-plan registrations live in S-8 POS deregistration filings, not RW.
Rule 462(b) lets an issuer register up to an additional 20% of the same class via an immediately-effective amendment; Form S-3MEF is the analogous mechanism for shelf takedowns needing extra capacity. Both are forward-looking expansion filings. For employee plans, incremental shares are almost always added through a fresh "evergreen" S-8 rather than a 462(b) amendment, so neither form substitutes for S-8 POS. The clean rule for reconstructing total plan shares: increases come from new S-8 filings; decreases, transitions, and substantive plan changes come from S-8 POS.
Form 11-K is the 1934 Act annual report for employee stock purchase, savings, and similar plans holding employer securities. It contains audited plan financial statements — assets, contributions, distributions, participant data — filed annually under Section 15(d). It shares a subject with S-8 POS (the same plans) but is the opposite kind of disclosure: periodic financial reporting under the Exchange Act versus event-driven registration mechanics under the Securities Act. They are complementary, not overlapping. Use 11-K for plan economics; use S-8 POS for plan registration status, share-pool changes, and successor adoptions.
Form 15 terminates or suspends an issuer's Section 12(g) or 15(d) reporting obligations, typically after going private or falling below holder thresholds. It superficially resembles an S-8 POS that deregisters unsold shares but operates one statutory layer up: Form 15 ends Exchange Act reporting for the issuer, while S-8 POS only removes unsold securities from a specific Securities Act registration shelf. The two are often filed in the same M&A window — S-8 POS to clear plan shares, Form 15 to stop SEC reporting — but they answer different questions. S-8 POS is plan-level; Form 15 is issuer-level.
Around mergers, acquisitions, holding-company reorganizations, and spinoffs, Form 8-K narrates the corporate event itself — Item 1.01 for material agreements, Item 2.01 for completed acquisitions, Item 5.02 for officer changes. Rule 414 then permits a successor issuer to adopt the predecessor's effective registration statements, and that adoption is executed through an S-8 POS carrying the predecessor's S-8 forward. 8-K describes the deal; S-8 POS executes the registration-level legal mechanics, including Rule 414 adoption language, plan reassignments, and any deregistration of unconsumed shares. Researchers see the deal in 8-K but only see what happened to the predecessor's plan registration in S-8 POS.
S-8 POS is the only filing that documents the legal after-life of an effective employee benefit plan registration. Specifically:
No neighbor covers this combination. S-8 marks the registration's birth; 11-K reports plan finances; 8-K describes the corporate event; Form 15 terminates issuer reporting; POS AM, 424B, RW, 462(b), and S-3MEF all serve unrelated offering tracks. When the question is how an employee-plan registration was modified, narrowed, transferred, or wound down, S-8 POS is not substitutable.
Form S-8 POS amendments capture deregistrations of unsold employee-plan shares, Rule 414 successor-issuer adoptions, share-pool changes, and routine prospectus updates. The users below each draw on a specific slice of the record.
Drafting attorneys use the corpus as a precedent library when preparing deregistration POS amendments, Rule 414 adoptions after holding-company reorganizations, or post-termination share withdrawals. They mine the cover-page legend, the explanatory note, the deregistration table, and the Item 8 exhibit index (legal opinions, auditor consents) to model language and confirm which exhibits are filed versus incorporated by reference. The decision: how to structure a clean first draft that survives staff review.
Compensation consultants and ERISA counsel scan peer POS filings to detect plan terminations, ESPP wind-downs, omnibus-plan replacements, and post-RIF share withdrawals. They pull the plan name and date from the cover page, the explanatory note for the amendment reason, and share counts from the deregistration table, joined to peers via entities[] CIK. The decision: how to size and time the next share-pool request a board compensation committee will approve.
Deal lawyers and integration teams track the registration-statement lifecycle around stock-for-stock transactions and reorganizations. They focus on the explanatory note describing the merger, the deregistration table quantifying withdrawn target shares, the target-versus-acquirer CIKs in entities[], and exhibit references to merger or plan-of-reorganization documents. The decision: confirming on a post-closing checklist that target plans were properly wound up or assumed by the successor issuer.
Reporting managers reconcile internal registration-statement inventories against EDGAR. They use metadata.json (accession, filing date, form type, CIK, file number) for joins, the cover page to confirm registrant details, and the deregistration table as audit evidence that unsold shares from terminated plans were withdrawn. The decision: closing the lifecycle log per plan (S-8 effective, 424 supplements, POS amendments, final deregistration) for auditor and internal-control review.
Fundamental analysts treat POS deregistrations as deflationary signals for overhang and POS updates as neutral-to-mildly dilutive. They subtract withdrawn shares using the deregistration table, classify the amendment from the explanatory note, and link to a covered ticker via registrant CIK. The decision: adjusting share-count and overhang forecasts after restructurings, RIFs, spinoffs, or completed acquisitions.
Investigators mine plan-amendment sequences in compensation disputes, fiduciary-duty claims, and restatements touching share-based compensation. They look at filing dates and accession numbers in metadata.json, the explanatory note, deregistration share counts, and auditor-consent exhibits that may flag auditor changes coinciding with plan changes. The decision: building timelines and exhibits for expert reports and depositions.
Researchers use the corpus as a longitudinal panel from 1994 to present, joining entities[] CIKs to compensation and governance datasets. They extract plan names, registered and deregistered share counts, and amendment reasons from the cover page and explanatory note to study overhang trends, deregistration behavior after layoffs or spinoffs, and the frequency of Rule 414 adoptions.
Engineering and quant teams ingest the POS stream as an event feature. They parse metadata.json to key events on CIK, classify each POS from the explanatory note (deregistration, update, successor adoption, pool reduction), and extract the deregistration table for net registered-share deltas per issuer per quarter. The decision: feeding M&A-completion trackers, dilution-overhang factors, and event-driven signals.
Filing agents use comparable POS submissions as templates to validate header tags, exhibit numbering, deregistration-table format, and signature-page structure. They rely on the raw HTML and TXT submission documents, the exhibit index, and metadata.json for filer identification. The decision: producing first drafts that pass EDGAR validation with minimal rework.
Teams building retrieval systems for securities filings embed the explanatory note, exhibit index, and deregistration table, using metadata.json for filtering by filer, date, and form type. The decision: supporting Q&A like "POS filings deregistering shares from terminated ESPPs" or "Rule 414 successor adoptions in a given year."
Governance researchers and activist analysts read POS activity as a secondary signal of restructuring or compensation-policy change. Clusters of deregistrations may flag a unit sale or workforce action; a Rule 414 adoption signals a holding-company reorganization. They focus on the explanatory note, deregistration counts, and registrant identity. The decision: shaping engagement memos, voting recommendations on equity-plan and say-on-pay proposals, and watchlists of issuers in transition.
The dataset serves three overlapping concerns: registration-statement hygiene (counsel, compliance, filing agents), employee-equity economics (compensation consultants, analysts, governance teams), and corporate-event extraction (M&A counsel, quants, forensic accountants, academics). Each role pulls different fields from the same record — metadata.json for joins and timing, the cover page for registrant and plan identity, the explanatory note for classification, the deregistration table for share-count math, and the exhibit list for legal-opinion and consent verification.
The use cases below are grounded in what S-8 POS records actually contain: a metadata.json index keyed on (cik, fileNo), a cover HTML carrying either a substantive Part II or a Rule 478 deregistration block, and, where present, EX-5.1 legal opinions, EX-23.x auditor consents, and EX-4.x plan documents.
M&A integration counsel monitors the deregistration of unsold shares under acquired-issuer S-8 shelves after a closing. The workflow joins entities[].cik and entities[].fileNo to the predecessor's original S-8, filters the cover HTML for a DEREGISTRATION OF SECURITIES heading, and extracts the share counts recited in the deregistration block. Output: a per-deal post-closing checklist confirming each target plan registration was either wound up or carried forward to the successor.
Event-data engineers extract Rule 414 adoptions from S-8 POS bodies to flag holding-company reorganizations, redomiciliations, and similar successor transitions. The pipeline scans the cover document for Rule 414 adoption language, captures the predecessor and successor CIKs from entities[], and pairs the result with the corresponding 8-K Item 2.01. Output: a structured event stream marking when a successor issuer assumed a predecessor's effective S-8 registrations.
Equity analysts and dilution modelers convert deregistration POS filings into negative deltas on registered share inventory. They classify the amendment by inspecting the cover HTML (presence of a deregistration section, absence of EX-5.1 and EX-23.x), pull the unsold-share count from the deregistration recital, and key the adjustment to the issuer via entities[0].cik and ticker. Output: revised overhang and basic-share-count forecasts following RIFs, spinoffs, or completed acquisitions.
Securities counsel mines the corpus as a precedent bank when drafting a new POS. They retrieve recent filings sharing the relevant fact pattern (Rule 478 deregistration, Rule 414 adoption, omnibus-plan refresh), compare the cover-block legend, explanatory note, Item 8 exhibit index, and signature page, and pull EX-5.1 opinion language and EX-23.x consent forms from neighbor filings. Output: a first-draft amendment whose structure, exhibits, and undertakings track current market practice.
In-house SEC reporting teams reconcile their registration-statement inventory by chaining all POS amendments to a given underlying S-8. They group records by (entities[0].cik, entities[0].fileNo), order by effectivenessDate, and parse the amendment number from documentFormatFiles[].description (e.g. "AMENDMENT NO. 3"). Output: a closed lifecycle log per plan — original S-8, intervening POS updates, and final Rule 478 deregistration — usable as audit evidence and internal-control documentation.
Forensic accountants and litigation-support analysts use EX-23.x consents in substantive POS filings as a side-channel signal of auditor relationships. They extract the consenting accounting firm name from each EX-23.x exhibit, key it to the registrant CIK and effectivenessDate, and compare against the prior 10-K consent. Output: a flag set highlighting issuers whose auditor identity on a plan-related filing diverges from the most recent annual report — a starting point for restatement and fiduciary-duty timelines.
RAG developers building securities-filing assistants embed the cover HTML, deregistration block, and exhibit index, using metadata.json fields (formType, effectivenessDate, entities[].cik, entities[].fileNo, entities[].sic) as filter facets. Output: targeted answers to questions such as "Rule 414 successor adoptions filed in 2024" or "ESPP terminations deregistering more than one million shares," with citations back to specific accession numbers.
The dataset is accessible through three endpoints: a JSON index for programmatic discovery, a single archive containing every container, and direct download URLs for individual monthly containers. Authenticated downloads accept either the ?token=YOUR_API_KEY query parameter or the standard sec-api authentication header.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-s8-pos-files.json
Returns dataset-level metadata and the full list of monthly containers. Each container entry includes its key, size, sha256 checksum, records, updatedAt timestamp, and a per-container downloadUrl. Use this endpoint to monitor which containers were touched by the most recent refresh run and decide which monthly ZIPs to re-download. This endpoint does not require an API key.
1
{
2
"datasetId": "1f13365b-9ae0-6903-95e8-d7fc994f27f4",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-s8-pos-files.zip",
4
"name": "Form S-8 POS Files Dataset",
5
"updatedAt": "2026-05-06T02:50:56.839Z",
6
"earliestSampleDate": "1994-01-01",
7
"totalRecords": 67342,
8
"totalSize": 348137696,
9
"formTypes": ["S-8 POS"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["TXT", "JSON", "HTML", "PDF"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-s8-pos-files/2026/2026-04.zip",
15
"key": "2026/2026-04.zip",
16
"size": 13818783,
17
"records": 154,
18
"sha256": "9f4c2b1d6a7e8c0b5f3a2d1e0c9b8a7f6e5d4c3b2a1908f7e6d5c4b3a2918070",
19
"updatedAt": "2026-05-06T02:50:56.839Z"
20
}
21
]
22
}
Fetch the index with curl:
curl https://api.sec-api.io/datasets/form-s8-pos-files.json
Download Entire Dataset: https://api.sec-api.io/datasets/form-s8-pos-files.zip?token=YOUR_API_KEY
A single ZIP archive bundling every monthly container, covering filings from January 1994 to the current month. This endpoint requires an API key.
curl -O "https://api.sec-api.io/datasets/form-s8-pos-files.zip?token=YOUR_API_KEY"
wget "https://api.sec-api.io/datasets/form-s8-pos-files.zip?token=YOUR_API_KEY"
Download Single Container: https://api.sec-api.io/datasets/form-s8-pos-files/2026/2026-04.zip?token=YOUR_API_KEY
Each container is a per-month ZIP keyed as <YYYY>/<YYYY>-<MM>.zip. Inside, files are organized as one folder per accession number, where each folder contains a metadata.json file alongside the original EDGAR submission documents (HTML, TXT, PDF) — image files excluded. This endpoint requires an API key.
curl -O "https://api.sec-api.io/datasets/form-s8-pos-files/2026/2026-04.zip?token=YOUR_API_KEY"
wget "https://api.sec-api.io/datasets/form-s8-pos-files/2026/2026-04.zip?token=YOUR_API_KEY"
Helper script: This codebase includes scripts/download-sec-api-file.js, which streams one or more dataset URLs to a local directory while preserving the path structure under /datasets/. It reads the API key from the project config and appends it as the token query parameter automatically.
node scripts/download-sec-api-file.js https://api.sec-api.io/datasets/form-s8-pos-files/2026/2026-04.zip --out-dir=./data
The dataset covers Form S-8 POS, the post-effective amendment to a previously effective Form S-8 employee-benefit-plan registration statement filed under Section 6 of the Securities Act of 1933. It captures both substantive plan amendments and Rule 478 deregistrations of unsold securities; it does not include the underlying original Form S-8 itself or pre-effective amendments to a pending S-8.
One record is a single EDGAR submission of a Form S-8 POS filing, identified by its 18-digit accession number. Each record is a folder (named with the dash-stripped accession number) containing a metadata.json index plus every original EDGAR document for the submission — the cover *_s8pos.htm, and where present EX-5.1 legal opinions, EX-23.x auditor consents, and EX-4.x plan exhibits — with image attachments and the consolidated SGML .txt submission wrapper deliberately omitted.
The filer is always the issuer that originally registered employee-plan securities on Form S-8, or a Rule 414 successor adopting that registration. Filers must be Exchange Act reporting issuers (Section 13 or 15(d)) eligible for Form S-8, current in their reports for the preceding 12 months, and not a shell company; both U.S. domestic corporations and foreign private issuers (including 20-F and 40-F filers) appear in the population.
S-8 POS filings are event-driven, not periodic, and there is no calendar-based deadline. They are filed when a fundamental change in the registration statement, a material plan amendment, a Rule 478 deregistration trigger (plan termination, M&A, end of offering), or a Rule 414 successor adoption occurs, and they generally become effective immediately upon filing.
The corpus spans EDGAR filings from January 1994 to the present, reflecting the phase-in of mandatory EDGAR filing for these documents between 1993 and mid-1996. File-type composition evolves across the timeline: TXT-based ASCII submissions dominate from 1994 through mid-2002, after which HTML becomes the default format for cover documents and exhibits.
The dataset is distributed as monthly ZIP containers keyed form-s8-pos-files/<YYYY>/<YYYY>-MM.zip, with file types of TXT, JSON, HTML, and PDF inside. Each container unpacks to a <YYYY>-MM/ directory holding one folder per filing; a single ZIP archive bundling every monthly container is also available at the dataset-level download URL.
Form S-8 captures the original short-form 1933 Act registration statement that registers employee-plan securities and is effective immediately on filing. The S-8 POS dataset captures only the post-effective amendments to those statements — substantive updates, fundamental-change refreshes, Rule 414 successor adoptions, and Rule 478 deregistrations of unsold shares — and is the only filing series that documents the legal after-life of an effective employee-plan registration. Increases in plan share pools generally come through new S-8 filings; decreases, transitions, and substantive plan changes come from S-8 POS.
Use the combination of entities[0].cik (issuer Central Index Key) and entities[0].fileNo (the 333-... registration number being amended) as the join key. Multiple POS records sharing the same (cik, fileNo) represent successive amendments to the same registration; accessionNo alone does not identify which underlying S-8 a given amendment targets, particularly when a registrant files several POS amendments on the same day.