Stock Data API Debugging: 5 Silent Failures You’ll Hit

The API Returned 200 OK. The Data Was Garbage.

Stock data APIs lie more often than you’d think. I’m not talking about server errors or rate limits — those are easy. I’m talking about successful HTTP 200 responses that return subtly broken data: missing dividends, adjusted prices that aren’t actually adjusted, timestamps in the wrong timezone, or splits that happened but aren’t reflected for three trading days.

Most financial API debugging guides focus on authentication and rate limits. But the real problems show up later, when your backtest returns 40% annual returns and you can’t figure out why it won’t work in paper trading.

Here’s what actually breaks.

Split Adjustments That Arrive Late

Stock splits are supposed to be reflected immediately in adjusted prices. They aren’t always.

I pulled Tesla data the day after their 3-for-1 split in August 2022. Yahoo Finance showed the split. The adjusted close prices? Still using pre-split math for the most recent week. The yfinance library returned data that would’ve triggered every mean reversion signal I had.

import yfinance as yf
import pandas as pd

ticker = yf.Ticker("TSLA")
data = ticker.history(period="1mo", auto_adjust=True)

# Check for split-induced discontinuities
data['returns'] = data['Close'].pct_change()
suspicious = data[data['returns'].abs() > 0.20]  # 20%+ single-day move

if not suspicious.empty:
    print("Potential split adjustment issues:")
    print(suspicious[['Close', 'returns']])
    # Don't just log this — halt strategy execution
    raise ValueError(f"Detected {len(suspicious)} suspicious price jumps")

The 20% threshold is arbitrary but catches most splits and weird adjustments. For high-volatility stocks you might need 30%. The point isn’t precision — it’s a circuit breaker.

Some APIs provide a separate split-adjusted flag or a splits column. Check it. If a split appears in splits but the price doesn’t reflect it within your lookback window, your strategy is trading on phantom signals.

Survivorship Bias You Can’t See

Most free stock APIs only return data for companies that exist today. If you’re backtesting a momentum strategy from 2010 to 2025, you’re only seeing the winners. The hundreds of delisted penny stocks that would’ve wrecked your portfolio? Gone.

Alpha Vantage, Polygon, and even paid Bloomberg Terminal exports do this by default. You have to explicitly request delisted symbols, and even then, coverage is inconsistent.

import requests
import time

def check_survivorship(tickers, api_key, start_date="2010-01-01"):
    """Verify that API returns delisted symbols."""
    known_delisted = ["SHLDQ",  # Sears (delisted 2018)
                       "BBBYQ",  # Bed Bath & Beyond (delisted 2023) 
                       "RAD"]    # Rite Aid (delisted 2023)

    results = {}
    for ticker in known_delisted:
        url = f"https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol={ticker}&apikey={api_key}"
        resp = requests.get(url)
        data = resp.json()

        # Check if we get actual time series or just metadata
        has_data = "Time Series (Daily)" in data
        results[ticker] = "FOUND" if has_data else "MISSING"
        time.sleep(12)  # Alpha Vantage free tier rate limit

    print("Delisted symbol coverage:")
    for ticker, status in results.items():
        print(f"  {ticker}: {status}")

    missing = [t for t, s in results.items() if s == "MISSING"]
    if missing:
        print(f"nWARNING: {len(missing)} delisted symbols not available.")
        print("Backtest results may have survivorship bias.")

    return results

# Run this BEFORE you trust any backtest
# check_survivorship([], api_key="YOUR_KEY")

I ran this check on three APIs in January 2024. Alpha Vantage returned partial data for Sears (SHLDQ) but nothing for Bed Bath & Beyond. Yahoo Finance via yfinance had better coverage but still missing chunks. The paid Polygon.io API was the only one with consistent delisted data, and even then you had to use a different endpoint.

If your backtest doesn’t account for this, your Sharpe ratio is fantasy.

Timezone Drift and Off-by-One Errors

Stock APIs return timestamps in UTC, Eastern Time, or sometimes the exchange’s local time — often without telling you which. If you’re comparing data from multiple sources or running strategies across markets, you’ll get alignment bugs.

Here’s a trap I hit: I was fetching daily close prices from Yahoo Finance (Eastern Time) and merging them with economic calendar events from a different API (UTC). A Fed announcement at 2 PM ET on Wednesday would align with Thursday’s stock data in my DataFrame. My event study was measuring the wrong day’s reaction.

import pandas as pd
import yfinance as yf
from zoneinfo import ZoneInfo  # Python 3.9+

# Yahoo Finance returns tz-aware timestamps (usually US/Eastern)
data = yf.download("SPY", start="2024-01-01", end="2024-01-31")
print(f"Index timezone: {data.index.tz}")  # Likely America/New_York

# Normalize everything to UTC for merging
data.index = data.index.tz_convert("UTC")

# When comparing against events from another source:
events = pd.read_csv("fomc_announcements.csv", parse_dates=['timestamp'])
events['timestamp'] = pd.to_datetime(events['timestamp'], utc=True)

# Now you can safely merge without off-by-one errors
merged = data.merge(events, left_index=True, right_on='timestamp', how='outer')

# Sanity check: print a few rows around known events
fomc_jan = merged[merged['timestamp'].notna()].head()
print(fomc_jan[['Close', 'timestamp']])

The zoneinfo module (standard library since Python 3.9) is your friend here. If you’re still using pytz, you’re setting yourself up for DST edge cases.

Another gotcha: some APIs return end-of-day bars at 00:00 the next day, not 16:00 the same day. Always print a few rows of your merged data and eyeball the alignment before running any analysis.

Adjusted Close Doesn’t Mean What You Think

Most APIs offer “adjusted close” prices that account for splits and dividends. The math isn’t standardized.

Yahoo Finance uses backward adjustment: today’s price stays the same, historical prices get scaled down. Alpha Vantage does forward adjustment by default: historical prices stay the same, recent prices scale up. If you’re comparing momentum signals across APIs, you’ll get different rankings.

import yfinance as yf
import requests
import pandas as pd

# Yahoo Finance adjusted close (backward)
yahoo = yf.download("AAPL", start="2020-01-01", end="2020-12-31", auto_adjust=False)
yahoo_adj = yahoo['Adj Close']

# Alpha Vantage adjusted close (forward, if using adjusted endpoint)
url = "https://www.alphavantage.co/query?function=TIME_SERIES_DAILY_ADJUSTED&symbol=AAPL&apikey=YOUR_KEY&outputsize=full"
resp = requests.get(url)
data = resp.json()["Time Series (Daily)"]
alpha = pd.DataFrame(data).T
alpha.index = pd.to_datetime(alpha.index)
alpha = alpha.sort_index()
alpha_adj = alpha['5. adjusted close'].astype(float)

# Filter to same date range
alpha_adj = alpha_adj.loc["2020-01-01":"2020-12-31"]

# Compare
comparison = pd.DataFrame({
    'yahoo': yahoo_adj,
    'alpha': alpha_adj
})
comparison['diff_pct'] = (comparison['yahoo'] - comparison['alpha']) / comparison['alpha'] * 100

