GET /v1/statements/all, GET /v1/facts, and GET /v1/filings for normalized statement bundles, reported facts, and filing identity. The prior provider may remain the better choice for data families, historical coverage, or non-SEC sources that you have not qualified on SEC API.
Map the consumer, not just the number
Choose one screen, calculation, or export. Write down the period basis, units, null behavior, and evidence fields its consumer needs.
Verify the current provider’s route and response shape in its own documentation before creating a mapping. Matching a headline number is not enough: a reported value also has a period, unit, presentation, and source context.
Dual-run one annual statement case
requestId, period, units, source identifiers, and every field your application displays. Compare nulls as carefully as populated values. Do not coerce an absent observation to zero or assume the same tag is comparable across issuers.
Decide where SEC API fits
Use SEC API when a reusable SEC statement and fact layer with filing context fits the consuming contract. Keep the prior provider when it has the required source type, presentation, or historical scope that your evaluation has not demonstrated here. Use direct SEC data when your team needs to own taxonomy parsing and normalization.Make the release reversible
- Dual-run one issuer and one annual case.
- Compare fields, periods, units, source identity, and null behavior.
- Store the SEC API evidence record beside the result.
- Release one read behind a reversible control.
- Add another statement family only after the first acceptance test passes.
Next step
Select the lowest-risk statement read, save the current output and its evidence record, then decide whether that one consumer can move.Statements API reference
Inspect the documented statement surface.
Facts API reference
Review tags and response metadata.
XBRL evaluation
Run a reconciliation proof.