Earnings calendar API

Query historical earnings dates, confirmations, and schedule changes

Query expected, confirmed, rescheduled, cancelled, and completed earnings events by symbol or date. Each observation includes its fiscal period, session timing, source evidence, status, and known-at timestamp.

Start free Read the API docs
Versioned
schedule observations
BMO / AMC
session timing
Fiscal
period identity
Event windows
reaction-ready joins
Definition

An earnings calendar API supplies company reporting dates and session timing. Historical research also needs when each date became known, because today's finalized calendar can reveal schedule changes that a past strategy could not have seen.

How DataCedar handles it

What you can query, which fields are returned, and how availability is reported.

01

Separate estimate from confirmation

Expected, confirmed, rescheduled, cancelled, and completed states stay explicit, with the source evidence and retrieval time behind each observation.

02

Preserve schedule history

A new date does not overwrite the previous date. An as-of query reconstructs the calendar visible before the change.

03

Normalize the reporting period

Issuer, fiscal quarter or year, session timing, timezone, and reporting event remain separate from the calendar day.

04

Measure the reaction

Join the event with its 8-K, filing documents, point-in-time facts, public news references, and permitted price-and-volume windows.

Data surface

What the schema is built to carry.

Cross-symbol earnings calendar
Expected and confirmed states
Schedule-change history
Before/open/after-market timing
Fiscal period normalization
Source evidence and known-at time
Filing and call linkage
Event-aligned research windows

Product boundary: Early calendar observations are not certainties. DataCedar exposes status, source, and known-at time rather than labelling every estimate as issuer-confirmed. Reaction windows require separately permitted market history.

API example

Cross-symbol earnings events

GET /v3/stocks/earnings
Request
curl "https://api.datacedar.com/v3/stocks/earnings?as_of=2026-07-17T12:00:00Z&limit=100" \
  -H "X-API-Key: $QUARTERTRACE_API_KEY"
Representative response
{
  "data": [{
    "symbol": "AAPL",
    "event_date": "2026-07-30",
    "session_timing": "after_market_close",
    "status": "confirmed",
    "fiscal_period": "2026-Q3",
    "known_at": "2026-06-26T13:00:00Z",
    "source_evidence": "..."
  }]
}

Examples document the public contract and may use illustrative values or redacted identifiers. Availability fields and rights filters are authoritative for the active environment.

Research workflow

Four steps from API key to a validated dataset.

01

Observe

Collect a date claim with its source, confidence or status, and retrieval time.

02

Version

Append confirmations and changes instead of mutating the prior observation.

03

Resolve

Attach the issuer, fiscal period, timezone, and market-session timing.

04

Study

Build event windows using only observations known before the simulated decision.

Field guide

Why a historical earnings calendar needs version history

01

The final earnings date is future information

Most calendars show the date currently believed to be correct. That is useful for planning the coming week, but it is dangerous for a historical simulation. A company may have changed or confirmed the date after the model's decision point.

DataCedar stores each observation with a status and known-at time. The calendar can therefore answer both 'when did the company report?' and 'what date did a researcher believe on this earlier day?'

  • Do not backfill the final date into earlier snapshots.
  • Keep estimated and issuer-confirmed sources separate.
  • Record cancellations and reschedules as events.
02

Session timing changes the return window

An announcement before the opening bell belongs to a different return window from one published after the close. A date without timezone and session timing can shift the event by an entire trading day.

DataCedar normalizes before-market, during-session, after-market, and unknown timing while preserving source wording. Research code can choose a consistent event-session rule and flag ambiguous observations.

  • Store the issuer/source timezone.
  • Map the event to an exchange session.
  • Keep unknown timing explicit instead of guessing.
03

An earnings event is more than a calendar row

The useful research object includes the fiscal period, release evidence, filing, call record, known-at fundamentals, news references, and the market response. Keeping those in separate vendor silos creates fragile joins and hidden mismatches.

DataCedar uses one event identity and company timeline. Transcript text remains rights-gated, while public SEC releases and calendar evidence can still support a complete, inspectable event record.

  • Join by stable issuer and fiscal period.
  • Preserve the evidence URL.
  • Apply the same information cutoff across every stream.
Comparison

Latest calendar versus point-in-time earnings history

A planning calendar answers what is expected now. A research calendar must also answer what was expected then.

Date changesLatest value replaces old dateEvery observation remains queryable
CertaintyOne date fieldExpected, confirmed, changed, completed
TimingDate or coarse labelSession timing plus timezone and evidence
Fiscal identityTicker and dateIssuer plus normalized fiscal period
Reaction studyManual data joinsEvent-aligned filings, facts, news, and bars
Before you rely on it

A practical validation checklist.

  1. 01Every date has a source and known-at timestamp
  2. 02Estimated and confirmed events are distinguishable
  3. 03Reschedules do not overwrite prior observations
  4. 04Session timing and timezone are retained
  5. 05The fiscal period is normalized
  6. 06The event maps to the correct trading session
  7. 07Reaction data uses the same as-of cutoff

Questions, answered.

Yes. The model retains historical event observations and schedule changes rather than keeping only today's final date.

Continue the research

Historical stock data →

Build historical stock price and volume exports with explicit adjustments, coverage checks, symbol history, and event windows for reproducible backtesting.

Stock market data API →

Query permitted stock price and volume beside SEC filings, earnings events, point-in-time fundamentals, news references, macro data, and coverage metadata.

SEC filings API →

Query SEC filing metadata, primary documents, exhibits, XBRL facts, and amendments with accession-level provenance and known-at timestamps.

Earnings call transcripts API →

A searchable, event-linked earnings-call schema for licensed transcripts and permitted issuer audio, with speakers, sections, source provenance, and rights controls.

Create a free API key for filings, facts, earnings events, news links, and macro data.

Explorer is $0 with no card and a 1 request/second limit. Market history and transcript text appear only when an eligible source is active for the account.

Open DataCedar