QUANTERY

← Quantery Blog

How to connect market data to Quantery

September 30, 2026 · 8 min readgetting-starteddata-qualityworkflow

To connect market data to Quantery, begin with the question your thesis needs to answer. Use SEC EDGAR for filing fundamentals, a price provider for market-dependent features, Financial Modeling Prep for index membership, and Alpha Vantage when the research actually needs historical options. Quantery's data documentation explains what each connection supplies and which data already comes with the app.

You don't need to connect everything before the first scan. Quantery includes a starter dataset with point-in-time SEC fundamentals, the US equity universe, and the bundled thesis templates. Treat that seed as a working introduction. It doesn't keep prices, filings, or membership history current for you, so the useful setup is the smallest set of sources that supports the thesis you're about to run.

Start with the inputs your thesis uses

A data dependency is an input a rule needs before it can produce a value. Write those dependencies down before opening provider settings. This keeps setup tied to research.

Take a filing-driven quality thesis. Its rules may use net income and operating cash flow. Those are filing facts, so SEC EDGAR is the natural source. Add a valuation yield and the thesis now needs a current market value. Add a price trend and it needs daily price history. Point the thesis at an index and it needs dated membership records as well.

That sequence matters because a feature can look self-contained after it has been calculated. Free-cash-flow yield appears as one ratio, but it combines filing data with a market denominator. A current ratio needs two balance-sheet lines from the same period. A drawdown needs a run of prices, including the earlier high. List the raw pieces and the required lookback for each feature.

If you're still learning the loop, run the starter workflow first. Then return to the thesis and ask what the seed can't keep fresh. You'll have a concrete reason for each connection.

What does each data source add?

The providers overlap in places, but they aren't interchangeable.

You probably don't need all four. A current fundamentals thesis can begin with EDGAR and a price source. A test that depends on historical index membership needs FMP's constituent data. An options thesis needs Alpha Vantage. An unused source gives you another dataset to maintain.

The unofficial Yahoo connection can get a price-dependent template moving without a data key. There is no service contract behind those public endpoints. If your process depends on a particular history or field, inspect local coverage and decide whether a keyed provider fits better.

What can the starter dataset do?

The starter data lets you inspect filing-based features, open the bundled templates, and understand how a thesis becomes a scan. It also means a fresh install isn't an empty shell. You can read the rules before choosing an external data account.

It isn't a live subscription. The Quantery docs say price and options history aren't part of the seed, and standard index membership must be fetched with the user's own FMP key. A template can therefore be present while an input it needs is absent or stale. The template defines the calculation. Your local lake determines whether the calculation has evidence to work with.

A local data lake is the on-device store holding the filings, prices, membership records, and other inputs Quantery has collected. Scans and backtests read that store. Provider connections fill it; they don't turn the app into a remote workspace. Your theses and research results stay local too.

Connecting a provider proves that Quantery can ask it for data. It doesn't prove that every company has the depth your rule needs. Collection and coverage are separate checks.

Connect one source and test a narrow pull

Open the app's settings and configure the provider that answers the first unmet dependency. For a keyed source, create the key with that provider, paste it into the corresponding field, and save it. For the optional Yahoo source, enable the connection without a key. The exact provider notes live in the setup documentation.

Quantery stores provider keys on your device and connects to providers directly. The keys aren't sent through Quantery's servers. That's important for privacy, but it also gives the connection a plain failure boundary: a rejected key, unavailable endpoint, or plan restriction comes from the route between your install and that provider.

Test the connection with a narrow collection job. Choose a company your thesis can explain and fetch the dataset you just configured. Don't begin by refreshing everything. A small pull answers the setup questions faster: Did the key work? Did the intended rows arrive? Does the source provide enough history? Did the field your feature needs appear?

Data pulls, scans, and backtests share the local database writer, so they run in sequence. If a scan is waiting behind collection, the queue banner shows the active work. Use Run next when the scan should move ahead, or Notify when done if you'd rather leave the jobs in order. Queueing protects a consistent research snapshot; it isn't a connection failure.

Verify coverage before trusting the feature

Open a company that should have received the data and inspect its coverage record. Check four different facts:

Those checks answer different questions. A price series can be fresh today and still start too late for a long backtest. Filing history can span many periods while missing the cash-flow line a feature requires. A stored row count says data exists; it doesn't certify that the record is usable for this thesis.

Read collection status literally. The documentation distinguishes a successful collection from a failed attempt, a dataset that hasn't been requested, and an EDGAR check that found no supported filing. Retrying can fix a network error. It can't create a filing that doesn't exist or unlock an endpoint outside the provider plan.

For a deeper preflight, use the workflow in how to check data coverage before a backtest. It shows how to map a thesis feature to its required periods before reading any return chart.

Match the provider mix to the research job

Once the narrow pull works, expand only as far as the next run needs.

For a current scan, refresh the inputs used by the active thesis across its declared universe. For a historical test, check that prices reach the planned start and that filing fundamentals are visible on the dates the rules will evaluate them. If the thesis targets a standard index, fetch and inspect its membership history before assuming the name of the index guarantees point-in-time membership.

Custom ticker lists can reduce the collection scope, but they don't repair missing evidence. A short list with shallow prices is still shallow. A broad universe with strong filing coverage may still be unable to evaluate a market-cap feature when its price data is stale. Universe and coverage work together, which is why the universe belongs inside the thesis.

Avoid filling an unknown input with zero just to keep a company in the result. Unknown debt isn't debt-free. A missing price isn't a flat return. Decide in the thesis whether absent data makes a feature null, withholds a score, or fails a required gate. Then you can inspect and retest that policy like any other rule.

Refresh the data without moving the thesis

A data refresh changes the evidence underneath a saved rule. Keep the thesis version fixed for the first scan after collection. If you edit a threshold at the same time, a changed survivor list has two possible causes and you've lost the clean comparison.

Run the unchanged thesis, inspect an expected result, and trace a feature back to its stored period and source. Then compare it with the prior run if you have one. Comparing two scan runs can locate entries, exits, and score movement, but the difference itself doesn't prove which new row caused the move. Use the dated filing or price record for that.

Keep a brief collection note beside the run: source connected, dataset refreshed, scope used, and any gaps left unresolved. You won't need a grand data catalog. You need enough record to explain why today's run had inputs yesterday's run lacked.

A setup that stays useful

The practical sequence is short:

  1. Open a thesis and list its raw data dependencies.
  2. Identify the first dependency the local lake can't support.
  3. Connect the provider that supplies it.
  4. Run a narrow collection job and inspect coverage.
  5. Expand the refresh to the thesis universe.
  6. Rerun the saved thesis without changing its rules.
  7. Record any remaining gap before reading the result.

That sequence scales better than connecting every source on day one. It also keeps the product's adaptability where it belongs. You choose the rule, you choose the evidence it may use, and you can see where that evidence runs out. A provider connection is plumbing. The research begins when you can explain why each input is there and what the thesis does when it isn't.

Research tooling, not investment advice. Nothing here is a recommendation to buy, sell, or hold any security. Screens, scores, and backtests are informational only; backtested results are hypothetical, exclude costs such as commissions and slippage, and do not guarantee future results. Verify against primary filings and make your own decisions.

Want to try this on your own rules? Quantery is free for 14 days: the full app, no card required.

← All articles