台股 API 完整指南：上市、上櫃、ETF、財報與即時行情資料怎麼串接

什麼是台股 API？

台股 API 是讓程式透過 HTTP request、WebSocket、檔案下載或其他資料介面取得台灣股票市場資料的服務。資料可能來自交易所、櫃買中心、公開資訊觀測站、券商、資料供應商或商用 financial data API。

對一般投資人來說，台股資料可能只是股價、成交量和漲跌幅。對開發者來說，台股資料需要被轉換成可重複使用的資料模型，例如：

• 股票代號與市場別
• 每日 OHLCV
• 即時 quote
• 財報欄位
• ETF 成分股
• 法人買賣超
• 交易日曆
• 除權息與 corporate actions
• API response schema
• error handling 與 rate limit

真正可用於產品的台股 API，重點不是能不能抓到資料，而是資料能不能長期穩定地被同一套程式消費。

台股資料可以分成哪些類型？

台股資料通常可以拆成幾個層級。這樣拆分的好處是，開發者可以依照使用情境選擇資料，不需要一開始就把所有資料接進系統。

上市、上櫃、興櫃與 ETF：開發時要注意什麼？

台股市場不是單一資料表。常見資料至少會遇到：

• 上市股票
• 上櫃股票
• 興櫃股票
• ETF
• 指數
• 權證、受益證券與其他商品

如果 API 沒有明確標示 market 或 instrument type，後續很容易在回測、搜尋、資料清洗時出錯。

例如，2330 是上市股票，部分中小型公司可能在上櫃市場，ETF 則有自己的商品特性。對使用者介面來說，它們都可能被搜尋成股票代號。但對資料管線來說，這些商品應該有清楚的分類。

Recommended schema

{
  "symbol": "2330",
  "name": "台積電",
  "market": "twse",
  "instrument_type": "stock",
  "currency": "TWD",
  "is_active": true
}

這種 schema 的好處是，使用者可以用同一個 search endpoint 找到商品，但資料工程師仍然可以在後端保持清楚的分類。

即時行情、延遲行情、盤後資料與歷史資料的差異

很多人搜尋台股 API 時，其實沒有先定義自己要的是哪一種資料。即時行情、延遲行情、盤後資料和歷史資料的成本、授權、更新頻率與使用情境都不同。

公開資料、交易所資料與商用 API 的差異

台股資料可以從不同來源取得。開發者要先理解這些來源的定位，才能決定要怎麼設計資料架構。

TW Market Data 的定位是最後一類：把台股資料整理成 developer-friendly 的 financial data API，讓使用者可以把資料接進 application、backtest、dashboard 或 AI agent workflow，而不是每個團隊都重新處理一次資料清洗和欄位標準化。

一個好用的台股 API schema 應該長什麼樣子？

好的 API schema 應該讓使用者一眼看懂資料，不需要猜欄位單位，也不需要自行判斷日期格式。

{
  "data": [
    {
      "date": "2026-04-23",
      "symbol": "2330",
      "market": "twse",
      "open": 812,
      "high": 825,
      "low": 808,
      "close": 821,
      "volume": 35124000,
      "turnover": 28754100000,
      "currency": "TWD"
    }
  ],
  "meta": {
    "source": "tw-market-data",
    "adjusted": false,
    "timezone": "Asia/Taipei"
  }
}

import requests
import pandas as pd

headers = {
    "Authorization": "Bearer YOUR_API_KEY"
}

params = {
    "symbol": "2330",
    "from": "2025-01-01",
    "to": "2025-12-31"
}

response = requests.get(
    "/v1/tw/stocks/ohlcv",
    headers=headers,
    params=params,
    timeout=20
)

response.raise_for_status()

data = response.json()["data"]
df = pd.DataFrame(data)

df["date"] = pd.to_datetime(df["date"])
df = df.sort_values("date")

print(df.head())

台股 API 在量化交易裡怎麼使用？

台股量化交易通常不是從模型開始，而是從資料開始。資料管線不穩定，策略結果就沒有可信度。

一個基本的台股量化流程通常包含：

