# SEC EDGAR Reg A+ Offering Lifecycle & Outcomes Monitor (`malonestar/reg-a-plus-lifecycle-monitor`) Actor

Track SEC Regulation A / Reg A+ offerings end to end from EDGAR, keyless: 1-A offerings and 253G2 circulars, 1-K annual reports, 1-U material events and 1-Z exit reports with sell-through. Feed, issuer, outcomes and delta modes — the outcome lifecycle the offering-only incumbents never sell.

- **URL**: https://apify.com/malonestar/reg-a-plus-lifecycle-monitor.md
- **Developed by:** [Kyle Maloney](https://apify.com/malonestar) (community)
- **Categories:** Business, Developer tools, Agents
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $5.50 / 1,000 reg a+ lifecycle results

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Reg A+ Offering Lifecycle & Outcomes Monitor (SEC EDGAR)

Track **Regulation A / Reg A+ offerings end to end** — not just the raise, but what
happened after it. This actor reads SEC EDGAR's full-text search API plus each filing's
structured XML and returns one clean, flat row per lifecycle event:

- **1-A** — the offering statement (tier, price, aggregate offering, a one-year financial snapshot, auditor, jurisdictions)
- **253G2** (and 253G1/G3/G4) — the qualified offering circular
- **1-K** — the annual report (the "did they survive / are they still reporting" signal)
- **1-SA** — the semiannual report
- **1-U** — the current report / material events (with the item codes)
- **1-Z** — the exit report (how much of the qualified offering actually **sold**, net proceeds, holders of record)

Reg A+ lets a company raise up to **$75M** from the public — a much larger universe than
Regulation Crowdfunding's $5M. Existing tools sell the **offering** (Form 1-A) and stop
there. **Nobody sells the outcome lifecycle.** This actor does: it follows each issuer from
offering statement through annual reports to exit, so you can see who is still reporting,
who quietly went dark, and how their raises actually turned out.

Keyless. No login, no scraping of anti-bot pages — just SEC EDGAR, the authoritative source.

### Who it's for

- **Reg A+ investors and analysts** — screen the whole market: which offerings qualified, which are still filing annual reports, which sold only a fraction of what they qualified, which filed a 1-Z and shut down.
- **Crowdfunding platforms (StartEngine, Republic/DealMaker, Dalmore, etc.)** — monitor your issuers' post-raise filings and benchmark against the market.
- **Securities lawyers & compliance** — a dated, structured feed of every Reg A lifecycle event, filterable by state and form type.
- **Journalists & researchers** — the raw record of who raised, how much, and what became of them.
- **B2B lead generation** — funded, growth-stage companies with public financials, addresses, auditors and legal counsel, one row each.
- **AI agents** — a clean, self-describing MCP tool (see below).

### Modes

| Mode | What it returns |
|------|-----------------|
| **feed** | Reg A lifecycle events across form types in a date window, filterable by `formTypes`, `state` and a full-text `platformQuery`. XML enrichment is opt-in. |
| **outcomes** | Form **1-K** annual reports (always XML-enriched) — the survival / still-reporting signal, with reporting period, fiscal year end, shell-company flag and securities outstanding. |
| **issuer** | Every Reg A lifecycle filing for one company (`cik` or `issuerQuery`), XML-enriched — the full arc for a single issuer. |
| **delta** | Only filings **new since your last run** for this scope, tracked in a named key-value store. The first run stores a baseline and fails with an explanatory message rather than billing the whole feed as new. |

### Example input

Recent Reg A+ lifecycle events with structured detail:

```json
{
  "mode": "feed",
  "startDate": "2026-08-01",
  "formTypes": ["1-A", "253G2", "1-K", "1-SA", "1-U", "1-Z"],
  "enrichXml": true,
  "maxResults": 200
}
```

One issuer's full lifecycle by CIK:

```json
{ "mode": "issuer", "cik": "2083128", "maxResults": 200 }
```

Who's still filing annual reports (the survival signal):

```json
{ "mode": "outcomes", "startDate": "2026-01-01", "maxResults": 200 }
```

Only filings that appeared since your last run (schedule this):

```json
{ "mode": "delta", "formTypes": ["1-A", "1-Z"], "maxResults": 500 }
```

### Output fields (highlights)

Every row is flat and CSV/JSON friendly. Full documentation is in the dataset schema.

- **Identity:** `form`, `form_base`, `is_amendment`, `event_class`, `accession`, `cik`, `issuer_name`, `file_date_iso`, `biz_state`, `biz_city`, `incorporation_state`, `filing_index_url`, `primary_doc_url`
- **Offering (1-A):** `offering_tier` (Tier1/Tier2), `securities_offered_type`, `price_per_security`, `security_offered_count`, `issuer_aggregate_offering_usd`, `total_aggregate_offering_usd`, `outstanding_securities`, `num_offering_jurisdictions`, `financial_statement_audit_status`, `auditor_name`, `legal_service_provider`
- **Financial snapshot (1-A, single most-recent period):** `fin_total_assets`, `fin_total_revenues`, `fin_net_income`, `fin_total_stockholder_equity`, `fin_cash_equivalents`, `fin_long_term_debt`, `fin_is_profitable`
- **Annual report (1-K):** `reporting_period_iso`, `fiscal_year_end_iso`, `shell_company_flag`, `issued_securities_titles`
- **Exit (1-Z):** `exit_securities_qualified`, `exit_securities_sold`, **`exit_sell_through_pct`** (how much of the qualified offering actually sold), `exit_issuer_net_proceeds_usd`, `exit_approx_record_holders`, `exit_offering_qualification_date_iso`
- **Current report (1-U):** `current_report_items` (material-event item codes)
- **Provenance & honesty:** `xml_status`, `data_source`, `drift_gate_status`, `matched_total`, `results_truncated`, `run_max_results_cap`

#### How to read a null

A null financial or date means **not reported, not fetched, or not applicable to that form** —
**never** a fabricated zero. A `0` means the filing literally reported `0.00`. Forms that file an
HTML/PDF primary document (253G2, 1-SA, 1-U, DOS) carry `xml_status = "not_applicable"` and their
structured columns are null by design.

### Reg A vs Reg CF — one important difference

If you also use our Reg CF (crowdfunding) monitor, note this: Regulation Crowdfunding's Form C-AR
annual report carries **structured two-year financials** in its XML. **Regulation A's 1-K does
not** — Reg A audited financial statements are filed as HTML/PDF exhibits, not machine-readable
fields. So on this actor the financial columns come from the **1-A offering** (a one-year
snapshot at the time of the raise) and the outcome economics come from the **1-Z exit report**
(securities qualified vs sold, net proceeds, record holders). The 1-K is the **continuation /
survival** signal — that the issuer is still meeting its ongoing reporting obligations — plus its
securities-outstanding detail.

### Trust & reliability

- **Live drift gate before any billable row.** Every run first verifies the source three ways: a floor check on the live 1-A corpus, a positive canary (a real, pinned 1-A filing that must still parse to the same issuer, tier and financials), and a negative control (a nonsense form must return exactly zero). If the source has drifted or is unavailable, the run **fails loudly and bills nothing**.
- **The state filter is post-validated on every row.** EDGAR's `locationCode` (singular) parameter is silently ignored server-side; we use `locationCodes` (plural) *and* re-check every returned row, so a `TX`-only query can never quietly return a national feed.
- **A hard, single billing cap.** `maxResults` bounds exactly how many rows are emitted and billed, enforced by one code path with a tripwire; every row carries `matched_total` and `results_truncated` so a capped answer is never mistaken for a complete one.
- **No silent zero.** An outage, an unparseable response or an HTML rate-limit page fails the run — it never becomes a green, empty "no filings" answer.

### Pricing & cost

Pay-per-result: you are billed per row emitted (one lifecycle event = one row), capped by your
`maxResults`. A typical scoping run of 200 rows costs a small, predictable amount; set `maxResults`
low to preview. Failed runs (source unavailable, bad input) emit nothing and bill nothing beyond
the negligible actor start. XML enrichment adds one polite EDGAR request per 1-A/1-K/1-Z row
(slower, same per-row price).

### Use as an MCP tool

This actor is callable by AI agents (Claude, Cursor, etc.) via `mcp.apify.com`. Its input and
output fields are fully described, so an agent can pick `mode`, set a date window or a `cik`, and
chain the results. Example agent prompt:

> "Using the Reg A+ lifecycle monitor, list every Reg A offering (form 1-A) filed in Texas in 2026
> with its tier, aggregate offering amount and net income, then show which of those issuers has
> since filed a 1-Z exit report and what percentage of the qualified offering actually sold."

### FAQ

**Where does the data come from?** SEC EDGAR full-text search (`efts.sec.gov`) for the filing
index, and each filing's `primary_doc.xml` on `sec.gov/Archives` for the structured detail. It is
the authoritative, public record.

**Is it keyless?** Yes. No API key, no account. Requests carry the SEC fair-access User-Agent and
are rate-limited politely.

**Why is `exit_sell_through_pct` so interesting?** It is the single clearest outcome number: a 1-Z
exit report states how many securities were *qualified* and how many actually *sold*. A raise that
qualified 15,000 units and sold 2,382 has a 15.9% sell-through — a very different story from the
offering statement alone.

**Can I monitor only new filings?** Yes — use `delta` mode on a schedule. The first run seeds a
baseline; subsequent runs return only genuinely new lifecycle events for that scope.

**What about Form D or QUALIF filings?** Form D is Regulation D, a different regime, and is excluded.
The SEC's `QUALIF` qualification notice is filed under a special SEC filer CIK (not the issuer's), so
it is deliberately excluded to keep the dataset issuer-centric — the issuer-filed 253G2 is the
qualification signal instead.

