Ticker Symbol Change History API by CIK

Ask the StockFit API for FB today and you get the ProShares S&P 500 Dynamic Buffer ETF, an ETF with SEC CIK 1174610. Not Facebook, and not Meta. Meta Platforms left that ticker on June 9, 2022, and the symbol later went to an unrelated fund. Any dataset keyed on the string FB now holds two issuers' histories under one key, and nothing in the data warns you.

This post is a working guide to ticker symbol change history: how to find a company's former names and prior tickers, why a name change and a ticker change are different events, which CIK survives a merger, and a short Python pattern that keeps backtests and watchlists on the right company. Every response below was pulled from the live API on 2026-10-26, and every date comes from the company's own SEC filing or release.

Why a ticker symbol is not a permanent identifier

A ticker is a label an exchange assigns to a listing. It moves in two ways, and each breaks historical data differently:

• Rename. The same company trades under a new symbol. Keyed by ticker, its history splits in two: everything before the change sits under the old symbol, everything after under the new one, and a query for either half returns a series that starts or stops for no economic reason.
• Reuse. A freed symbol is assigned to a different issuer. Keyed by ticker, two unrelated histories are joined into one series. This is worse than a split, because the data still looks complete.

The fix is to key on an identifier that belongs to the issuer, not the listing. For SEC filers that is the Central Index Key (CIK): it stays with the filer through renames and ticker changes, and the security-level CUSIP and composite FIGI give you two more anchors. The four companies in this post show each failure mode:

Event lists of old symbol, new symbol and effective date are the usual answer to this problem, and they help with renames. They cannot tell you on their own that a symbol was later reused, and their coverage window matters. EODHD's US stock symbol rename history API states: “The data starts from 2022-07-22 and is updated daily. Only US exchanges are supported for the moment.” A feed that starts on that date does not include the FB to META change of June 9, 2022. Delisted companies are the other half of the same problem, covered in our guide to survivorship bias in point-in-time data; this post stays on renames and reuse.

The FB trap: one ticker symbol, two issuers

Resolve the old Facebook ticker with /api/lookup/symbol (response abridged):

curl "https://api.stockfit.io/v1/api/lookup/symbol?symbol=FB" \
  -H "Authorization: Bearer $STOCKFIT_API_KEY"

{
  "symbols": ["FB"],
  "exchanges": ["Cboe BZX"],
  "name": "ProShares S&P 500 Dynamic Buffer ETF",
  "cik": 1174610,
  "seriesId": 93206,
  "type": "etf",
  "compositeFigi": "BBG01VRMNFB1",
  "status": "operating",
  "priorTickers": []
}

The response is correct for today: FB is the symbol of a ProShares fund listed on Cboe BZX. It is also exactly what breaks a pipeline that stored FB years ago and re-resolves it now. The same thing happens one step later, at the price endpoint:

curl "https://api.stockfit.io/v1/api/price/history?symbol=FB&resolution=1mo" \
  -H "Authorization: Bearer $STOCKFIT_API_KEY"

{
  "cik": 1174610,
  "symbol": "FB",
  "resolution": "1mo",
  "data": [
    [1748736000000, 39.56732177734375],
    [1751328000000, 39.65823745727539],
    ...
  ],
  "latestQuote": { "ts": "2026-10-23T00:00:00.000Z", "close": 45.662601470947266, "volume": 1459 }
}

That is 18 monthly bars starting 2025-06-01, an adjusted close of about $39.57 at the start and $45.66 on 2026-10-23. A backtest that asked for “FB” gets a buffered S&P 500 fund, with no error. The one signal is the cik field at the top of the response: 1174610, not Meta's 1326801. Check it on every price response you store.

Request prices by CIK and the rename disappears

Ask /api/price/history for Meta by CIK instead, across the week the ticker changed (response abridged):

curl "https://api.stockfit.io/v1/api/price/history?cik=1326801&from=2022-06-06&to=2022-06-10&adjusted=false" \
  -H "Authorization: Bearer $STOCKFIT_API_KEY"

{
  "cik": 1326801,
  "symbol": "META",
  "resolution": "1d",
  "data": [
    [1654473600000, 194.25],
    [1654560000000, 195.64999389648438],
    [1654646400000, 196.63999938964844],
    [1654732800000, 184],
    [1654819200000, 175.57000732421875]
  ]
}

