Parsing 8-K item codes programmatically: a clean API

The 8-K is the SEC's "something just happened" form. Companies file one within four business days of a material event, and the item codes attached to it tell you what kind of event without reading a word of the document. Item 2.02 is an earnings release. 5.02 is an executive leaving or arriving. 1.01 is a material agreement signed. 1.05 is a cybersecurity breach. If you trade catalysts or build screeners, the item code is the cheapest, fastest signal EDGAR produces.

The problem is the shape it arrives in.

What EDGAR actually gives you

Pull a company's submissions feed from data.sec.gov and the item codes come back as a bare comma-joined string, parallel-indexed against the form array:

{
  "filings": {
    "recent": {
      "form":  ["8-K", "4", "8-K", "10-Q"],
      "items": ["2.02,9.01", "", "5.02", ""],
      "acceptanceDateTime": ["2026-06-18T20:00:24.000Z", "...", "...", "..."]
    }
  }
}

No labels. No indication that 2.02 is an earnings drop and 9.01 is just the exhibit index attached to it. No flag for whether the filing as a whole is worth waking up for. To make this usable you end up doing three jobs:

1. Maintain a code-to-label map. There are roughly two dozen live 8-K item codes, and the SEC revises them — 1.05 (material cybersecurity incident) was added in 2023, for example. A stale dict silently mislabels new events.
2. Decide which codes are material. This is the judgment call. An 8-K carrying only 9.01 (financial statements and exhibits) or 5.07 (results of a shareholder vote) is usually noise. One carrying 2.02, 5.02, or 1.01 usually is not. You need a defensible rule, not a vibe.
3. Gate on time correctly. The useful timestamp is acceptanceDateTime (when the filing actually went public), not filingDate (a calendar date). Sort on the wrong one and your "newest" ordering is off by hours.

It is maintainable. It is also the kind of code that rots — you write it once, it works, and eight months later a new item code or a schema tweak quietly drops events on the floor.

The item codes that matter

Here is the working split. Presence of any code in the first group flags the filing material:

Code	Meaning	Material
1.01	Entry into a material definitive agreement	yes
1.03	Bankruptcy or receivership	yes
1.05	Material cybersecurity incident	yes
2.01	Completion of acquisition or disposition of assets	yes
2.02	Results of operations (earnings)	yes
2.06	Material impairment	yes
3.01	Delisting notice or listing-rule failure	yes
4.02	Non-reliance on previously issued financials	yes
5.01	Change in control	yes
5.02	Director/officer departure or appointment	yes
7.01	Regulation FD disclosure	yes
8.01	Other events	yes
5.03	Amendments to bylaws; fiscal year change	no
5.07	Submission of matters to a shareholder vote	no
9.01	Financial statements and exhibits	no

The full set is wider; this is the part you reach for most. The point is that the materiality call belongs in the data layer, applied consistently, not re-derived in every consumer.

The shortcut: one endpoint, already typed

EDGAR Events parses the item string, labels every code, sets a per-filing material flag, and sorts on acceptance time. You ask for what you want:

curl -s -H "X-API-Key: $EDGAR_KEY" \
  "https://api.edgarevents.com/filings?ticker=NVDA,TSLA&type=8-K&material=true"

A returned event (a real NVDA 8-K from the live feed):

{
  "event_type": "8-K",
  "form": "8-K",
  "ticker": "NVDA",
  "company": "NVIDIA CORP",
  "cik": "0001045810",
  "filed_date": "2026-06-18",
  "accepted": "2026-06-18T20:00:24.000Z",
  "report_date": "2026-06-15",
  "items": [
    { "code": "8.01", "label": "other events", "material": true },
    { "code": "9.01", "label": "financial statements and exhibits", "material": false }
  ],
  "summary": "8-K: 8.01 (other events); 9.01 (financial statements and exhibits)",
  "material": true,
  "accession": "0001193125-26-275783",
  "filing_url": "https://www.sec.gov/Archives/edgar/data/1045810/000119312526275783/d48176d8k.htm",
  "source": "submissions"
}

Each item carries its own code, label, and material boolean; the filing's top-level material is true if any item is material. filing_url points at the actual document if you want to go deeper, and accepted is the real public-timestamp to sort and gate on.

Narrowing the firehose

Filter by item code, by materiality, by lookback window:

# Just executive changes across a watchlist
curl -s -H "X-API-Key: $EDGAR_KEY" \
  "https://api.edgarevents.com/filings?ticker=AAPL,MSFT,NVDA,AMD&type=8-K&item=5.02"

# Everything material for one ticker in the last 24 hours
curl -s -H "X-API-Key: $EDGAR_KEY" \
  "https://api.edgarevents.com/filings/TSLA?type=8-K&material=true&hours=24"

item filters to a specific code, material=true drops the routine filings, hours sets the lookback (up to a week). The single-ticker form /filings/{ticker} is the same data scoped to one company.

Push, don't poll

For live catalyst work, register a webhook and only get the material 8-Ks:

curl -s -X POST -H "X-API-Key: $EDGAR_KEY" -H "Content-Type: application/json" \
  -d '{"event_types":["8-K"],"tickers":["NVDA","TSLA","AMD"],"material_only":true,"url":"https://your-app.com/hooks/edgar"}' \
  "https://api.edgarevents.com/webhooks"

Matching filings are POSTed within seconds, each signed with HMAC-SHA256 in the X-Edgar-Signature header so you can verify authenticity before acting on it.

Do you need this?

If you are comfortable owning the item-code map, the materiality rule, the SEC rate-limit throttle, and a polling loop, libraries like edgartools get you most of the way for free. The trade you are making by paying is maintenance and latency: someone else keeps the code table current, applies the materiality call the same way every time, and pushes you a signed event instead of leaving you to diff the submissions feed on a timer.

It is $29/month, self-serve, live from data.sec.gov, cancel anytime. Grab a key at edgarevents.com; the full interactive reference is at api.edgarevents.com/docs.