Home/Offers/Trading & Capital Markets/Stock Fundamental Research API

Trading & Capital Markets

Stock Fundamental Research API

Your users can buy a share in two taps. Deciding whether they should takes them somewhere else — usually to a competitor's research, or to a forum.

Stock brokers
Investing apps
Wealth platforms
Research terminals

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Execution has been commoditised. A retail investing app can route an order as well as anyone, which means the differentiator has moved to what happens before the order: whether the user can form a view inside your product or has to leave to form it somewhere else.

The research most apps show is thin — a price chart, a market cap, perhaps a P/E ratio with no context for whether it is high or low for that sector. Anything deeper usually means licensing an expensive terminal feed designed for professionals and awkward to present to a retail audience.

The middle path is a research layer built from filings and market data: standardised financials, health scores that compare a company to its own sector rather than to the whole market, valuation ratios with peer context, and summaries that explain what changed in an earnings report in language a non-professional can follow.

Who buys this

Stock brokers, Investing apps, Wealth platforms, Research terminals

Category: Trading & Capital Markets

What the API returns

What comes back

Financial health scores across profitability, leverage, liquidity and cash generation
Valuation ratios with sector and historical percentile context
Standardised financial statements across reporting standards
Earnings summaries in plain language, with the figures that moved
Growth and margin trend analysis over multiple years
Peer comparison against sector and size cohorts
Dividend history with sustainability indicators
Quality flags where filings are late, restated or unusual

Endpoints

Method	Path	Returns
GET	/v1/companies/{id}/health	Financial health scores with components
GET	/v1/companies/{id}/valuation	Valuation ratios with peer context
GET	/v1/companies/{id}/financials	Standardised statements
GET	/v1/companies/{id}/earnings/latest	Latest earnings with a plain-language summary
GET	/v1/companies/{id}/peers	Peer set with comparable metrics
POST	/v1/screen	Screen the universe on health and valuation criteria

Request and response

illustrative

Request

{
  "identifier": "US0378331005",
  "include": ["health", "valuation", "peers"],
  "peer_basis": "sector_and_size"
}

Response

{
  "company": { "name": "Example Industries plc", "sector": "Industrials",
               "currency": "USD", "fiscal_year_end": "12-31" },
  "health": {
    "overall": 74,
    "profitability": 81,
    "leverage": 62,
    "liquidity": 77,
    "cash_generation": 79,
    "trend": "improving"
  },
  "valuation": {
    "pe_ttm": 18.4,
    "pe_sector_percentile": 0.41,
    "ev_ebitda": 11.2,
    "fcf_yield": 0.052,
    "vs_own_5y_median": "slightly_cheap"
  },
  "latest_earnings": {
    "period": "Q3 2026",
    "revenue_change_yoy": 0.064,
    "margin_change_bps": 85,
    "summary": "Revenue grew 6.4% year on year with gross margin up 85 basis points. Operating cash flow improved while net debt fell slightly."
  },
  "flags": []
}

Where the data comes from

Company filings	Annual and interim reports from official regulatory repositories, which are the authoritative source
Market price data	Current and historical prices for market-based ratios
Shares outstanding and corporate actions	Without accurate share counts every per-share figure is wrong
Sector classification data	Needed so peer comparison is against genuinely comparable companies
Earnings calendars	Scheduled reporting dates for timely refresh
FX rates	For cross-currency comparison of companies reporting in different currencies

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Statement standardisation across reporting frameworks, so companies are genuinely comparable
Health scoring with sector-relative normalisation — a leverage ratio that is alarming for software is unremarkable for utilities
Valuation percentiles computed against both the peer set and the company's own history
Trend analysis that separates one-off items from sustained change
Language generation for summaries, constrained to figures present in the filing and validated against them
Restatement detection so historical comparisons use consistent figures
Anomaly flags for unusual accounting patterns, presented as observations rather than accusations
Coverage and freshness reporting per company so stale data is visible

What it changes for the business

Users stay in your app

Research inside the product removes the main reason a user opens a competitor's.

Premium research tier

Screening and peer comparison are features users will pay to unlock.

Better-informed orders

Context before the trade reduces the complaints that follow uninformed ones.

Content engine

Health and valuation changes generate a steady stream of legitimate notification material.

How it fits into your product

How it embeds

REST JSON for your own research screens
Prebuilt health-score and peer-comparison components
Batch endpoints for refreshing your whole covered universe
Webhooks on earnings publication and material score changes
Localisation of summary text across your supported languages
Entitlement controls so screening sits behind a premium plan

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Is this investment advice?

No. Scores and ratios are measurements of reported figures. The API never says buy or sell. Your compliance team decides how the output is framed, and we build to that.

How current are the figures?

Financial statements update as filings are published, typically within hours of release. Market-based ratios update with price data. Every response carries an as-of timestamp so staleness is never ambiguous.

What coverage is realistic?

Major developed markets are straightforward because filings are well structured. Smaller markets depend on how machine-readable the local repository is, and we would scope coverage honestly during discovery rather than promising a number we cannot hold.

Are the summaries generated by a language model?

Yes, but tightly constrained: the model may only reference figures extracted from the filing, and every numeric claim is validated against the source before the summary is returned. A summary that fails validation is withheld rather than shown.

Can we screen on custom criteria?

Yes. The screening endpoint accepts arbitrary combinations of the available fields, and we can add derived fields specific to your audience.

All Trading & Capital Markets offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers