Skip to main content
This is the complete catalog of event types. Each entry names the payload shape it carries and the API endpoint its entries match, so you can reuse parsers you have already written. For how delivery, retries, and signature verification work, see the Webhooks reference.

Envelope

Every delivery is a POST of the same JSON envelope. Only data.object varies by event type.

Payload shapes

Four shapes cover every event type that carries data, and each catalog entry below names which one it uses. filing_items.metadata.created is the exception: it carries filing metadata rather than data, and its shape is documented with the event itself.

Filing-level

Used by the four statement events, the three segment events, and the two insider events. A header identifying the filing, plus an array named after the event’s dataset. Each array entry is identical to a single entry from the corresponding API response.
Header vs. entry form_type. Statement entries carry their own form_type recording which form that row came from. It matches the header for the filing’s reported period, and is null on ttm entries, because a trailing twelve month window can span multiple filings. Read the header when you want the filing; read the entry when you want that row’s provenance. Segment entries carry no form_type, filing_date, or filing_datetime.

Release-level

Used by the three earnings intelligence events. Keyed to an earnings release rather than a filing period.

Earnings

Used only by earnings.created. The data.object is a single entry from the GET /earnings/ response, with no wrapper array. Used by the four macro events. A date header naming the print, plus the same body the dataset’s snapshot endpoint returns, under the same key. One event per dataset per new date (per release for the labor market, per bank per rate change for interest rates). A later revision of an already published date does not fire a new event; the snapshot and history endpoints serve the revised values.

Event types

Listed alphabetically.

balance_sheets.created

Fires when a filing’s balance sheets are extracted, within minutes of a 10-K, 10-Q, 20-F, or 6-K being processed. Shape: filing-level, carrying balance_sheets. Entries match GET /financials/balance-sheets.

balance_sheet_segments.created

Fires when a filing reports balance sheet segment breakdowns. Balance sheet segments are rarer than income statement segments, so expect this event for fewer filings. Shape: filing-level, carrying balance_sheet_segments. Entries match GET /financials/balance-sheets/segments.

cash_flow_statements.created

Fires when a filing’s cash flow statements are extracted, within minutes of a 10-K, 10-Q, 20-F, or 6-K being processed. Shape: filing-level, carrying cash_flow_statements. Entries match GET /financials/cash-flow-statements.

cash_flow_statement_segments.created

Fires when a filing reports cash flow statement segment breakdowns. Like balance sheet segments, these are reported by fewer filings. Shape: filing-level, carrying cash_flow_statement_segments. Entries match GET /financials/cash-flow-statements/segments.

earnings.created

Fires when we parse a new earnings release (8-K) or quarterly/annual report, within minutes of the filing hitting EDGAR. Shape: earnings. The data.object is a single GET /earnings/ entry, so any parser written against the Earnings API works unchanged.
A single quarter can fire more than one earnings.created event. The 8-K earnings release fires first, then the 10-Q (or 10-K for the fiscal-year quarter) follows 30 to 45 days later with the full GAAP-audited numbers. Both carry the same (ticker, report_period) but different accession_numbers and different source_types. See Handling multiple earnings events below.

filing_items.metadata.created

Fires when a filing’s items become available, which is the moment GET /filings/items can serve them quickly. Covers 10-K, 10-Q, and 8-K filings and their amendments (10-K/A, 10-Q/A, 8-K/A), one event per filing.
This event carries metadata, not filing text. Filing text runs to megabytes, which would blow the 10 second delivery deadline, so the payload gives you the filing header, the items it contains, and a url to fetch the text from. Treat it as a notification to go pull, not as the data itself.
Using available_items. The values are exactly what the item query parameter accepts, so you can filter before spending a call. Append &item=<name> to the url to fetch a single section:
Item naming follows the filing family: 10-K items look like Item-1A, 10-Q items are part-qualified as Part-1,Item-2, and 8-K items carry their decimal number as Item-2.02. A filing contains any subset, so check available_items rather than assuming a given item is present. This makes the event a cheap filter: an agent that only cares about earnings releases can watch for Item-2.02 and ignore every other 8-K without fetching anything. Fetching the url is a normal billed API call, and it hits a warm cache. See GET /filings/items for the response schema and the full list of item names.

financial_metrics.created

Fires when a filing’s financial metrics (valuation, margins, ratios, growth) are computed. Shape: filing-level, carrying financial_metrics. Entries match GET /financial-metrics.

forward_guidance.created

Fires when an earnings release contains forward guidance, minutes after earnings.created once we finish analyzing the release. Shape: release-level, carrying forward_guidance. Entries match GET /kpi/guidance.

income_statements.created

Fires when a filing’s income statements are extracted, within minutes of a 10-K, 10-Q, 20-F, or 6-K being processed. Shape: filing-level, carrying income_statements. Entries match GET /financials/income-statements.
A filing usually produces one entry per array. When we can also compute a trailing-twelve-months view from it, a second entry with "period": "ttm" appears alongside the quarterly or annual one. Entries are ordered by period type, so on annual filings the ttm entry comes first.

