Your user typed Apple. Which row do you actually want?

Between a human name and an API call sits a resolution problem that never fully goes away. /search/{query} is the tool for it — and the tool that shows you why it is hard.

Six rows for one word

/search/{query} takes the query in the path and offers limit, type (all, stock, etf, fund, bond, index, crypto), exchange, bonds_only (0 or 1) and fmt (json or xml). Asking for Apple with limit=6 returned:

AAPL       US   Apple Inc.                     Common Stock  USD  US0378331005  primary
AAPLX-USD  CC   Apple tokenized stock (xStock) Currency      USD  null
AAPL       BA   Apple Inc DRC                  Common Stock  ARS  US0378331005
0R2V       LSE  Apple Inc.                     Common Stock  USD  US0378331005
0R2V       IL   Apple Inc.                     Common Stock  USD  US0378331005
APLE       US   Apple Hospitality REIT Inc     Common Stock  USD  US03784Y2000  primary

Four lessons in six rows.

Search returns ranked candidates, not an answer. The last row is a completely different company that happens to be called Apple Hospitality. Ranking weighs ticker match alongside size and recent volume, and no ordering rule can know which company a human meant.

The ticker is not the name. On the London exchange Apple trades as 0R2V, not AAPL. A user who types AAPL with an exchange=LSE filter finds nothing at all, and concludes your product has no UK coverage.

One ISIN, four rows. US0378331005 appears on the US, Buenos Aires, LSE and IL lines. An ISIN identifies the security, not the listing — it cannot tell you which venue, currency or price you want. The Buenos Aires row's previous close of 26,920 is in Argentine pesos; the US row's 336.91 is in dollars. Same ISIN, two numbers that must never be compared — and note that the exchange rate alone will not reconcile them either. The search result names that line Apple Inc DRC: it is a CEDEAR, a receipt representing a fraction of one share, so the two prices differ by a conversion ratio on top of the currency. The Canadian line is a CDR and works the same way. Reach for an FX rate by itself and you land wrong by the ratio, then blame the FX source.

The live response carried a field the published schema does not. Every row came back with isPrimary, true for AAPL.US and APLE.US and false for the rest. It is exactly the flag you want for "the main listing" — and exactly the kind of thing to use as a convenience with a fallback, not as a contract.

And identifiers move over time

Resolution has a second dimension. /symbol-change-history returns renames, with from and to both required as YYYY-MM-DD, an optional ex exchange filter, and fmt of json or csv. Coverage is US exchanges only.

A January 2026 window returned 22 renames, among them MMC → MRSH (Marsh, effective 2026-01-14) and MODG → CALY (Callaway Golf, 2026-01-16). A 2022 window contains the one everybody remembers: FB → META, Meta Platforms Class A, effective 2022-06-09 — and ANTM → ELV on 2022-06-28.

Two details deserve your attention. Derivatives rename alongside their underlying: RELI → EZRA and RELIW → EZRAW both landed on 2026-01-26, so a mapping table that tracks only common stock silently breaks the warrant series. And coverage thins going backwards: a query spanning 2021-01-01 to 2022-06-30 — eighteen months — returned 28 rows, the earliest dated 2021-04-05, while the single month of January 2026 returned 22. Treat the early record as incomplete, not as evidence that nothing happened.

An ISIN is the anchor this domain keeps recommending, and /search/{query} is where you turn one back into listings: query the ISIN itself and the response is every venue trading that security, each with its own exchange code and currency and an isPrimary flag. /search/US0378331005 returned 13 listings on 2026-09-07, AAPL on US marked primary, then Buenos Aires, London, Frankfurt, Mexico and the rest. That is the resolution step a mapping table needs: store the ISIN, resolve it to the listing you want on a schedule, and let the ticker be the answer rather than the key. Two limits: Isin is null on many symbol-list rows, so the resolution must fall back to name plus exchange; and a Buenos Aires or London line of a US company is a different price series, not a duplicate to merge.

The rule that follows

A ticker is a lease, not a name. Store an internal identifier for the instrument, keep the ticker as a time-stamped attribute of it, and reconcile against this endpoint on a schedule. Otherwise a rename splits one company's history into two half-series, and the older half quietly stops updating — the kind of failure that produces no error and no alert, and that the sanity checks in trust-but-verify exist to catch.

Try it now

1. Here is /search/Volkswagen with limit=6. Count how many of the returned rows are the same issuer on different venues, and how many are a different share class of it. Then decide which one your application should default to, and write the rule down. For a company you know, open it in the Terminal and search there.

Open VOW3.XETRA in the EODHD Terminal

2. Here is /symbol-change-history for 26 to 27 January 2026, the two days around the pair named above. Read the company names and say which row is the common stock and which the warrant, and write the two rows your mapping table would need. Pairs like this are the ones that break naive mappings.

3. Take any ticker in your own data and ask whether you could prove it referred to the same company three years ago. If the answer is "probably", you have found your next piece of work.