SEC EDGAR Filings API - Real-Time 8-K/10-K Filing Monitor avatar

SEC EDGAR Filings API - Real-Time 8-K/10-K Filing Monitor

Pricing

from $4.00 / 1,000 filing records

Go to Apify Store
SEC EDGAR Filings API - Real-Time 8-K/10-K Filing Monitor

SEC EDGAR Filings API - Real-Time 8-K/10-K Filing Monitor

Real-time SEC EDGAR filing alerts (8-K/10-K/10-Q/Form 4) via the official data.sec.gov API - a fraction of the cost of $300+/mo commercial SEC data feeds. No API key.

Pricing

from $4.00 / 1,000 filing records

Rating

0.0

(0)

Developer

Moose & Raven

Moose & Raven

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

0

Monthly active users

9 days ago

Last modified

Categories

Share

SEC EDGAR Filings API - Real-Time 8-K/10-K Filing Monitor (JSON)

Investors and analysts tracking a watchlist of public companies, insider-trading researchers monitoring Form 4 filings, competitive-intelligence and compliance teams who need to know the moment a company files an 8-K or 10-K, and fintech/data platforms building their own filing feed all use this actor to stop manually refreshing SEC EDGAR by hand. Point it at a list of tickers or CIKs in companies, turn on monitorMode, and each scheduled run returns only the filings that are genuinely new since the last check - as structured JSON filing records you can pipe straight into an alert, dashboard, or database, instead of a person checking EDGAR's website every morning.

Real-time monitoring of SEC EDGAR for new company filings (10-K, 10-Q, 8-K, Form 4 insider transactions, or any other form type) and full-text search matches, via the official data.sec.gov and efts.sec.gov APIs - no API key, no account, no scraping. Optional incremental monitor mode tracks new filings across scheduled runs, so you can get alerted as soon as a company files. Because it runs on the free, official SEC data service rather than a paid third-party reseller, it's available at a fraction of the cost of commercial SEC data feeds.

Worked example: watching Apple for new 8-K filings

Input:

{"companies": ["AAPL"], "formTypes": ["8-K"], "monitorMode": true}

The first run returns a company-info record plus one filing record per recent 8-K Apple has on file, e.g.:

{"recordType": "filing", "form": "8-K", "accessionNumber": "0000320193-26-000011",
"filingDate": "2026-04-30",
"filingUrl": "https://www.sec.gov/Archives/edgar/data/320193/000032019326000011/aapl-20260430.htm"}

Schedule that same input to run hourly (see section 6 below) and, because monitorMode remembers every accessionNumber already delivered, only genuinely new 8-Ks come back on later runs - so every alert you get represents real news, not Apple's last quarterly filing showing up again.

1. What makes this different

Zero account friction. SEC EDGAR requires no API key and no account at all - the only requirement is a descriptive User-Agent header identifying the requester, which SEC's own fair-access policy publishes and this actor sends on every request (

Moose and Raven support@mooseandraven.com
). SEC EDGAR is the canonical, industry-relied-upon source for U.S. public company filings, with a strong operational track record.

Bundles what's normally scattered across separate tools: company filings (10-K/10-Q/8-K), insider Form 4 transactions, and full-text search across all of EDGAR, in one actor with incremental new-filing monitoring for scheduled runs.

A fraction of the cost of a trading-terminal subscription, if filing alerts are the only feature you need. Benzinga Pro's own pricing page lists plans at "$37/monthly," "$147/monthly," and "$197/monthly" (benzinga.com/pro/pricing) for a broad news/trading terminal that bundles SEC filing alerts as one feature among many. Quiver Quantitative's API pricing page lists its Trader plan - the tier required to unlock Form 4 insider-trading data - at "$75.00 month" ( api.quiverquant.com/pricing). This actor's pay-per-event pricing (see section 7) has no monthly floor, so if SEC filing/Form-4 alerts are genuinely the only thing you need, watching even a large company list here runs a small fraction of either subscription's flat monthly cost. Neither Benzinga Pro nor Quiver Quantitative is a 1:1 replacement for this actor (they bundle real extra tooling - charting, news, scanners, other market data); this is a narrower, cheaper tool for the filing-alert job specifically.