1. 1. 定義股票 universe
2. 2. 取得歷史 OHLCV
3. 3. 處理交易日曆與缺值
4. 4. 加入財報、法人、ETF 或技術指標資料
5. 5. 產生 signal
6. 6. 建立 portfolio
7. 7. 加入交易成本與滑價
8. 8. 回測績效
9. 9. 檢查風險與資料偏誤

台股 API 在 AI Agent workflow 裡怎麼使用？

AI agent 不能靠語言模型自己猜股價、財報或法人買賣超。金融資料必須由外部工具提供，LLM 才能負責整理、推理、比較與產生結構化結論。

一個台股 AI agent workflow 可以拆成幾個 tools：

tools = [
    "search_stocks",
    "get_stock_profile",
    "get_daily_ohlcv",
    "get_realtime_quote",
    "get_financial_statements",
    "get_monthly_revenue",
    "get_institutional_flows",
    "get_etf_constituents",
    "calculate_risk_metrics"
]

Agent 不應該只輸出一句看多或看空。比較好的 response schema 應該明確標出資料來源、訊號、信心、風險和缺失資料。

{
  "symbol": "2330",
  "signal": "neutral",
  "confidence": 0.62,
  "summary": "價格動能偏強，但估值與短期波動需要進一步檢查。",
  "data_used": [
    "daily_ohlcv",
    "financial_statements",
    "institutional_flows"
  ],
  "risk_flags": [
    "high_recent_volatility",
    "requires_updated_financials"
  ],
  "not_investment_advice": true
}

這種格式比自然語言回答更適合放進 production workflow。它可以被 dashboard 呈現，也可以被下一個 agent、risk manager 或 portfolio process 使用。

選擇台股 API 的 checklist

在選擇台股 API 之前，可以用下面的 checklist 檢查。

• 是否支援上市與上櫃資料？
• 是否支援 ETF 與指數資料？
• 是否提供歷史 OHLCV？
• 是否清楚標示成交量與成交金額單位？
• 是否有交易日曆？
• 是否支援除權息或 adjusted price？
• 是否能查財報、月營收與基本面資料？
• 是否有法人買賣超或籌碼資料？
• 是否支援批次查詢？
• 是否有穩定的 API docs？
• 是否有 rate limit 說明？
• 是否提供錯誤碼與 retry 建議？
• 是否能用於商業產品或 production workflow？
• 是否能被 AI agent / MCP / tool calling 使用？
• 是否清楚說明資料更新時間？

如果只是做一次性的資料分析，公開資料或爬取頁面可能足夠。如果要做 SaaS、dashboard、量化回測或 AI agent，應該優先考慮穩定 schema、文件、授權和資料更新流程。

建議的 API endpoint 設計

以下是 developer-friendly 台股 API 可以採用的 endpoint 結構示意。

GET /v1/tw/stocks/search?q=台積電
GET /v1/tw/stocks/{symbol}/profile
GET /v1/tw/stocks/{symbol}/quote
GET /v1/tw/stocks/{symbol}/ohlcv?from=2025-01-01&to=2025-12-31
GET /v1/tw/stocks/{symbol}/financials
GET /v1/tw/stocks/{symbol}/monthly-revenue
GET /v1/tw/stocks/{symbol}/institutional-flows
GET /v1/tw/etfs/{symbol}/constituents
GET /v1/tw/calendar/trading-days

實際 endpoint 命名不一定要和上面完全相同。重點是路徑必須可預期，response schema 必須穩定，錯誤處理必須清楚。

常見錯誤：把資料抓下來不等於可以做產品

很多台股資料專案會卡在同一個地方：prototype 可以跑，但 production 不能用。

常見問題包括：

• 每個 endpoint 回傳欄位不同
• 同一欄位有時是 string，有時是 number
• 日期格式不一致
• 民國年與西元年混用
• 成交量單位沒有標準化
• 沒有處理停牌或無成交資料
• 沒有保留下市資料
• 沒有明確標示資料更新時間
• 沒有 cache，導致 request 過多
• 沒有 retry，遇到暫時錯誤就中斷 pipeline

資料產品的核心不是抓資料，而是讓資料可以被穩定、重複、可監控地使用。