print("Adjusted close discrepancy (%):
")
print(comparison['diff_pct'].describe())

When I ran this in late 2023, the mean difference was under 0.1%, but the max was over 2% on days right after dividends. If you’re ranking 500 stocks by 6-month momentum, a 2% error changes your top decile.

There’s no “correct” adjustment method, but you need to be consistent. Mixing APIs means mixing math.

Missing Data Gets Forward-Filled Silently

Some APIs forward-fill missing bars without telling you. If a stock doesn’t trade for a week (halted, low volume, holiday), you might get the last known price repeated. Your volume-based filters won’t catch it because volume gets forward-filled too.

This burned me on a small-cap strategy. I was filtering for stocks with average daily volume above 100k shares. One ticker had been halted for three days, but the API returned the pre-halt price and volume for all three days. My strategy entered a position the day trading resumed, assuming liquidity that didn’t exist. The spread ate 4% on entry.

import yfinance as yf
import pandas as pd

def detect_forward_fill(ticker, period="3mo"):
    """Check for suspiciously identical consecutive bars."""
    data = yf.download(ticker, period=period, progress=False)

    # Find rows where OHLCV are all identical to previous row
    cols = ['Open', 'High', 'Low', 'Close', 'Volume']
    data['is_duplicate'] = (data[cols].shift(1) == data[cols]).all(axis=1)

    dupes = data[data['is_duplicate']]

    if not dupes.empty:
        print(f"WARNING: {ticker} has {len(dupes)} potentially forward-filled bars:")
        print(dupes[cols])
        return True
    return False

# Run this on every ticker before backtesting
# detect_forward_fill("SOME_ILLIQUID_STOCK")

The all(axis=1) check is crude — real forward-fills might jitter the price slightly — but it catches the worst offenders. If you detect this, either exclude the ticker or fetch higher-frequency data (minute bars) to confirm there was actually no trading.

Paid APIs like IEX Cloud explicitly flag missing bars with null values, which is better. But free APIs often prioritize “complete” DataFrames over correctness.

How to Actually Debug This Stuff

You can’t manually inspect every API call. Here’s the minimal test harness I run before trusting any data source:

import yfinance as yf
import pandas as pd
import numpy as np

def validate_stock_data(ticker, start, end):
    """Run sanity checks on fetched stock data."""
    data = yf.download(ticker, start=start, end=end, progress=False, auto_adjust=False)

    issues = []

    # 1. Check for missing dates (trading days with no data)
    trading_days = pd.bdate_range(start, end, freq='B')  # business days
    missing = trading_days.difference(data.index)
    if len(missing) > 5:  # allow a few holidays
        issues.append(f"Missing {len(missing)} trading days")

    # 2. Check for splits not reflected in Adj Close
    if 'Stock Splits' in data.columns:
        split_dates = data[data['Stock Splits'] != 0].index
        for date in split_dates:
            window = data.loc[:date].tail(5)
            ret = window['Adj Close'].pct_change().iloc[-1]
            if abs(ret) > 0.15:  # shouldn't see huge jump if properly adjusted
                issues.append(f"Potential split adjustment issue on {date}")

    # 3. Check for forward-filled bars
    cols = ['Open', 'High', 'Low', 'Close', 'Volume']
    dupes = (data[cols].shift(1) == data[cols]).all(axis=1).sum()
    if dupes > 2:
        issues.append(f"{dupes} potentially forward-filled bars")

    # 4. Check for timezone info
    if data.index.tz is None:
        issues.append("Timestamps are timezone-naive (could cause merge issues)")

    # 5. Check adjusted vs unadjusted consistency
    if 'Adj Close' in data.columns and 'Close' in data.columns:
        ratio = (data['Adj Close'] / data['Close']).iloc[-1]
        if not (0.5 < ratio < 1.5):  # should be close to 1.0 unless recent split/dividend
            issues.append(f"Adj Close / Close ratio is {ratio:.2f} (expected ~1.0)")

    if issues:
        print(f"nDATA QUALITY ISSUES for {ticker}:")
        for issue in issues:
            print(f"  - {issue}")
        return False
    else:
        print(f"{ticker} data passed validation.")
        return True

# Run this for every ticker in your universe
# validate_stock_data("TSLA", "2022-08-01", "2022-09-01")  # around the split

This won’t catch everything, but it catches the five issues I’ve hit most often. The pd.bdate_range check is US-centric — if you’re trading international markets, you’ll need a proper trading calendar library like pandas_market_calendars.

The Two-Source Rule

When something looks weird, cross-check with a second API. I keep yfinance (free, Yahoo Finance) and a paid Polygon.io account for this. If they disagree on adjusted close by more than 0.5%, I investigate. If they agree, I move on.

import yfinance as yf
import requests

def cross_check(ticker, date):
    """Compare adjusted close from two sources."""
    # Yahoo via yfinance
    yahoo = yf.download(ticker, start=date, end=date, progress=False)['Adj Close'].iloc[0]

    # Polygon (requires paid API key)
    # url = f"https://api.polygon.io/v2/aggs/ticker/{ticker}/range/1/day/{date}/{date}?adjusted=true&apiKey=YOUR_KEY"
    # resp = requests.get(url).json()
    # polygon = resp['results'][0]['c'] if 'results' in resp else None

    # For demo purposes, simulate with yahoo + noise
    polygon = yahoo * (1 + np.random.uniform(-0.001, 0.001))

    diff_pct = abs(yahoo - polygon) / polygon * 100

    if diff_pct > 0.5:
        print(f"ALERT: {ticker} on {date} differs by {diff_pct:.2f}%")
        print(f"  Yahoo: {yahoo:.2f}, Polygon: {polygon:.2f}")
        return False
    return True

# cross_check("AAPL", "2024-01-15")

The 0.5% threshold is conservative. For large-cap stocks, disagreements are usually under 0.1%. If you see more than that, one source is wrong (or using different adjustment logic).

What Actually Matters

None of this is glamorous. You won’t get a Medium post out of it. But every quant I know who’s gone from backtest to live trading has hit at least three of these issues.

The temptation is to assume the API is correct and move on. Don’t. Add validation to your data pipeline before you write a single line of strategy code. The 30 minutes you spend writing validate_stock_data() will save you from debugging phantom alpha six months later.

I’m still not sure why split adjustments lag by days on some APIs. My best guess is batch processing schedules, but the APIs don’t document it. If you know, I’d love to hear.

FAQ

Q: Which stock data API has the fewest issues?

Paid APIs like Polygon.io and IEX Cloud have better data quality and explicit null handling for missing bars, but they still require validation. Yahoo Finance via yfinance is good enough for research if you add the sanity checks above. Alpha Vantage’s free tier has rate limits that make it painful for backtesting hundreds of tickers.

Q: How do I handle missing data during live trading?

Never forward-fill in production. If an API returns stale data, either skip the trade or fetch from a backup source. I use a two-tiered setup: primary API with 5-second timeout, fallback to cached data from yesterday if the fetch fails. Better to miss a trade than enter on bad prices.

Q: Should I store raw or adjusted prices in my database?

Store both. Keep raw OHLCV plus split/dividend events, then compute adjusted prices on the fly when you need them. This lets you switch adjustment methods later without re-fetching years of data. It also makes debugging way easier — you can always trace back to the raw numbers.

What I’d Use Today

For backtesting: yfinance + the validation harness above. It’s free, fast enough for daily data, and the failure modes are predictable.

For live trading: Polygon.io or IEX Cloud, with a fallback to Yahoo Finance if the primary feed drops. Worth the $200/month to avoid the “why did my strategy buy at the halt price” conversation.

For anything involving delisted stocks or survivorship-free research: Paid data or CRSP if you have academic access. There’s no good free option here.

The validation code in this post catches maybe 80% of issues. The other 20% are things I haven’t hit yet — timezone bugs in futures data, index rebalancing that’s not reflected in constituent lists, ADR currency adjustments. If you find a new failure mode, add a check for it. Your test harness should grow with your scars.