2. How it works

  1. No API key needed. Nothing to register, nothing to configure beyond companies.
  2. Supply companies as ticker symbols (e.g. "AAPL") or raw numeric CIKs - tickers are resolved via SEC's own official ticker-to-CIK mapping file. A ticker/CIK that doesn't resolve is reported as an explicit company-not-found record, never silently skipped.
  3. Choose which formTypes to watch (default: 10-K, 10-Q, 8-K, 4) or leave empty for every filing type on record.
  4. Optional fullTextSearchQuery runs a one-shot keyword search across EDGAR's full-text search index (all companies, not just the ones being watched), optionally restricted by fullTextSearchForms. Automatically paginates up to maxSearchResults (default 1,000). If EDGAR's real total exceeds that cap, an explicit search-truncated record surfaces the true total - a capped search is never reported as if it were exhaustive.
  5. Optional incremental monitor mode: remembers which filings it has already delivered per company (by accession number, via a persistent named key-value store) and only reports genuinely NEW filings on later runs. Charges one monitor-run event in addition to per-filing/per-search-result events.
  6. A failed lookup/fetch is never silently treated as "nothing new." Ticker-resolution, submissions, and full-text-search failures each push an explicit fetch-failed (or rate-limited, if SEC's fair-access limit was tripped) status record naming which company and stage failed. monitor-run is not billed on a run containing any such compromised result.
  7. An unexpectedly-shaped submissions response is treated as an anomaly, not a clean empty result. SEC's own filing-list structure isn't a versioned, guaranteed-stable contract - if it is ever missing the expected fields, this actor flags it rather than silently reporting zero filings for that company.
  8. SEC's 10 requests/second fair-access limit is respected by design: every request this actor makes to *.sec.gov is client-side throttled with a minimum spacing, so a multi-company run should never trip the limit. If it is tripped anyway, that surfaces as an explicit rate-limited record, not a silent gap.

3. Input

FieldTypeNotes
companiesarrayTicker symbols or numeric CIKs - provide at least one of companies or fullTextSearchQuery
formTypesarrayDefault 10-K, 10-Q, 8-K, 4 - leave empty for every form type on record
monitorModebooleanPersistent incremental "new since last run" tracking, by accession number
fullTextSearchQuerystringOne-shot keyword search across ALL of EDGAR's full-text index, not just watched companies
fullTextSearchFormsarrayRestricts the full-text search to specific form types
maxSearchResultsintegerDefault 1,000 - caps the full-text search pull, not the per-company filing list

See the Input tab for the full form with inline descriptions.

4. Output fields

Each dataset item has a recordType of "company-info", "filing", "search-result", "search-truncated", "company-not-found", "fetch-failed", or "rate-limited".

company-info (one per watched company, every run)

FieldTypeNotes
cikstringSEC's own 10-digit Central Index Key, as a string (leading zeros preserved in SEC's own format, stripped here)
tickerstring | nullEchoes the input ticker, null if a raw CIK was supplied
name, sic, sicDescriptionstring | nullLegal name and SEC's own industry classification
exchangesarray of stringe.g. ["Nasdaq"]
stateOfIncorporationstring | nullTwo-letter state code
fiscalYearEndstring | nullMMDD, e.g. "0926"
fetchedAt, sourceApisourceApi is "data.sec.gov/submissions"

filing

FieldTypeNotes
cik, tickerstring | nullSame as above
formstringe.g. "8-K", "10-K", "4"
accessionNumberstringSEC's own stable filing ID, e.g. "0000320193-26-000011" - this is the monitor-mode dedup key
filingDate, reportDatestring | nullYYYY-MM-DD
primaryDocument, primaryDocDescriptionstring | nullThe filing's main document filename and its description
isXBRLbooleanWhether the filing includes machine-readable XBRL data
filingUrlstring | nullDirect link to the primary document on sec.gov, constructed from cik+accessionNumber+primaryDocument
fetchedAt, sourceApisourceApi is "data.sec.gov/submissions"

search-result (from fullTextSearchQuery)

FieldTypeNotes
cikstring | nullThe FIRST CIK associated with the hit - EDGAR's own search index can return multiple CIKs per hit (co-filers); only the first is surfaced as a top-level field, see Limitations
displayNamestring | nullEDGAR's own formatted company/ticker/CIK label, e.g. "CARNIVAL CORP (CCL) (CIK 0000815097)"
form, accessionNumber, fileDate, fileDescriptionSame shape as filing's equivalent fields
fetchedAt, sourceApisourceApi is "efts.sec.gov/LATEST/search-index"

