How should I choose a Taiwan stock data source for Python?

Six questions that decide what you need

• How far back do you need? If 'from now on' is enough, saving the official snapshot daily works. If you need years of existing history, you need a source that already accumulated it.
• Does your universe need delisted tickers? A backtest does. A live monitor does not. A source that cannot return a delisted symbol will inflate your results.
• Do you need to reason about when a figure became public? Fundamental strategies do; a pure price-and-volume strategy often does not.
• Do you need both the listed and the OTC market? On the official side these are separate endpoints with different field vocabularies.
• Do you need real time? If so, post-close sources — ours included — are the wrong tool, and you want a quote vendor.
• Are you willing to run the schedule, the cleaning and the gap-filling yourself? If yes, the free path is genuinely viable. If no, what you are buying is time, not better numbers.

Five checks you can run yourself

None of this requires trusting a comparison article, including this one. Each check takes a minute.

• Query a ticker you know has delisted. Nothing back means survivorship bias.
• Ask for a date range from two years ago. If you only ever get the latest day, it is a snapshot source and the history is yours to accumulate.
• Check whether fundamentals can be tied to a publication moment. Only a period end date, with no way to reason about filing timing, means look-ahead cannot be avoided.
• See how gaps are represented. A hole quietly filled with the previous value cannot be detected afterwards.
• Check the types. ROC-calendar date strings and numbers-as-strings are work you will be doing.

If you are building a demo, a tutorial or a one-off study

The official open endpoints take no registration and no key, return JSON on a plain GET, and are the first-party source. The trade-off is that they serve the latest period as a snapshot, dates arrive in the ROC calendar, values arrive as strings, and the listed and OTC markets live on separate endpoints. All of that is work you can absolutely do yourself.

If you are building a backtest you need to reproduce

Then the properties you need are queryable history, retained price history for delisted names, and a defensible basis for when each figure became knowable. Miss any one and the result skews optimistic in a way that never shows up in the performance report — which is why it is worth settling when you pick the source rather than after you have a number you like.

If you are wiring this into an AI agent or an automated pipeline

You will want a stable shape, a machine-readable way to discover what exists, and per-row traceability back to the source. Responses here carry provider, source_role and lineage, and there are llms.txt and openapi.json for programmatic discovery. That matters little to a human reader and quite a lot to an agent.

Where we fit, and where we do not

• Fits: queryable date ranges; price history retained for stopped-trading names; listed and OTC in one schema with the market labelled; dates and numbers already typed; provider and lineage on every row.
• Does not fit: no real-time quotes. This is historical and post-close data.
• Fits: as_of filters by knowledge date server-side, and the response reports as_of_applied plus the field it cut on. The knowledge date is the statutory filing deadline rather than the observed announcement, so it is conservative rather than exact.
• Does not fit: no single site-wide gaps field. Different datasets signal gaps differently.
• Partly: adjusted prices are not served ready-made. The official adjustment factors are, and you compute the back-adjusted series yourself.

You can use more than one

A common arrangement is to take daily increments from the official endpoint and backfill the past from an accumulated history. The numbers reconcile because the origin is the same. Choosing a source is choosing which part of the work you do, not picking a side.

Common questions