# Actor input Schema

## `mode` (type: `string`):

What to return. "feed" = Regulation A / Reg A+ lifecycle events (1-A offering statements, 253G2 qualified offering circulars, 1-K annual reports, 1-SA semiannual reports, 1-U current reports, 1-Z exit reports) in a date window. "outcomes" = Form 1-K annual reports with issuer, reporting period, fiscal year end and securities-outstanding detail from each filing's XML — the survival / still-reporting signal (note: Reg A 1-K financial statements are filed as HTML/PDF exhibits, NOT structured XML, so financial columns are populated from the 1-A offering, not the 1-K). "issuer" = every Reg A lifecycle filing for one company (by cik or issuerQuery), XML-enriched. "delta" = only filings new since your last run for this scope, tracked in the named key-value store 'reg-a-plus-lifecycle-baseline'; the FIRST delta run stores a baseline and fails with an explanatory message rather than billing the whole feed as new.

## `formTypes` (type: `array`):

Which Reg A form types to include (feed and delta modes; outcomes mode always uses 1-K only). Allowed values: 1-A (offering statement), 253G1 / 253G2 / 253G3 / 253G4 (qualified offering circular), 1-K (annual report), 1-SA (semiannual report), 1-U (current report / material events), 1-Z (exit report), DOS (draft offering statement). Leave empty for the default lifecycle spine: 1-A, 253G2, 1-K, 1-SA, 1-U, 1-Z. Amendments (e.g. 1-A/A) are included under their base form and flagged is\_amendment.