One continuous series: the close was $196.64 on June 8, 2022, the last day under FB, and $184.00 on June 9, the first day under META. The ticker changed; the issuer and its price history did not. Bars this old are outside the Free plan's two-year price window, so this request needs Starter or above. Starter covers five years of prices; Stock, ETF and Pro cover twenty.

Search will not take you back from a reused ticker

Once a symbol has moved on, the ticker alone cannot lead you back to its earlier holder. /api/lookup/search for FB with includeDelisted=true ranks the ProShares ETF first, and a search for Facebook returns an empty array, because search does not match former names. The two ways back are a former-name lookup, covered next, and an identifier you stored when you first saw the company. No StockFit endpoint answers “which company held ticker X on date Y”, so store the CIK at ingest.

Former names and prior tickers by CIK

/api/lookup/former-names searches the legal names a filer has used on EDGAR and returns the current profile of each match (response abridged):

curl "https://api.stockfit.io/v1/api/lookup/former-names?searchString=Facebook&limit=5" \
  -H "Authorization: Bearer $STOCKFIT_API_KEY"

[
  {
    "symbols": ["META"],
    "exchanges": ["Nasdaq"],
    "name": "Meta Platforms, Inc.",
    "cik": 1326801,
    "seriesId": 0,
    "type": "stock",
    "compositeFigi": "BBG000MM2P62",
    "formerNames": ["Facebook Inc"],
    "status": "operating",
    "priorTickers": [
      { "symbol": "FB", "exchange": "Nasdaq", "lastSeen": "2022-03-31" }
    ]
  }
]

Every profile from the lookup endpoints carries the same identity fields, so the former-name search, a symbol lookup and a batch lookup all hand you something you can store:

lastSeen is a lower bound, not a change date

lastSeen is the most recent date StockFit confirmed the company under that ticker. It is not the day the ticker stopped. In each of the three renames in this post with a sourced effective date, the company kept trading under the old ticker for months after lastSeen:

Use lastSeen to answer “was this company still trading as FB on March 31, 2022?” (yes). Do not use it as the date to switch symbols in a time series: you would cut over 70 to 113 days early. For the operating companies in this post these values are quarter ends; for funds they can be specific days. Take the effective date from the company's 8-K or press release.

Search with the full legal name

The former-name search matches substrings, so short terms are noisy. With limit=5, Square returns 5 North Square funds (CIK 1750821) and no Block. With limit=50 it returns 35 matches, Block among them, next to Madison Square Garden, Pershing Square, Townsquare Media and Klook (formerly Esquared Capital). Search for Square, Inc. and Block is the only result. If the old ticker was not reused, the shorter path is a symbol lookup on it: SQ still resolves to Block, CIK 1512673.

Name change vs ticker change: two events, two dates

It is tempting to treat “Facebook became Meta” as one event. Meta's filings show three:

• October 28, 2021: the name. The 8-K filed that day reports that Facebook, Inc. “changed its corporate name to Meta Platforms, Inc.” through an amended certificate of incorporation filed in Delaware on October 28, 2021.
• A ticker that never happened. The same 8-K says the company intended to begin trading under “MVRS”, expected to be effective on December 1, 2021. It did not trade under MVRS.
• June 9, 2022: the ticker. The 8-K filed May 31, 2022 states that Class A common stock “will begin trading on The Nasdaq Global Select Market under the new ticker symbol 'META' prior to market open on June 9, 2022.”

So for more than seven months, Meta Platforms traded as FB. A pipeline that switches tickers on the name-change date, or on an announced date, gets the window wrong. Block shows the same split: SEC's submissions record ends the Square, Inc. name in December 2021, while the ticker stayed SQ until January 21, 2025.

What SEC's own data gives you

SEC publishes filer metadata through its EDGAR APIs, which describe the submissions JSON as containing “metadata such as current name, former name, and stock exchanges and ticker symbols of publicly-traded companies.” Two things are worth knowing. Former names there come with from and to dates, which StockFit's formerNames does not carry. Tickers there are current only: Meta's record lists META, Block's lists XYZ and BSQKZ, and neither lists the old symbol.

