Stock API: Pricing, Permissions & Access Limits

Stock API: Pricing, Permissions & Access Limits

How are stock API interfaces charged, what data can you access after paying, and what restrictions apply during integration? Pricing typically depends on data type, subscription tier, and billing cycle; permissions must be verified individually for markets, endpoints, and historical ranges; access limits require separate checks on call frequency, per-request data volume, and real-time subscription quotas. Obtaining an API key or purchasing a subscription does not automatically grant access to all stock data.

Here are actionable answers: Tushare's personal historical minute data is publicly priced at 2,000 CNY/year as a standalone permission; TickDB's Basic plan is publicly priced at 99 USD/month, listing 60 API calls/minute, 50 concurrent subscriptions, and 1 WebSocket connection. The data scope and delivery methods differ between the two—price alone should not drive your selection. Free options also have boundaries: Tushare's lower credit tier offers limited data access, while TickDB lists a 7-day curated selection trial. Below is a breakdown by "pricing—permissions—capacity." Prices and documentation were verified on October 18, 2026; confirm against the latest pages and your actual account entitlements before ordering.

How Much Does a Stock API Cost? Start by Understanding What Data You're Buying

Compare prices only for the same data type, use case, and billing cycle. Daily bars, historical minutes, and real-time minutes are not the same entitlement; credit thresholds and standalone paid permissions are not interchangeable.

Tushare's official permissions page lists the following personal tiers:

Item	Listed Price or Threshold	Boundaries to Confirm
120 Credit Tier	0 CNY/year	Unadjusted daily bars; 50 calls/minute, 8,000 calls/day
2,000+ Credit Tier	200 CNY/year starting	Scope determined by endpoint requirements; not a universal pass
Historical Minute Data	2,000 CNY/year	Standalone permission; cannot be substituted with standard credit tiers
Real-time Minute Data	1,000 CNY/month	Monthly subscription; do not confuse with annual pricing

The same page lists separate pricing for institutional users, shown as 10x the personal rate. During procurement, also confirm the account entity and applicable scope; "institutional pricing" itself does not grant permission to resell data externally.

For monthly subscriptions, evaluate price and capacity together. For example, the 60 calls/minute and 50 concurrent subscriptions in the Basic plan are two separate limits: one governs request frequency, the other governs real-time subscription count—they are not interchangeable. Trials listed on official sites also have time limits and instrument scope; do not interpret them as permanent full-market free access.

Final budgets must also account for historical backfills, duplicate requests, and reconnection recovery. Only by listing "data category, user type, scope, update frequency, and billing cycle" on the same requirements sheet can quotes be meaningfully compared.

Sources: Tushare official "Permissions" and related credit tier documentation; subscription prices from official pricing sections, verified October 18, 2026.

Does Having an API Key Mean You Have Permission? Data Scope and Use Case Still Need Verification

An API key primarily serves for authentication; a valid account does not mean all markets, endpoints, and historical ranges are open. Even if a request succeeds, use cases such as public display or redistribution still require separate confirmation under the terms of service or contract.

Actual integration can be divided into three layers: first verify the key and subscription are valid, then test the target market, endpoint, and date range, and finally confirm the project's data usage scope.

Using TickDB as an example, the official API key management endpoint can query plan identifiers, status, expiration time, and remaining seconds. Below is the minimal request from the documentation—replace the placeholder key to execute in your own environment:

curl -H "X-API-Key: YOUR_API_KEY" \
  "https://api.tickdb.ai/v1/apikeys/subscriptions"

A successful response returns a business status code of 0. Key fields to inspect: plan, status, expires_at, and remaining_seconds; active indicates a valid key but does not mean the response lists all data permissions or grants external use rights. This article only verifies documentation and did not execute the request with a paid account.

Figure 1: Integration verification overview. Account status check is only the first step; market, endpoint, historical range, and actual use case still require separate confirmation. Non-official interface screenshot.

Error responses also help diagnose issues: official documentation defines request frequency exceeded, trading product not enabled, historical range exceeded, endpoint access denied, and channel subscription denied as separate business errors. Clients should check both HTTP status and business codes rather than treating all failures as network issues and repeatedly retrying.

Open-source stock data interfaces also require clarification of licensing boundaries. The zhangxiangliang/stock-api repository uses the MIT license, and the README states its data comes from third parties with usage restrictions and disclaimers. Code licensing addresses the conditions for using the project code and cannot substitute for upstream data usage authorization, nor does it constitute a commercial-grade availability commitment.