## `startDate` (type: `string`):

Only include filings filed on or after this date. STRICTLY YYYY-MM-DD (e.g. 2026-01-01) — slash dates, month names and compact dates are rejected with a loud failure because they cannot be applied unambiguously. Leave blank for no lower bound (Reg A+ began 2015-06-19).

## `endDate` (type: `string`):

Only include filings filed on or before this date. STRICTLY YYYY-MM-DD. Leave blank for no upper bound (today). An unusable value fails the run loudly; nothing is billed.

## `state` (type: `string`):

Optional 2-letter US state/territory code (e.g. TX) filtering on the issuer's principal business address. Applied server-side via the EDGAR locationCodes parameter AND re-validated on every returned row — if EDGAR ever stops applying the filter the run fails loudly instead of shipping a national feed labelled as one state.

## `platformQuery` (type: `string`):

Optional crowdfunding platform, broker-dealer or service-provider name, e.g. "StartEngine", "DealMaker" or "Dalmore Group". Matched as an exact phrase via EDGAR full-text search against the filing documents (Reg A does not carry a structured platform field, so this is a document-text match, not a structured filter). Use the platform's legal name as it appears in offering circulars.

## `cik` (type: `string`):

SEC CIK number of the issuer for issuer mode, with or without leading zeros (e.g. 2083128). Find it on any EDGAR filing page. issuer mode requires cik or issuerQuery.

## `issuerQuery` (type: `string`):

Company-name phrase for issuer mode when you do not know the CIK, e.g. "Elio Motors". Matched as a phrase via EDGAR full-text search; prefer cik for an exact match.

## `enrichXml` (type: `boolean`):

In feed/delta modes, also fetch each filing's primary\_doc.xml to add the structured fields. 1-A adds offering tier, price, aggregate offering, jurisdiction count, auditor, and a one-year financial snapshot (total assets, revenue, net income, equity); 1-K adds reporting period, fiscal year end, shell-company flag and securities outstanding; 1-Z adds securities qualified vs sold, net proceeds, record holders and exit sell-through. Adds one polite EDGAR request per 1-A/1-K/1-Z row (slower). 253G2/1-SA/1-U/DOS have no structured XML (xml\_status=not\_applicable). outcomes and issuer modes always enrich. When off, those columns are null with xml\_status="not\_fetched" — null means NOT FETCHED, never "none".

## `maxResults` (type: `integer`):

Hard cap on rows emitted AND billed this run (newest filings first). Every row carries matched\_total and results\_truncated so a capped answer is never mistaken for a complete one.

## Actor input object example

```json
{
  "mode": "feed",
  "formTypes": [
    "1-A",
    "253G2",
    "1-K",
    "1-SA",
    "1-U",
    "1-Z"
  ],
  "startDate": "2026-01-01",
  "enrichXml": false,
  "maxResults": 200
}
```

# Actor output Schema

## `results` (type: `string`):

The default dataset.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "mode": "feed",
    "formTypes": [
        "1-A",
        "253G2",
        "1-K",
        "1-SA",
        "1-U",
        "1-Z"
    ],
    "startDate": "2026-01-01",
    "maxResults": 200
};

// Run the Actor and wait for it to finish
const run = await client.actor("malonestar/reg-a-plus-lifecycle-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "mode": "feed",
    "formTypes": [
        "1-A",
        "253G2",
        "1-K",
        "1-SA",
        "1-U",
        "1-Z",
    ],
    "startDate": "2026-01-01",
    "maxResults": 200,
}

# Run the Actor and wait for it to finish
run = client.actor("malonestar/reg-a-plus-lifecycle-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "mode": "feed",
  "formTypes": [
    "1-A",
    "253G2",
    "1-K",
    "1-SA",
    "1-U",
    "1-Z"
  ],
  "startDate": "2026-01-01",
  "maxResults": 200
}' |
apify call malonestar/reg-a-plus-lifecycle-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,malonestar/reg-a-plus-lifecycle-monitor"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/iDJsodRgSyecDrsfq/builds/4fwZ6Q7fFN4b3ZhyG/openapi.json