What happens to your history when a ticker gets renamed?

Tickers are labels, and labels get reassigned. A company rebrands, restructures, or simply wants a better set of four letters, and the symbol changes while the company does not — the string you have been storing is the only thing that moved. Mergers are the harder case, because there the security may genuinely not be the same continuing entity, and a remap that pretends it is will splice two different histories into one series.

These are real changes returned by /symbol-change-history?from=2026-01-01&to=2026-03-31, called on 2026-07-28:

• MMC → MRSH, effective 2026-01-14 (Marsh)
• MPW → MPT, effective 2026-02-02 (Medical Properties Trust)
• ARMN → ARIS, effective 2026-02-19 (Aris Mining)
• SAVA → FLNA, effective 2026-03-11
• and on 2026-02-23 a block of Invesco ETFs at once: PIN → IMVP, PHB → IFLN, KBWR → FDIQ, SPVU → QVMT

That is one quarter, on one country's exchanges, with dozens of entries. This is not a rare event. Here is a different, pinned window — two weeks of October 2022, settled history, so the call above the table returns the same seven rows whenever you run it:

The failure mode, and why it is silent

Suppose your database is keyed on the ticker string. On 2026-02-02, MPW stops producing new rows. Nothing errors. No status code changes. You have a perfectly valid series that simply stops.

Meanwhile MPT starts producing rows with no history behind it. If nothing ever joins the two, you have manufactured two artefacts at once: a company that vanished in February, and a company that appeared from nowhere in February. Backtest across that window and the vanished one drops out of your universe — which is the survivorship problem from the survivorship-and-biases lesson, except this time you created it yourself, with a key choice, rather than inheriting it from a data provider.

The endpoint

/symbol-change-history returns rows of exchange, old_symbol, new_symbol, company_name and effective.

Two things about it are unusual enough to note. First, from and to are both required: true — most date parameters in this API are optional, these are not. The server does not enforce it: on 29 September 2026 a call with neither answered 200 with 326 changes, effective 2025-09-29 to 2026-09-28, the trailing year and nothing older, and a call with only to answered 200 as well. Forget the dates and you get a plausible list with the history missing, not an error. Second, it is documented at 5 API calls per request rather than 1, because it sits in the exchange-metadata family.

And the honest limitation, taken straight from the spec's own description: "Only US exchanges are currently supported". Coverage runs back to 2021-04-05 — which is worth checking for yourself rather than trusting, because a later start date is widely quoted, including by tooling built on this endpoint, and the data goes back more than a year further than that. So this endpoint solves the problem for US listings and does not solve it anywhere else. Outside the US you need a different anchor — an ISIN where you have one, or the venue's own reference data.

The design lesson, which outlives this API

Do not key on something that changes. Assign your own internal identifier and treat every external code — ticker first, but ISIN too — as a mutable label attached to it. An ISIN is far steadier than a ticker and is the better external anchor of the two, but it is not immutable either: a change of domicile, a new share class or a security replacement can issue a new one. Then a rename is one row in a mapping table instead of a silent break in every series you own.

If you already key on tickers — most people do, at first — the cheap mitigation is a scheduled job that pulls recent symbol changes and reconciles them before they cause a gap, rather than after somebody notices a chart ending in February.

Try it now

1. Here is a 92-day window of /symbol-change-history, 1 June to 31 August 2026, both dates set because both are required. On 28 September 2026 it held 107 renames; the table shows the two at each end. Check whether any of these symbols sit in a universe you track, and work out from the count how many renames a year that rate implies.

2. Take one pair from the list above, MPW to MPT, and read both sides across the effective date of 2 February 2026. Below are /eod/MPW.US?from=2026-01-01&to=2026-03-31 and /eod/MPT.US over the same window. Write down which symbol holds the history, which holds the future, and what the last date under the old symbol tells you.

3. Look at how your own storage identifies an instrument. If the answer is "the ticker", you now know what that costs and roughly how often it will happen.

Build it yourself

Build the failure handling that turns a renamed ticker into one empty row instead of a broken page. When the data does not arrive