Stock Screener API: Fields, Coverage and Reproducible Queries

A stock screener API accepts documented filters and returns structured records from its supported universe. It may supply only a current company snapshot; price history, financial statements, news and option data can be separate endpoints with different permissions and delays. Design the query around the actual contract rather than assuming one endpoint provides every field.

How Pineify helps

Pineify AI Finance Agent has a company-screener tool backed by a market-data provider. Its supported filters include market cap, price, volume, beta, sector, industry, country, exchange and asset flags, with a result limit. Pine Script AI Coding Agent handles a separate chart-code workflow; it does not remove API licensing, data gaps or TradingView request limits.

Read the endpoint contract before choosing filters

Check the provider documentation for accepted parameters, units, comparison boundaries, coverage and result limit. The fact that an API provider offers a financial ratio somewhere does not mean the company-screener endpoint accepts that ratio as a filter.

  • Pineify’s current company-screener tool exposes market cap, price, volume, beta, annual dividend, sector, industry, country, exchange and ETF/fund/active flags.
  • It does not expose P/E, RSI or revenue-growth parameters in that same tool. A request needing those values requires other data and an explicit join or calculation.
  • Distinguish annual dividend amount from dividend yield, current session volume from average volume and current market cap from historical market cap.
  • Document unavailable values and currencies. Do not replace a missing ratio with zero.

Build a pipeline that can be reproduced

Save the query, endpoint version, observation time and response metadata. Confirm the universe and whether results are capped or paginated before claiming a complete screen. A response with 100 rows may simply have reached a limit.

  • Specify the required fields and a finite universe first.
  • Use the provider’s documented authentication and permissions. Keep credentials outside public client code.
  • Handle rate limits and service errors explicitly, and distinguish a failed response from a successful empty result.
  • Deduplicate records using appropriate security identifiers and dates. Preserve share-class distinctions when they matter.
  • For post-filter calculations, record the formula, source periods and excluded missing-data cases.

A hypothetical filter example

Suppose your research rule is positive P/E below 15 and revenue growth above 20%. A company with P/E 50 fails even if growth is 60%. A company with P/E 12 and growth 25% passes those two conditions, but still needs a reporting-period and accounting-quality review. These are invented inputs, not a scan of NVDA or AAPL.

  • Check whether P/E uses trailing, forecast or normalized earnings. A negative P/E is not simply a cheaper positive multiple.
  • Use comparable revenue periods and the publication dates of the reports.
  • If the endpoint cannot filter those fields directly, obtain them separately and label the resulting post-filter process.

A current response is not a historical backtest

A historical test needs the universe and observations available on each historical date. Reusing today’s financial statements, restatements or surviving symbols can introduce look-ahead or survivorship bias. A valid screen also remains distinct from a trading strategy with entries, exits and costs.

  • Store publication time separately from fiscal period end.
  • Check delisted securities, corporate actions and share-class changes.
  • Model fees, slippage and fills before describing simulated returns.
  • Do not describe a TradingView price-only test as a backtest of financial data that the script never received.

Choose API research or chart code for the specific task

Use the Finance Agent’s supported data tools to organize a research question and inspect the returned records. For chart-based conditions, Pineify’s Coding Agent can draft Pine Script for chart-based conditions. Request a syntax check and review the resulting logic in TradingView. A successful syntax check does not establish profitable behavior, data availability or broker compatibility.

  • Pine request functions access supported TradingView datasets; Pine does not perform arbitrary HTTP calls to a stock-screener API.
  • A finite-list script remains subject to request limits and chart-data availability.
  • An API endpoint or JSON export can have separate redistribution and storage terms. A generated indicator does not waive those terms.

How to check a screener result

Check 1

Confirm the symbol universe, timeframe, field settings, and data timestamp.

Check 2

Open each candidate chart and compare the screen result with price, volume, and nearby structure.

Check 3

Write down the condition that would invalidate the setup before making a trading decision.

This page is for informational purposes only and does not constitute investment advice. Trading stocks carries substantial risk of loss. Past performance does not guarantee future results. Always consult a qualified financial advisor before making trading decisions. Pineify is an information tool, not an investment adviser. No screener, indicator, or AI system can predict stock prices with certainty or guarantee a return.

Frequently asked questions

Does a stock screener API include real-time prices and news?

Not necessarily. Read the specific endpoint and plan documentation. Current company screening, historical prices, news and options may use separate datasets with different access and delays.

Can Pineify’s company screener filter P/E and RSI directly?

Those parameters are not exposed by its current company-screener tool. Use supported filters and obtain additional required fields through an appropriate separate source or workflow.

Does Pineify replace any external API integration?

No. Finance Agent research tools and Pine chart scripts serve different tasks. They do not guarantee the same fields, coverage, licensing or historical data as a custom API pipeline.

Can I backtest the API results?

Only with a suitable historical dataset and explicit rules. A current snapshot is insufficient to reconstruct what was known on every past date.

What should I check in a free API plan?

Confirm allowed fields, symbols, call limits, delay, history and usage rights in the current plan. A free endpoint does not imply unrestricted access or redistribution.