US Stocks API: Build a Research Page with Prices, History and Filings

A stock research page has to answer three questions quickly: what is the price, how has it moved, and what has the company reported?

A US stocks API can supply all three. The useful part of the integration is deciding how each piece reaches the screen. Prices change frequently, a chart covers a selected period, and a quarterly report describes a period that ended before the document was filed. Giving all three the same “Updated now” label loses that context.

This guide maps a simple research page to the SiftingIO US Stocks API, with requests for company discovery, the latest price, historical OHLCV and SEC filings. You can use the same pattern for an investing app, an internal research tool or a financial information site.

Start with four useful panels#

Keep the first screen focused. A reader should recognize the company, see a price with its timestamp, inspect a chart and open the relevant company reports.

These panels should load independently. A temporarily unavailable price should not prevent someone from reading the company’s filings or exploring its historical chart.

The examples below use AAPL as a familiar ticker. It is an integration example, not an investment recommendation. They show request construction rather than captured market prices.

1. Resolve the company before requesting its data#

Start with company search when the visitor types a name. Set SIFTING_API_KEY in your server environment, then run:

curl --fail-with-body --silent --show-error --get \
  -H "X-API-Key: ${SIFTING_API_KEY:?Set SIFTING_API_KEY first}" \
  --data-urlencode "q=apple" \
  --data-urlencode "limit=5" \
  "https://api.sifting.io/v1/fnd/stocks/search"

Let the visitor choose the matching company. Keep the returned ticker and company name together instead of assuming the first search result is the intended security. The response also includes a CIK, the SEC identifier for the issuer.

That distinction becomes useful as the product grows: a price belongs to a security, while company reports belong to an issuer. An issuer may have more than one traded share class. Preserve both identifiers so the company panel and price panel remain connected to the right entities.

For a fixed watchlist, start with known tickers and check them in the symbol catalog. A company-search match alone is not a guarantee that every dataset is available for that security.

2. Put the latest price beside its timestamp#

Request a price for the selected stock:

curl --fail-with-body --silent --show-error \
  -H "X-API-Key: ${SIFTING_API_KEY:?Set SIFTING_API_KEY first}" \
  "https://api.sifting.io/v1/last/trade/stocks/AAPL"

The last-trade response exposes s for the symbol, p for price, P for size and t for a Unix timestamp in milliseconds. Price and size are JSON strings. Preserve them for display, or convert deliberately when calculating with them.

On the screen, put the timestamp close to the price. Give the timestamp a timezone. Keep the time when your app fetched the response separately if you need it for diagnostics.

An HTTP response arriving now does not mean a trade happened now. At weekends and outside the relevant trading session, the interface needs to make the available price’s age clear. Use a separate market-session indicator rather than deriving “Market open” from a successful request.

REST is convenient for the initial page load and occasional refreshes. If the page needs continuous price updates, use the WebSocket protocol for the changing values. Historical chart data and filing lists can keep their own refresh schedules.

3. Load a chart at the resolution the reader needs#

A year of daily bars is a good starting point for a company overview. Intraday detail becomes useful when the reader selects a shorter window.

This request uses a closed historical window so the example is repeatable:

curl --fail-with-body --silent --show-error --compressed --get \
  -H "X-API-Key: ${SIFTING_API_KEY:?Set SIFTING_API_KEY first}" \
  -H "Accept-Encoding: gzip" \
  --data-urlencode "start=2025-01-01" \
  --data-urlencode "end=2025-12-31" \
  --data-urlencode "interval=1d" \
  --data-urlencode "limit=500" \
  "https://api.sifting.io/v1/hist/stocks/AAPL/bars"

The historical endpoint requires gzip support. --compressed tells cURL to decode the response. Each row in data contains t, o, h, l, c and v: bar opening time, open, high, low, close and share volume. The chart uses c for a closing-price line, or all four price fields for candlesticks.

These are interface choices, not fixed API range limits. The supported intervals are 1m, 5m, 15m, 30m, 1h, 1d, 1w and 1mo.

SiftingIO offers 25+ years of US stock historical coverage for supported series. The available start date depends on the instrument; a recently listed company naturally has a shorter trading history. Check the requested ticker and range before promising a fixed chart depth to your users.

Follow meta.next_cursor when it is returned, keeping the same filters and passing the token as cursor. Otherwise, a chart can silently show only the first page. Keep the bars in chronological order.

The stock-bars reference describes regular-session coverage. Closed sessions produce no bars. Preserve those session boundaries rather than adding invented weekend prices or zero-volume candles. Also label a price chart as a price chart: a total-return calculation requires an explicit treatment of corporate actions and distributions.

4. Add reports that explain the business#

The price chart shows market movement. A report panel gives readers a direct route to what the company disclosed.

Fetch recent annual and quarterly reports, including amendments:

curl --fail-with-body --silent --show-error --get \
  -H "X-API-Key: ${SIFTING_API_KEY:?Set SIFTING_API_KEY first}" \
  --data-urlencode "form=10-K,10-Q,10-K/A,10-Q/A" \
  --data-urlencode "limit=10" \
  "https://api.sifting.io/v1/fnd/stocks/AAPL/filings"

The filings endpoint provides the form, accession number, reporting-period end, filing date, acceptance time and primary-document URL where available. Show the reporting period and filing date as separate fields. Keep amendments identifiable instead of silently treating them as interchangeable documents.

For example, a report covering a quarter that ended in March may be filed in May. A timeline should place that document according to the event it represents. A fiscal-period label belongs in the report details; a disclosure timeline needs the filing or acceptance time. A backtest needs its own point-in-time availability policy before using that report as historical knowledge.

Use the returned primary-document URL for an “Open filing” link. This lets a reader inspect the source directly. If you later add a summary, keep that link beside it.

For operating-company research, XBRL financials can add reported metrics. Carry the period and unit with each metric. ETF pages and other security types need their own relevant information panels; do not assume they share an operating company’s reporting pattern.

Let each panel keep its own clock#

A useful research page can have several different dates without being inconsistent:

This separation also makes the page easier to maintain. Cache company details and report lists on a suitable schedule. Refresh prices according to the screen’s needs and the account’s limits. Fetch historical bars when the selected ticker, interval or date range changes.

Keep the API key on your server, and return only the fields your frontend needs. On errors, preserve working panels and label the affected one. A missing price is unavailable, not zero; an empty filing list is empty, not a failed price feed.

Try the page with one company#

Start with a ticker, a daily chart and a short filing list. That is enough to evaluate the data and give a reader something useful. Then add continuous updates, additional periods or company financials where they improve the page.

Create a free SiftingIO account to generate an API key and try the requests within your account’s market access and limits. Before putting data on a public screen, match the use case to the plan’s display rights and applicable source conditions. The data methodology and pricing page explain the product context and available plans.