Status records (company-not-found, fetch-failed, rate-limited, search-truncated) each carry a message explaining exactly what happened - read it before treating an absence from the output as a clean "nothing found."

Real sample output

Live-fetched for AAPL (input:

{"companies":["AAPL"],"formTypes":["8-K","10-K"], "fullTextSearchQuery":"climate risk","fullTextSearchForms":["10-K"],"maxSearchResults":5}
) - not a fabricated example:

{
"recordType": "company-info",
"cik": "320193",
"ticker": "AAPL",
"name": "Apple Inc.",
"sic": "3571",
"sicDescription": "Electronic Computers",
"exchanges": ["Nasdaq"],
"stateOfIncorporation": "CA",
"fiscalYearEnd": "0926",
"fetchedAt": "2026-07-18T00:58:09.581Z",
"sourceApi": "data.sec.gov/submissions"
}
{
"recordType": "filing",
"cik": "320193",
"ticker": "AAPL",
"form": "8-K",
"accessionNumber": "0000320193-26-000011",
"filingDate": "2026-04-30",
"reportDate": "2026-04-30",
"primaryDocument": "aapl-20260430.htm",
"primaryDocDescription": "8-K",
"isXBRL": true,
"filingUrl": "https://www.sec.gov/Archives/edgar/data/320193/000032019326000011/aapl-20260430.htm",
"fetchedAt": "2026-07-18T00:58:09.669Z",
"sourceApi": "data.sec.gov/submissions"
}
{
"recordType": "search-result",
"cik": "0000815097",
"displayName": "CARNIVAL CORP (CCL) (CIK 0000815097)",
"form": "10-K",
"accessionNumber": "0000815097-23-000012",
"fileDate": "2023-01-27",
"fileDescription": "10-K",
"fetchedAt": "2026-07-18T00:58:16.867Z",
"sourceApi": "efts.sec.gov/LATEST/search-index"
}

That same run also correctly surfaced a search-truncated record - the "climate risk" query matched far more than 5 filings, and maxSearchResults: 5 capped delivery, so the true match count was disclosed rather than hidden.

5. Use cases

  • Investor relations & competitive intelligence - get notified the moment a watched company (or its peers) files an 8-K, without polling EDGAR's website by hand.
  • Insider-trading research - monitor Form 4 filings (formTypes: ["4"]) for a company or list of companies as a cheap, always-on feed.
  • Legal / compliance due diligence - pull a company's full recent filing history by ticker or CIK, including SIC classification and state of incorporation, in one call.
  • Thematic/topic research - use fullTextSearchQuery to find every company across all of EDGAR that mentions a specific risk, technology, or event in a given form type (e.g. "climate risk" in 10-Ks, "cybersecurity incident" in 8-Ks).
  • Fintech / data platforms - feed a normalized, deduplicated SEC filing stream into an existing alerting or research dashboard via monitor mode, at a fraction of a commercial SEC data feed's cost.

6. Setting up filing alerts (Apify Schedules + your own notification channel)

This actor produces structured data; wiring that into an email/Slack/Teams alert is done with Apify's own platform features, not actor-specific code:

  1. Create an Apify Schedule pointing at this actor, with monitorMode: true and your companies/formTypes set. Hourly or daily is typical - 8-K monitoring in particular benefits from a tighter interval since 8-Ks are often market-moving and time-sensitive.
  2. Attach a Webhook to the schedule/actor for the ACTOR.RUN.SUCCEEDED event. Apify's webhook payload includes the run's dataset ID, so your webhook target can fetch the new items.
  3. Route the webhook to Slack/Teams via their native "incoming webhook" URL, or to email via a lightweight relay (e.g. a Zapier/Make webhook-to-email step) - since monitorMode only delivers genuinely new filings, every triggered notification represents real new information, not a repeat.
  4. Because the dataset always distinguishes filing/search-result records from company-not-found/fetch-failed/rate-limited/search-truncated status records, your alert logic can (and should) treat the latter as "monitoring degraded this run" rather than silently trusting an empty result.

7. Pricing

