IPO and Securities Registration Statements (S-1)
Securities registration statements - S-1 and S-1/A for IPOs and resale registrations, S-3 and S-3ASR for shelf offerings by seasoned issuers, S-8 for employee benefit plans - one row per filing with the registrant, what class of securities is being registered, whether it is an amendment, and the Rule 457 fee table's stated offering amount where the filer tagged an Exhibit 107. This is the issuance pipeline BEFORE the shares exist, which is what separates it from edgar_dilution_metrics: that measures dilution already reported on the balance sheet, this shows what a company has registered the right to sell.
edgar_registration_statements - the dataset name to pass to the Obscura API.
What one row means
One **Securities Act registration statement** - the filing in which a company registers securities for sale, and therefore the earliest dated, public statement that new shares are coming. The form says what kind of issuance it is: an `S-1` registers an IPO or a resale, an `S-3` a shelf for a seasoned issuer, an `S-3ASR` an *automatic* shelf that is effective the moment it is filed, an `S-8` a share reserve for an employee benefit plan. Together they are the **issuance pipeline**, and they lead `edgar_dilution_metrics` by design: dilution metrics measure share count after it has moved, while a registration statement is filed before a single share is sold. The prospectus itself is NOT stored - an `S-1` runs to 33 MB and the text would dwarf every other export on the platform. What is stored is the REGISTRATION EVENT: who is registering, under which form, whether it is an amendment, against which `333-` file number, and - where the filing states it in a machine readable way - the Rule 457 fee table: what is being registered, how much of it, at what maximum aggregate offering price, and the fee paid on it. See `docs/datasets/edgar_registration_statements.md` for the source mapping and `docs/availability/edgar_registration_statements.md` for the availability evidence.
One row per One row per registration statement, keyed by its ACCESSION. The key is the accession and NOT the archive path, because EDGAR indexes one filing under one path PER associated CIK and a co-registered Securities Act filing associates every guarantor: accession 0001193125-12-272275 (Mueller Water Products plus 24 guarantor subsidiaries on 333-182160) is 25 separate rows of the 2012-06-15 daily index, and 0001193125-24-096283 (Extra Space Storage plus three) is 4 rows of the 2024-04-15 index. Measured across five dissemination days spanning 2012-2026, 254 index rows carry 219 distinct registration statements. Keying on the path would count one shelf registration 25 times and turn a single issuance event into a fabricated wave of them. The co-registrants are a child list (co_registrants), never extra rows..
Point-in-time availability
Every Obscura dataset carries available_date: the calendar day the publisher made the row
available, day-of, with no session rounding. It is the one column a backtest filters on, and it means the
same thing on every dataset in the catalog.
For edgar_registration_statements: filing_join: available_date is the EDGAR DISSEMINATION day, taken from the bronze object's own day partition, and never from the submission's own FILED AS OF DATE. WHY: a registration statement carries no embargo - it is readable the day EDGAR disseminates it - but SEC BACK-DATES the legal filing date, and on this family the back-dated field is also the one the form's own legal effectiveness keys on. MEASURED (evidence class B, docs/availability/edgar_registration_statements.md): the S-8 0001104659-25-068083 (JIADE Ltd) states FILED AS OF DATE 20250715 and EFFECTIVENESS DATE 20250715, was not ACCEPTED by EDGAR until 2025-07-16 14:56:51, is ABSENT from the 2025-07-15 daily index and PRESENT in the 2025-07-16 one. Dating that row from its header would publish a registration a full day before anyone outside EDGAR could learn it existed.
Refresh cadence
Obscura refreshes edgar_registration_statements every 6 hours - the most frequent scheduled job that re-collects or re-exports it. This is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when a row became public is recorded per row in available_date.
Schema - 27 columns
The full public column list for edgar_registration_statements, with the meaning of every field. The same
schema is served unauthenticated at https://api.obscura.trade/v1/catalog/edgar_registration_statements.
| Column | Type | Description |
|---|---|---|
| accession | text · not null | PK. SEC accession number of the registration statement, e.g. `0001193125-26-300909`. The key is the accession, not the archive path: EDGAR lists a co-registered filing under one path per guarantor CIK. |
| filename | text · not null | The PRIMARY registrant's SEC EDGAR Archives path for this filing (`edgar/data/{cik}/{accession}.txt`), derived from the payload's own registrant blocks rather than from whichever index row was walked - so it is the same value on every ingestion path. The join key into `edgar_filings`. |
| available_date | date | Public availability date: the EDGAR DISSEMINATION day, recovered from the bronze object's own day partition. This is the point-in-time anchor and the only date a backtest may key on. |
| accepted_at | timestamp with time zone | When SEC ACCEPTED the submission (`<ACCEPTANCE-DATETIME>`), US-Eastern wall clock stored under a UTC type. Deliberately NOT the availability date: an acceptance after the 5:30pm ET cutoff is disseminated the next morning. NULL on a row ingested from the dissemination feed rather than from Archives - the feed's PDS envelope does not carry this stamp, so a NULL here is a fact about the envelope and not a decoder gap. |
| filed_as_of | date | SEC's LEGAL filing date (`FILED AS OF DATE`) - the date the registration is deemed filed for statutory purposes. Kept for parity with `edgar_filings`; NEVER an availability date, because SEC back-dates it (measured one day on `0001104659-25-068083`, which was not accepted until the following afternoon). |
| effectiveness_date | date | The day the registration became LEGALLY EFFECTIVE (`EFFECTIVENESS DATE:` / `<EFFECTIVENESS-DATE>`), i.e. the day securities could actually be sold off it. Present on the forms that are effective UPON FILING - `S-3ASR` (Rule 462(e)), `S-8` (Rule 462(a)) and `S-8 POS` - and absent on the forms SEC must declare effective (`S-1`, `S-1/A`, `S-3`, `S-3/A`), whose effectiveness arrives later in a separate `EFFECT` notice carried by `edgar_effectiveness_notices`. A NULL here is therefore a fact about the form family, not a gap. It is NOT an availability date and can precede one: it inherits `filed_as_of`'s back-dating, so a registration can be legally effective a day before anyone outside EDGAR could read that it exists. |
| form_type | text · not null | The form exactly as filed - `S-1`, `S-1/A`, `S-3`, `S-3/A`, `S-3ASR`, `S-8`, `S-8 POS`. The single column that separates an IPO from a shelf from an employee plan, kept verbatim so no interpretation is baked into it. |
| registration_type | text · not null | What the filing registers, as a closed vocabulary derived from `form_type` and CHECKed against it in the migration so the two can never drift: `ipo_or_resale` (`S-1`, `S-1/A` - an IPO or a resale registration for existing holders), `shelf` (`S-3`, `S-3/A` - a delayed-basis shelf that SEC must declare effective), `automatic_shelf` (`S-3ASR` - a well-known seasoned issuer's shelf, effective on filing and unlimited in amount), `employee_plan` (`S-8`, `S-8 POS` - shares reserved for a stock or benefit plan). This is the dilution TYPE: `employee_plan` is routine compensation overhang, `ipo_or_resale` is new float hitting the market. |
| is_amendment | boolean · not null | TRUE when the filing amends an earlier registration rather than opening a new one - `S-1/A`, `S-3/A` (pre-effective amendments) and `S-8 POS` (a post-effective amendment, most often a DEREGISTRATION of unsold plan shares after a merger). A consumer counting new issuance must exclude these or it will count the same offering once per revision: `0001193125-24-096372` and its siblings are five separate amendments of one registration. |
| cik | bigint | Central Index Key of the PRIMARY registrant - the company actually registering the securities. Chosen by FILE NUMBER, not by header position: on a co-registered shelf the parent holds the bare `333-NNNNNN` and each guarantor a `-NN` suffix, and the parent is NOT reliably written first (on `0001193125-12-272275` the first of 25 blocks is *AnvilStar, LLC* on `333-182160-24`; Mueller Water Products, the parent, is third). |
| company_name | text | Primary registrant's name as EDGAR conforms it, e.g. `DELTA AIR LINES, INC.`. |
| sic_code | integer | Primary registrant's SIC code, read from ITS OWN header block rather than from the first block in the header. Scoping is load-bearing here: on the Griffon Corp `S-3/A` `0000930413-12-003611` two of six registrant blocks state a SIC and they DISAGREE (parent `3442`, co-registrant `3524`), so an unscoped read records a guarantor subsidiary's industry as the issuer's. NULL when the primary's own block states none. |
| state_of_incorporation | text | Primary registrant's state or country of incorporation from its own header block, e.g. `DE`, `MD`, `E9` (Cayman) - the offshore codes are what mark a foreign-domiciled issuer registering into the US market. |
| file_number | text | The Securities Act registration file number, e.g. `333-297385`, with any co-registrant `-NN` suffix removed so every party to one registration resolves to the SAME number. This is the spine of the issuance graph: it joins BACK to nothing (the registration starts here), FORWARD to the `EFFECT` notice that declares it effective in `edgar_effectiveness_notices`, and onward to every `424B*` takedown priced off the shelf in `edgar_structured_notes`. |
| co_registrants | jsonb · not null | JSON array of `{cik, name, file_number}` for the co-registrants - the guarantor subsidiaries carried on a `333-NNNNNN-NN` suffix of the primary's registration. Empty array on an ordinary single-registrant filing, which is the large majority. Kept as a child list because these are parties to ONE registration, not separate registrations. |
| co_registrant_count | integer · not null | Number of co-registrants (0 on a plain filing, 24 on the Mueller Water Products shelf). A direct proxy for a guaranteed-debt structure, and the column that guards against fanning one registration into 25 - the migration CHECKs it equals the array length. |
| fee_table_format | text · not null | HOW the Rule 457 filing-fee table (Exhibit 107, `EX-FILING FEES`) is expressed on THIS filing, and therefore whether the amounts below could be read at all. A closed vocabulary of three: `inline_xbrl` (the exhibit carries `ffd:` inline-XBRL facts, and every amount below comes from them); `untagged_html` (the exhibit is present but is a plain HTML grid with no facts, so every amount below is NULL); `absent` (no fee exhibit in the submission - the universal shape before 2022 and the normal shape on an amendment that registers nothing new). Recorded rather than inferred, because a NULL amount means three different things and a consumer must be able to tell them apart. |
| total_offering_amount | numeric | Total maximum aggregate offering price across the whole fee table (`ffd:TtlOfferingAmt`), in USD - **the headline size of the registration**. NULL unless `fee_table_format = 'inline_xbrl'`; the migration CHECKs that biconditional, so a NULL is always "not machine-readable on this filing", never "stated as zero". A genuine `0.00` is a different fact and a real one: see `registers_unspecified_amount`. |
| total_fee_amount | numeric | Total registration fee computed on the table (`ffd:TtlFeeAmt`), in USD. At the statutory rate this is a second, independent measure of the offering's size and a cross-check on `total_offering_amount`. NULL exactly when the table is not inline XBRL. |
| total_previously_paid_amount | numeric | Fee already paid on securities carried over from a prior registration (`ffd:TtlPrevslyPdAmt`), in USD. Non-zero marks a Rule 415(a)(6) re-registration of unsold securities rather than a genuinely new offering - the amount is being re-shelved, not newly created. |
| total_offset_amount | numeric | Total fee offsets claimed against earlier filings (`ffd:TtlOffsetAmt`), in USD. |
| net_fee_amount | numeric | Fee actually due with this filing (`ffd:NetFeeAmt`), in USD - `total_fee_amount` less offsets and previously-paid amounts. Zero on an automatic shelf, which pays as it takes down. |
| registers_unspecified_amount | boolean · not null | TRUE when the fee table registers an INDETERMINATE amount rather than a stated one - the filing claims Rule 457(r) (a well-known seasoned issuer's automatic shelf, which registers an unspecified amount and pays the fee at each takedown) or Rule 456(b). This is what makes `total_offering_amount = 0.00` meaningful instead of looking like a parse failure: the Delta Air Lines `S-3ASR` `0001683168-26-005455` registers seven classes of security with `ffd:Rule457rFlg` on every one and a total of exactly `0.00`, and that zero is the filing's true statement about itself. A consumer summing registered amounts MUST exclude these rows or it will read the largest shelves on EDGAR as the smallest. |
| securities | jsonb · not null | JSON array of the fee table's per-security rows, one object per offering line, each `{security_type, security_title, fee_rule, amount_registered, max_offering_price_per_security, max_aggregate_offering_price, fee_rate, fee_amount, previously_paid, carry_forward_form, carry_forward_file_number, carry_forward_effective_date}`. This is WHAT is being registered - `Equity`/`Debt`/`Other`/`Unallocated (Universal) Shelf`, with the class title as the registrant wrote it (`Common stock, par value $0.01 per share`). Empty array unless the table is inline XBRL: a per-row read of the untagged HTML grid would require aligning a value to its column header, which is exactly the alignment this parser refuses to guess at. |
| security_line_count | integer · not null | Number of offering lines in `securities` (1 on a plain single-class registration, 7 on the Delta shelf, 10 on a shelf that also carries securities forward under Rule 415(a)(6)). The migration CHECKs it equals the array length. |
| document_count | integer | Number of documents in the submission (`PUBLIC DOCUMENT COUNT:`) - 1 on a bare `S-8 POS` deregistration, 21 on a shelf with exhibits and an XBRL package. A size proxy for a filing whose text is deliberately not stored. |
| document_types | jsonb · not null | Ordered JSON array of the submission's document types, e.g. `["S-3ASR","EX-5.1","EX-15","EX-23.1","EX-25.1","EX-FILING FEES","GRAPHIC"]`. The manifest is kept; the bodies are not. It is what makes `fee_table_format = 'absent'` auditable - a reader can see for themselves that no `EX-FILING FEES` member was in the filing. |
Access edgar_registration_statements
Two delivery paths, one identifier. Both require an Obscura account and an active subscription; the catalog entry and the schema above are public.
import obscura
client = obscura.Client("obs_live_…")
df = client.query(
dataset="edgar_registration_statements",
symbols=["NVDA", "AAPL"],
start="2024-01-01",
)Create a free account Browse all 122 datasets
Frequently asked questions
What is in the edgar_registration_statements dataset?
Securities registration statements - S-1 and S-1/A for IPOs and resale registrations, S-3 and S-3ASR for shelf offerings by seasoned issuers, S-8 for employee benefit plans - one row per filing with the registrant, what class of securities is being registered, whether it is an amendment, and the Rule 457 fee table's stated offering amount where the filer tagged an Exhibit 107. This is the issuance pipeline BEFORE the shares exist, which is what separates it from edgar_dilution_metrics: that measures dilution already reported on the balance sheet, this shows what a company has registered the right to sell. One **Securities Act registration statement** - the filing in which a company registers securities for sale, and therefore the earliest dated, public statement that new shares are coming. The form says what kind of issuance it is: an `S-1` registers an IPO or a resale, an `S-3` a shelf for a seasoned issuer, an `S-3ASR` an *automatic* shelf that is effective the moment it is filed, an `S-8` a share reserve for an employee benefit plan. Together they are the **issuance pipeline**, and they lead `edgar_dilution_metrics` by design: dilution metrics measure share count after it has moved, while a registration statement is filed before a single share is sold. The prospectus itself is NOT stored - an `S-1` runs to 33 MB and the text would dwarf every other export on the platform. What is stored is the REGISTRATION EVENT: who is registering, under which form, whether it is an amendment, against which `333-` file number, and - where the filing states it in a machine readable way - the Rule 457 fee table: what is being registered, how much of it, at what maximum aggregate offering price, and the fee paid on it. See `docs/datasets/edgar_registration_statements.md` for the source mapping and `docs/availability/edgar_registration_statements.md` for the availability evidence.
How do I avoid look-ahead bias with edgar_registration_statements?
Filter on edgar_registration_statements.available_date, the day the publisher made the row public. For this dataset that date is derived as follows - filing_join: available_date is the EDGAR DISSEMINATION day, taken from the bronze object's own day partition, and never from the submission's own FILED AS OF DATE. WHY: a registration statement carries no embargo - it is readable the day EDGAR disseminates it - but SEC BACK-DATES the legal filing date, and on this family the back-dated field is also the one the form's own legal effectiveness keys on. MEASURED (evidence class B, docs/availability/edgar_registration_statements.md): the S-8 0001104659-25-068083 (JIADE Ltd) states FILED AS OF DATE 20250715 and EFFECTIVENESS DATE 20250715, was not ACCEPTED by EDGAR until 2025-07-16 14:56:51, is ABSENT from the 2025-07-15 daily index and PRESENT in the 2025-07-16 one. Dating that row from its header would publish a registration a full day before anyone outside EDGAR could learn it existed. A query of the form WHERE available_date <= '<as-of date>' never sees a row before it existed.
In what formats can I get edgar_registration_statements?
As a Parquet bulk export (POST https://api.obscura.trade/v1/download) or as JSON from the typed query API (POST https://api.obscura.trade/v1/query), both with dataset="edgar_registration_statements". The column schema is public at https://api.obscura.trade/v1/catalog/edgar_registration_statements.
Can I filter edgar_registration_statements by company or symbol?
Yes. edgar_registration_statements carries cik, the column the API's symbols filter resolves against.
How often is edgar_registration_statements updated?
Obscura refreshes edgar_registration_statements on a every 6 hours schedule - that is the most frequent scheduled job that re-collects or re-exports the table. It is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when the publisher makes a row available is described by the availability rule above, and is recorded per row in available_date.