Fundamentals API

Query point-in-time company fundamentals from SEC XBRL facts

Query company facts by symbol, tag, fiscal period, and as-of cutoff. Each value retains its XBRL concept, unit, form, accession, filing date, period, and known-at timestamp for restatement-safe backtests.

SEC XBRL
public fact source
Units
kept with every value
Accession
document provenance
Versioned
restatement history
Definition

A fundamentals API provides structured financial-statement facts and derived metrics. Historical research requires the version disclosed by the cutoff, not a later restatement presented as if it had always been known.

How DataCedar handles it

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

01

Keep the source concept

Taxonomy tag, custom concept, unit, frame, period, fiscal year and quarter, form, accession, and filing date remain available.

02

Resolve facts as of a cutoff

Known-at filters exclude later disclosures and restatements before selecting the eligible version.

03

Link numbers to documents

Every value can trace back to the filing and accession that reported it, making normalized fields inspectable.

04

Separate facts from calculations

Source facts remain immutable; trailing periods, ratios, growth, and other derived metrics can be versioned independently.

Data surface

What the schema is built to carry.

SEC Company Facts / XBRL
Standard and custom concepts
Units and fiscal periods
Form and accession provenance
Known-at fact versions
Restatement comparisons
Source versus derived fields
Earnings-event and filing joins

Product boundary: Normalization improves usability but cannot make every issuer's accounting concepts directly comparable. DataCedar preserves the original concept and document context so researchers can inspect exceptions.

API example

Point-in-time company facts

GET /v3/stocks/{symbol}/fundamentals
Request
curl "https://api.datacedar.com/v3/stocks/AAPL/fundamentals?tag=Revenue&as_of=2026-05-02T00:00:00Z&limit=20" \
  -H "X-API-Key: $QUARTERTRACE_API_KEY"
Representative response
{
  "data": [{
    "concept": "us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax",
    "value": 95359000000,
    "unit": "USD",
    "period_end": "2026-03-28",
    "form": "10-Q",
    "accession": "0000320193-26-000000",
    "known_at": "2026-05-01T20:05:00Z"
  }]
}

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

Select

Choose the source concept or normalized field and the required fiscal granularity.

02

Cut off

Apply the simulated decision time before resolving the eligible filing version.

03

Inspect

Retain unit, period, frame, form, accession, and source concept with the value.

04

Derive

Compute ratios or trailing values in a separate, versioned layer that cites its inputs.

Field guide

What makes a fundamentals API safe for historical research

01

Financial facts have document context

The same friendly label can refer to different taxonomy concepts, units, durations, and issuer-specific extensions. Removing that context makes a table easy to read but hard to trust.

DataCedar keeps the XBRL concept and filing accession beside normalized output. A researcher can inspect the source document and handle an issuer-specific exception without abandoning the API.

  • Keep standard and custom concepts.
  • Retain units and duration or instant semantics.
  • Link every value to an accession.
02

Restatements must not travel backward in time

A later 10-K or amendment may report a different value for an earlier period. A latest-value endpoint can silently insert that revision into a backtest conducted before the later filing.

DataCedar stores fact versions with filing and known-at timestamps. The as-of cutoff is applied before choosing the value, while later versions remain available for restatement research.

  • Resolve versions only after the cutoff.
  • Compare filings by accession.
  • Do not mutate saved source facts.
03

Derived metrics need their own provenance

Trailing-twelve-month revenue, margins, growth, and ratios are calculations, not source facts. Their validity depends on period selection, sign conventions, units, and the versions of every input.

DataCedar separates source values from derived layers. A derived metric should retain its formula, input accessions, calculation time, and schema version so it can be recomputed after a mapping change.

  • Never sum instant balance-sheet facts.
  • Avoid mixing annual and quarterly durations.
  • Version formulas and normalized mappings.
Comparison

Latest fundamentals versus point-in-time company facts

A polished ratio is useful only when its source period and eligible filing version are unambiguous.

SourceVendor-normalized fieldSEC concept, form, and accession retained
RevisionsLatest reported valueKnown-at filing version
UnitsMay be standardized silentlySource unit and normalization both inspectable
Derived metricsOpaque calculationSeparated from source facts with inputs
Event contextSeparate calendar and documentsFiling and earnings-event joins
Before you rely on it

A practical validation checklist.

  1. 01Every value retains concept and unit
  2. 02Instant and duration facts are not confused
  3. 03Fiscal periods and frames are explicit
  4. 04The filing accession is present
  5. 05Known-at filtering happens before version resolution
  6. 06Derived metrics cite their source inputs
  7. 07Issuer-specific mappings are inspectable

Questions, answered.

Yes. Source facts retain filing and known-at timestamps so as-of queries can exclude later disclosures and revisions.

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