Pay per event (current live pricing - confirmed via the Apify API at time of writing):

  • filing-record - $0.004 per new filing delivered
  • search-result - $0.003 per full-text search hit delivered
  • monitor-run - $0.05 per scheduled monitor-mode run, in addition to per-record charges

monitor-run is not billed on a run containing any compromised result (a genuine fetch failure or rate-limit hit) - a disclosed search-truncated cap still bills normally, since it's a known, surfaced limit, not a blind spot.

See the actor's Pricing tab for the authoritative, current numbers.

8. Use from Claude, Cursor, and other AI agents (MCP)

This actor can be called as a tool by any MCP-compatible AI client (Claude Desktop, Cursor, VS Code, etc.) via Apify's hosted MCP server, without any actor-specific integration code:

  1. Point your MCP client at https://mcp.apify.com, authenticated with your Apify API token (as a bearer header or via OAuth - see Apify's MCP docs for client-specific config).
  2. Expose this actor specifically with the tools query parameter: https://mcp.apify.com?tools=mooseandraven/sec-edgar-filing-monitor
  3. Your agent can then call it directly - e.g. "check Apple's recent 8-K filings" or "find 10-Ks mentioning cybersecurity incidents" maps naturally onto companies/formTypes or fullTextSearchQuery/fullTextSearchForms. The actor's own input schema (this page's Input tab) is what the MCP tool schema is built from, so any filter documented here is available to the agent.

9. FAQ

How fresh is the data? This actor queries SEC EDGAR's live APIs at run time - results are as current as EDGAR's own systems, which typically reflect a filing within minutes of it being accepted.

Do I need an SEC EDGAR API key? No - EDGAR is fully keyless. The only requirement is a descriptive User-Agent header, which this actor sends automatically per SEC's fair-access policy.

Why did I get a company-not-found record instead of filings? The ticker or CIK didn't resolve against SEC's own ticker-to-CIK map or the submissions API directly - either a typo, a delisted/renamed ticker, or a genuinely non-existent company.

How far back does filing history go? The submissions API used here returns each company's most recent ~1,000 filings (SEC's own documented window) - sufficient for monitor mode, but not a full historical archive for companies with a longer filing history. See Limitations.

What's the pricing/subscription model? Pay-per-event, not a flat subscription - you're charged per filing/search-result actually delivered plus a per-monitor-run fee, so cost scales with how much genuinely new data the actor finds. See Pricing above.

Why do I sometimes get a search-truncated record instead of just search results? This actor deliberately surfaces its own limits instead of hiding them - see Output fields above. A broad fullTextSearchQuery can match thousands of filings; maxSearchResults caps what's fetched, and a capped pull is never silently reported as complete.

10. What it does NOT do / Limitations

  • Only the most recent ~1,000 filings per company are available via the submissions API used here (SEC's own documented ceiling on the filings.recent window) - a company with a longer history has older filings in separate paginated files this actor does not fetch. This is sufficient for monitor mode (which only needs the newest filings since the last checkpoint) but is a real ceiling for a one-time deep historical pull.
  • Full-text search is not deduplicated across monitor runs - it's a one-shot query each run, independent of the per-company monitor checkpoint.
  • Full-text search is capped at maxSearchResults (default 1,000), not exhaustive by default - a broad query can match 10,000+ filings (EDGAR's own count). Set maxSearchResults higher for a broader pull; either way, if the real total exceeds what was fetched, a search-truncated record surfaces the true total so this is never silent. Note EDGAR itself sometimes reports only "at least 10,000" (totalRelation: "gte") rather than an exact count for very broad queries - that's EDGAR's own reporting behavior, passed through honestly (see totalRelation on the search-truncated record), not this actor rounding.
  • A search-result's cik field is only the FIRST associated CIK - EDGAR's own search index can return multiple co-filer CIKs per hit (e.g. a joint filing); this actor surfaces the primary one, not the full co-filer list.
  • Form 4 (and other structured filings) are delivered as metadata + a link to the primary document, not with the underlying transaction details (shares, price, insider name) parsed out
    • that would require fetching and parsing each filing's own XML/HTML document individually, out of scope for v1.

Local development

npm install
npm test # recorded-fixture unit tests, no network needed
npx apify-cli run # local end-to-end run - works immediately, no key/account needed

Support

Built and maintained by Moose & Raven. Questions or issues: support@mooseandraven.com.