# SEC's own view of the same CIK (JSON, send a User-Agent that names you)
curl -A "YourApp/1.0 (you@example.com)" https://data.sec.gov/submissions/CIK0001326801.json
# -> "tickers": ["META"], plus formerNames entries with from and to dates

The two sources fit together. Use SEC's submissions record when you need the dates of a legal name, and priorTickers when you need to know which symbols a CIK used to trade under.

Mergers and ticker changes: which CIK survives

A merger can leave the famous name on one CIK and the history on another. When United Technologies and Raytheon Company combined, the 8-K filed April 8, 2020 reports that “the Company changed its name to Raytheon Technologies Corporation and its ticker symbol to 'RTX'” at the merger's effective time on April 3, 2020. “The Company” is United Technologies, CIK 101829, later renamed RTX Corp. Raytheon Company, which traded as RTN, is a separate filer. One /api/lookup/batch request shows both, plus a company with no successor (response abridged):

curl "https://api.stockfit.io/v1/api/lookup/batch?symbols=UTX,RTN,TWTR" \
  -H "Authorization: Bearer $STOCKFIT_API_KEY"

{
  "UTX": {
    "symbols": ["RTX"],
    "name": "RTX Corp",
    "cik": 101829,
    "compositeFigi": "BBG000BW8S60",
    "formerNames": ["RAYTHEON TECHNOLOGIES CORP", "UNITED TECHNOLOGIES CORP /DE/"],
    "priorTickers": [{ "symbol": "UTX", "exchange": "NYSE", "lastSeen": "2019-12-31" }]
  },
  "RTN": {
    "symbols": [],
    "name": "RAYTHEON COMPANY",
    "cik": 1047122,
    "formerNames": ["HE HOLDINGS INC"],
    "priorTickers": [{ "symbol": "RTN", "exchange": "NYSE", "lastSeen": "2019-12-31" }]
  },
  "TWTR": {
    "symbols": [],
    "name": "Twitter, Inc.",
    "cik": 1418091,
    "formerNames": ["Twitter Inc"],
    "status": "delisted",
    "priorTickers": [{ "symbol": "TWTR", "exchange": "NYSE", "lastSeen": "2022-06-30" }]
  }
}

A history keyed on the name “Raytheon” can land on either CIK: 101829, the surviving issuer that carries the United Technologies record and today's RTX listing, or 1047122, the former Raytheon Company with no current symbol. Neither is wrong as a filer; they are just different entities. Decide which one your model means and store that CIK. The batch response is keyed by the symbol you sent, so UTX comes back as RTX Corp without any extra mapping step.

No successor ticker: TWTR

Twitter is the case with no new ticker. The profile still resolves (CIK 1418091, empty symbols), and the company's last 10-Q covers the period ended 2022-06-30, the same date as its lastSeen. It kept filing after that: its Form 15-12G, which deregisters the stock, was filed on 2022-11-07. Ask the price endpoint for TWTR and you get an HTTP 400, by design. The endpoint documentation says a ticker identifies an instrument only while its listing is active, so “a selector resolving to a delisted listing returns 400 rather than another company's prices.” Handle that 400 as “no active listing” in your code, not as a transient error to retry.

Look up a company by CIK, CUSIP or FIGI

If your source data already carries a CIK, CUSIP or FIGI, skip the ticker entirely. /api/lookup/cik, /api/lookup/cusip and /api/lookup/figi return the same profile shape, and for Meta all four of these requests return the identical profile shown in the former-name example:

# Four identifiers, one company: each returns the same Meta profile
curl "https://api.stockfit.io/v1/api/lookup/symbol?symbol=META" -H "Authorization: Bearer $STOCKFIT_API_KEY"
curl "https://api.stockfit.io/v1/api/lookup/cik?cik=1326801" -H "Authorization: Bearer $STOCKFIT_API_KEY"
curl "https://api.stockfit.io/v1/api/lookup/cusip?cusip=30303M102" -H "Authorization: Bearer $STOCKFIT_API_KEY"
curl "https://api.stockfit.io/v1/api/lookup/figi?figi=BBG000MM2P62" -H "Authorization: Bearer $STOCKFIT_API_KEY"