income_statement_segments.created

Fires when a filing reports income statement segment breakdowns. This is the most common of the three segment events. Shape: filing-level, carrying income_statement_segments. Entries match GET /financials/income-statements/segments.

inflation.created

Fires when a new month of consumer price index data is published, within hours of the monthly release. One event per reference month, carrying every series we track. Shape: print-level, carrying inflation. The array is identical to the body of GET /macro/inflation/snapshot: one entry per series, each with the index level and the month-over-month and year-over-year percent changes.
The live event carries one entry per series, twelve in total. date is the reference month as its first day, not the release date, the same convention the Inflation API uses.

labor.created

Fires when a new labor market release is published, within hours of the release. One event per release: the monthly jobs report (jobs_report: payrolls, the unemployment rates, participation, hourly earnings), the monthly job openings report (job_openings: job openings, hires, quits), and the weekly jobless claims release (jobless_claims: initial and continued claims, their 4-week averages, the insured unemployment rates). The release field names which one. Shape: print-level, carrying labor plus release. The array is the matching slice of GET /macro/labor/snapshot: one entry per series in the release, each with the value, the change from the prior period, the change from a year earlier, and that change as a percent.
The live event carries every series in the release: ten for the jobs report, six for job openings, eight for jobless claims. date is the reference period, not the release date, the same convention the Labor Market API uses. For jobless_claims the header date is the week the initial claims cover; the continued claims and insured unemployment rate entries are dated one week earlier, as the release states them. Weekly values carried by the event are the advance figures; the snapshot and history endpoints serve the final figures once published.

insider_ownership.created

Fires when an insider reports positions they hold rather than trades: SEC Form 3 initial ownership statements, Form 5 filings that include holdings, and their amendments (3/A, 5/A). One event per filing, delivered once daily in the early morning UTC covering the previous day’s filings. Shape: filing-level, carrying insider_ownership. Entries match GET /insider-ownership.
A single Form 5 that reports both transactions and holdings fires both events: one insider_trades.created and one insider_ownership.created, sharing the same accession_number.
Each entry describes one held position:

insider_trades.created

Fires when a company insider reports buying or selling stock: SEC Form 4, Form 5 annual statements that include transactions, and their amendments (4/A, 5/A). One event per filing, delivered once daily in the early morning UTC covering the previous day’s filings. Shape: filing-level, carrying insider_trades, with one entry per reported transaction in filing order. Entries match GET /insider-trades.
Amendments. An amendment (4/A, 5/A) is its own filing with its own accession_number, so it fires its own event containing the complete, amended set of transactions. Treat its contents as replacing what the original filing reported.

interest_rates.created

Fires when a central bank changes its policy rate. One event per bank per change, dated the first day the new rate is in effect. The source publishes the daily series once a week, so the event arrives up to nine days after the decision. Shape: print-level, carrying interest_rates plus bank. The array holds one entry, the bank’s row for that day, identical to that bank’s entry in GET /macro/interest-rates/snapshot. For the Federal Reserve the rate is the midpoint of the target range.

non_gaap_metrics.created

Fires when an earnings release contains non-GAAP metrics, minutes after earnings.created. Shape: release-level, carrying non_gaap_metrics. Entries match GET /kpi/non-gaap.

operating_kpis.created

Fires when operating KPIs are extracted from a new earnings release, minutes after earnings.created. Shape: release-level, carrying operating_kpis. Entries match GET /kpi/metrics.

yield_curve.created

Fires when a new business day of the Treasury yield curve is published, the same evening. One event per business day. Shape: print-level, carrying yield_curve. The object is identical to the body of GET /macro/yield-curve/snapshot: the date plus one key per tenor, null where a tenor was not published that day.

Handling multiple earnings events

A single quarter of earnings can produce more than one earnings.created event as the SEC filing chain progresses:
  1. The 8-K earnings release fires first, typically hours after announcement.
  2. The 10-Q (or 10-K for the fiscal-year quarter) follows 30 to 45 days later with the full GAAP-audited numbers, segments, and footnotes-derived metrics.
Both events have the same (ticker, report_period) but different accession_numbers and different data.object.source_type values ("8-K" vs "10-Q" vs "10-K"). Three reasonable ways to handle this:
  • Dedupe by (ticker, report_period) — process the first event you see, ignore the later one. Use when latency matters more than completeness.
  • Always process the most recent source_type — keep the 10-Q’s richer data, discard the earlier 8-K once it arrives. Use when you need the full GAAP record.
  • Process both — emit your downstream signal twice. Use when you have separate “first signal” and “final record” consumers, such as real-time alerting plus an analytics warehouse.
The dedup key on our side is event.id, the same one we use for retry idempotency. The dedup key on your side is (ticker, report_period) if you want once-per-quarter semantics. Foreign issuers and microcaps that don’t file 8-Ks fire only one event per period (the 10-Q, 10-K, or 20-F).

Timing summary

See also