Free Earnings Calendar API
for Reliable Event Data
Choose an earnings calendar by confirmed event times, estimate coverage, revisions, history, and usage rights—not by symbol count alone.
TL;DR
An earnings calendar API is a changing schedule of expected corporate events, not a permanent list of dates. A production record should show who is reporting, which fiscal period the event covers, whether the date and session are estimated or confirmed, when the schedule last changed, and what source supports it. The API is most useful for planning alerts, workload, and portfolio monitoring before results are released.
Keep the exchange timezone, before-market or after-market flag, confirmation status, and last-updated timestamp with every event.
EPS and revenue consensus can change until release. Snapshot estimates when alerts, event studies, or backtests depend on earlier information.
Fields a useful earnings calendar API should return
At minimum, expect a stable company identifier, ticker, exchange, event date, event time or session, fiscal quarter, fiscal year, currency, confirmation status, and updated timestamp. A date without timezone semantics is unsafe: midnight UTC can become the prior local date, while “after market close” describes a session rather than an exact clock time.
For analysis, look for estimated and actual EPS, estimated and actual revenue, the number of contributing analysts, surprise values, and source provenance. Keep raw and normalized values separately. Providers may define adjusted EPS, diluted EPS, consensus, and surprise percentages differently, so field names alone do not guarantee comparable numbers.
| Field group | What to retain | Why it matters |
|---|---|---|
| Identity | Provider ID, ticker, exchange, company name | Tickers change and can be reused. |
| Timing | Date, timezone, session, confirmation, updated time | Prevents late or misdated alerts. |
| Event status | Estimated, confirmed, rescheduled, postponed, cancelled, reported | Lets applications update or withdraw scheduled work safely. |
| Fiscal context | Fiscal year, quarter, period end, report type | Prevents a calendar event from being assigned to the wrong quarter. |
| Results | EPS and revenue estimates, actuals, currency, units | Supports consistent surprise calculations. |
| Change history | Prior dates, sessions, statuses, source, and observation times | Supports audit, schedule-quality analysis, and point-in-time research. |
How to test coverage, timing, and revisions
Test more than large US companies. Query ADRs, newly listed issuers, firms with non-calendar fiscal years, multiple share classes, and symbols that changed. Compare upcoming events with company investor-relations pages or exchange notices, then compare reported values with filings. Record whether an event is estimated, confirmed, postponed, cancelled, or reported.
Measure freshness through changes, not a marketing label. Poll a representative week and log when dates, sessions, estimates, and actuals first appear and when they change. A provider can update quickly after release yet still publish an unreliable schedule days earlier. Historical endpoints should also preserve the estimate visible before the announcement rather than attaching today’s consensus to an old event.
Combine legal company identity, fiscal period, event type, and provider event ID. Do not key only by date: the date may change, and one issuer may schedule several events on the same day.
Append each observed date, session, status, source, and observation time. A current view can show the latest confirmed schedule, while the history explains how often and how late the provider changed it.
Interpret BMO, AMC, and during-market labels in the listing exchange timezone. Use the exchange trading calendar for holidays, half days, and daylight-saving transitions rather than applying one global clock rule.
Schedule, update, postpone, cancel, and complete alerts using the stable event key. Repeated polls should not create duplicate notifications, while material schedule changes should update the existing event visibly.
The calendar service plans work before publication; a reported-results service confirms actual values afterward. Keep their polling frequencies, completion rules, latency metrics, and error states separate.
Across several reporting cycles, measure company coverage, first-seen lead time, confirmation lead time, reschedule detection delay, cancellation accuracy, and duplicate-event rate. Segment results by market capitalization, exchange, and region. A calendar that looks complete on announcement day may still be unsuitable if it discovers smaller issuers too late for research preparation.
Build an earnings-event workflow that survives schedule changes
An earnings calendar becomes operationally useful only when the application reacts differently to discovery, confirmation, rescheduling, publication, and completion. Treat the calendar as a versioned event stream. Each observation should update the same stable event record, while every material change remains available for audit and point-in-time analysis.
When an estimated date first appears, create a provisional event and schedule low-frequency checks. Attach the issuer, fiscal period, expected session, source, and first-seen time. Research preparation can begin, but user-facing copy should still label the date as unconfirmed.
When the issuer or provider confirms the date, preserve the prior estimate, mark the confirmation source and time, and increase polling as the release window approaches. If the session changes from before-market to after-market, update the existing alert instead of creating a second event.
After publication, acquire actual EPS and revenue through a separate results workflow. Use an idempotency key so repeated provider responses cannot send duplicate alerts. Partial releases should remain open until required fields arrive or a documented timeout policy closes the event.
Store the actual-value source, source timestamp, retrieval time, estimate snapshot used for comparison, units, currency, and any later corrections. Completion should mean the required evidence is present—not merely that the expected clock time has passed.
Worked surprise example. Assume the last pre-release snapshot contains EPS consensus of $1.10 and revenue consensus of $2.42 billion. The company reports EPS of $1.24 and revenue of $2.48 billion. EPS surprise is ($1.24 − $1.10) ÷ |$1.10| = 12.7%; revenue surprise is ($2.48bn − $2.42bn) ÷ $2.42bn = 2.5%. Store the raw differences as well as the percentages, together with the estimate timestamp, analyst count, currency, unit scale, and whether the figures are GAAP or adjusted. When the consensus is zero or negative, percentage surprise can be unstable or counterintuitive, so the raw difference and calculation method should remain visible.
Use QVeris to find earnings calendar capabilities
QVeris helps AI agents discover, inspect, and call earnings-calendar and corporate-event tools. An agent can compare date-range inputs, company identifiers, event states, timezone semantics, fields, and limits before routing a request. QVeris simplifies access; the application still owns event identity, schedule versioning, exchange-calendar logic, alert idempotency, and source verification.
FAQ
Some providers offer public endpoints or a free plan, but quotas, history, exchange coverage, delayed fields, and commercial rights vary. Verify the current terms before production use.
BMO means before market open and AMC means after market close. They are session labels, not precise timestamps, and should be interpreted in the relevant exchange timezone.
Only if the data preserves the schedule and consensus known at each historical point. Latest-only records create look-ahead bias.
Refresh distant events less often and increase frequency as the expected date approaches. Confirmed events and active earnings-season watchlists deserve tighter polling than unconfirmed dates months away.
Append the new schedule observation, retain the prior value, update existing alerts, and explain the changed status. Do not delete and recreate the event under a new identity.
Yes. Results releases, conference calls, guidance calls, and investor events can share a date. Use event type and stable event ID rather than assuming one row per company per day.
They can enrich the event, but store versioned estimates separately and reference the selected snapshot. A changing consensus should not silently mutate a scheduling record.