CUSIP is especially useful across a pure ticker change. Block's announcement of the XYZ symbol says: “The CUSIP for the NYSE listing and the ISIN for the ASX listing will remain unchanged.” Looking up CUSIP 852234103 returns Block, Inc., CIK 1512673, current symbols XYZ and BSQKZ, prior ticker SQ: one key on both sides of the change. Holdings files such as 13F and N-PORT report positions by CUSIP, so this is often the most direct path from a filing to a company. The same selectors work on the price endpoint, which accepts cik, cusip and composite_figi as well as symbol.

A caution for funds: a fund trust holds many series under one CIK, so for an ETF or mutual fund store the CIK together with seriesId, or the composite FIGI. The ProShares fund now trading as FB is series 93206 of CIK 1174610.

Resolve once, store the CIK: a Python pattern for backtests

Everything above reduces to one rule: resolve a ticker to its CIK the moment it enters your system, store the CIK, and never resolve the same ticker again for that record. A ticker resolved today describes today. If you saved FB in 2021 and resolve it now, you get the ETF. If you saved CIK 1326801 in 2021, you get Meta forever.

import datetime
import os

import requests

BASE = "https://api.stockfit.io/v1/api"
HEADERS = {"Authorization": f"Bearer {os.environ['STOCKFIT_API_KEY']}"}


def get(path, **params):
    r = requests.get(f"{BASE}/{path}", params=params, headers=HEADERS, timeout=60)
    r.raise_for_status()
    return r.json()


def resolve(symbols):
    """Resolve tickers to a stored identity. Run this when a symbol first enters your system."""
    identities = {}
    for i in range(0, len(symbols), 50):  # /lookup/batch takes up to 50 symbols
        chunk = symbols[i:i + 50]
        profiles = get("lookup/batch", symbols=",".join(chunk))
        for sym in chunk:
            p = profiles.get(sym)  # missing symbols are omitted, never guessed
            if p is None:
                identities[sym] = None
                continue
            prior = [t["symbol"] for t in p["priorTickers"]]
            if sym in p["symbols"]:
                state = "current"
            elif not p["symbols"]:
                state = "no_active_listing"
            elif sym in prior:
                state = "renamed"
            else:
                state = "review"
            identities[sym] = {
                "cik": p["cik"],
                "seriesId": p["seriesId"],
                "compositeFigi": p["compositeFigi"],
                "name": p["name"],
                "currentSymbols": p["symbols"],
                "state": state,
                "resolvedOn": datetime.date.today().isoformat(),
            }
    return identities


def prices(identity, start, end):
    """Fetch bars by CIK, then confirm the series belongs to the issuer you stored."""
    data = get("price/history", cik=identity["cik"], **{"from": start, "to": end})
    if data["cik"] != identity["cik"]:
        raise ValueError(f"price series is CIK {data['cik']}, expected {identity['cik']}")
    return data["data"]

Given the batch responses for three of the tickers in this post (pulled 2026-10-26), resolve() stores:

ids = resolve(["SQ", "UTX", "TWTR"])
# SQ   -> cik 1512673 (Block, Inc.), currentSymbols ["XYZ", "BSQKZ"], state "renamed"
# UTX  -> cik 101829 (RTX Corp), currentSymbols ["RTX"], state "renamed"
# TWTR -> cik 1418091 (Twitter, Inc.), currentSymbols [], state "no_active_listing"

Three details make this pattern hold up:

• The state field only catches renames. A reused ticker resolves to its new holder, with the symbol in symbols, so it comes back as current. Only a CIK stored earlier can tell you the holder changed. When you re-check a watchlist, compare the fresh CIK with the stored one and alert on a mismatch.
• Missing means missing. /api/lookup/batch omits symbols it cannot resolve, so record None and review it by hand rather than guessing from a name.
• Check the CIK on the way back. The prices helper raises if the series belongs to another issuer, which is how the FB trap would surface if a ticker ever slipped through.

All lookup endpoints in this post are on every plan, including Free, so you can resolve a whole universe before paying for anything; price depth is what varies by plan. For the fund side of the same problem, where a symbol belongs to a series inside a trust, read how we map a CIK to a fund ticker. For the fundamentals side, keying statements on CIK and filing date, see point-in-time data for backtesting. If you are not set up yet, a free API key is enough to run every lookup above.

FAQ