Sources: Official "API Key Management," "Error Codes," and stock-api README, verified October 18, 2026.

How to Evaluate Access Limits? First Convert Business Requirements to Call Volumes

At minimum, separately check requests per minute, daily or rolling window quotas, per-request return volume, and WebSocket connection and subscription counts. These limit different resources—satisfying one does not mean overall usability.

Suppose you want to poll 500 stocks, refreshing every 5 seconds, with the endpoint allowing 50 symbols per request and 240 active minutes per day: each round requires 10 requests, averaging 120 per minute and 28,800 per day. Adding a 20% retry and recovery buffer, budget for 144 requests/minute and 34,560 requests/day. The runtime duration and batch size here are example parameters and do not represent commitments from any single provider for all endpoints.

The code below only performs offline budgeting—modify parameters according to your actual endpoint:

from math import ceil

symbols = 500
batch_size = 50          # Modify per actual endpoint support
refresh_seconds = 5
active_minutes = 240     # Example runtime duration
headroom = 0.20          # Budget buffer, not measured failure rate

requests_per_round = ceil(symbols / batch_size)
average_rpm = requests_per_round * 60 / refresh_seconds
rounds_per_day = ceil(active_minutes * 60 / refresh_seconds)
daily_requests = requests_per_round * rounds_per_day

print("Requests per round:", requests_per_round)
print("Average requests per minute:", average_rpm)
print("Budgeted requests per minute with buffer:", ceil(average_rpm * (1 + headroom)))
print("Base daily requests:", daily_requests)
print("Budgeted daily requests with buffer:", ceil(daily_requests * (1 + headroom)))

Figure 2: Request budget for hypothetical polling scenario, not endpoint measurement. Beyond average frequency, also check burst limits, connection counts, and subscription counts.

Plugging this requirement into TickDB Basic plan's public limits, basic polling already exceeds 60 requests/minute; switching to real-time subscriptions, monitoring 500 symbols simultaneously also exceeds the 50 concurrent subscriptions limit. This yields a "current approach exceeds this tier's capacity" assessment—next steps should be adjusting refresh strategy, narrowing scope, or verifying other plans, not assuming the approach is viable simply because one stock request succeeds.

Batch size also affects the conclusion: if the target endpoint only queries one symbol at a time, polling 500 stocks with 5-second refresh would require an average of 6,000 requests/minute. Even if average volume stays within limits, batching all requests in one round may trigger short-window restrictions; when multiple processes share an account, also verify whether quotas are shared.

Historical backfills must be calculated separately. Tushare's stk_mins documentation lists a maximum of 8,000 rows per request, 500 requests/minute, and 300,000 rolling 24-hour cumulative requests, requiring a standalone permission. Here, 8,000 refers to return rows, not 8,000 stocks; backfill plans also need to be batched by symbol, date, and record granularity.

When official pages have conflicting information, do not arbitrarily choose the more lenient values. For example, Tushare's daily bar endpoint page lists 500 requests/minute, while the low credit tier permissions page lists 50 requests/minute. Record the discrepancy and determine the effective limit using your account's tier, actual endpoint, and confirmation from the service provider.

Sources: Official pricing sections of the services above, Tushare "Stock Historical Minute Bar" "Daily Bar" and permissions documentation, verified October 18, 2026.

Before Purchasing, How Do You Verify a Stock Data API Fits Your Project?

First conduct small-scale validation with your target data and actual deployment environment, then decide on a plan. Validation should cover at minimum:

• Data fitness for the task: Select actual markets, symbols, adjustment method, granularity, and historical dates to check fields, time zones, trading days, and null values.
• Permissions cover the requirements: Test target endpoints and historical ranges, and separately confirm actual use cases like public display, sharing, or redistribution.
• Capacity is sufficient: Budget separately for normal refresh, historical backfill, retries, and recovery; check frequency limits, return volumes, and real-time subscription restrictions.
• Deployment conditions affect calls: Test network and search functionality in the actual deployment region; the stock-api README explicitly notes that some search features have overseas IP restrictions—do not assume local testing results apply to production.

If your project only needs low-frequency daily bar research, first verify the free tier's coverage and limits; if you need historical minute backtesting, focus on confirming standalone permissions, historical range, and batch return limits; if you need real-time multi-symbol display, include subscription count, connection count, recovery strategy, and display use case in your acceptance criteria. Selection should be based on whether project requirements match actual entitlements, not on single conditions like "there's a free endpoint" or "the plan claims real-time."