The vocabulary that makes search work: symbols, dates, identifiers, joins

Why this matters. Search only works when you know what the thing is called. A large share of the questions that look like data problems are vocabulary problems wearing a costume. Foundation: Why do old prices look "wrong" on charts?

The symbol is the key to everything

Our universal format is SYMBOL.EXCHANGE: AAPL.US, VOW3.XETRA, HSBA.LSE. The suffix names the venue, and it matters because the same company can trade in several places, in different currencies, on different hours.

For US tickers the suffix defaults, so a bare AAPL still returns data. Which produces a trap worth knowing: an empty response for AAPL is not a suffix problem. Check entitlement, the date range, or a mistyped symbol instead of sending the client to add .US.

Some suffixes name an asset class rather than a venue. Indices use .INDX (GSPC.INDX for the S&P 500), currency pairs .FOREX (EURUSD.FOREX), crypto .CC (BTC-USD.CC), money-market and reference rates .MONEY, European funds .EUFUND, government bonds .GBOND. Five of these appear in /exchanges-list; INDX does not, and /eod/GSPC.INDX answers all the same (1,674 symbols on /exchange-symbol-list/INDX, read 2026-09-07). An instrument absent from the exchange list can therefore be on the shelf, and the check is the symbol list for its suffix or a /search on the name. A client asking for "the S&P 500" or "bitcoin" is asking for one of these suffixes. The public lesson Virtual exchanges lists them with examples.

The symbol is also the join

That one key is what lets a client line up prices, fundamentals, news, dividends and options for the same company. Get it right and the datasets stack. Get it wrong and everything downstream is quietly about a different company, without a single error being raised.

Two places where the key alone is not enough, both documented:

• Currency metadata is not uniformly populated. Some venues carry a missing or wrong currency field. A client building a multi-currency view on the assumption that it is always there gets a silent mess rather than an exception.
• Bulk end-of-day carries no instrument type, deliberately, because adding it would break existing integrations. The documented route is to take the type from search and join it on the symbol.

When the client's key is not our key

Institutional clients rarely key their universe by ticker. Identifier mapping translates between CUSIP, ISIN, FIGI, LEI, CIK and our symbols, and it is often the entire answer to whether an integration is feasible.

And tickers are not stable: companies rename, merge and relist. Symbol change history is what turns a broken historical join back into a working one.

The shape of the data

Bars are OHLCV — open, high, low, close, volume — for end-of-day and intraday alike. Prices come in two conventions: raw closes, which are what the tape printed, and adjusted closes, with splits and dividends folded in.

That second pair resolves the single most common complaint we receive. "Your historical prices do not match somewhere else" is, nine times in ten, two different adjustment conventions rather than a data error.

Try it now

1. Write the full ticker for Apple, for Volkswagen on Xetra, and for Vodafone in London. Then check them with /search/{query} — searching the company name returns the symbols we actually carry, which is faster than guessing a suffix. The searches for Volkswagen and Vodafone are below.

2. See the US default and the trap that comes with it. /eod/AAPL and /eod/AAPL.US return the same data — the two tables below are the same day asked both ways — so an empty response for a bare US ticker is not a suffix problem. Check entitlement, the date range, or a mistyped symbol before sending the client to add .US.

3. A client says their portfolio join lost half its rows after a merger. Name the endpoint that explains it, then call it: /symbol-change-history. That is what turns a broken historical join back into a working one.

4. When the client's key is not our key, /id-mapping?filter[isin]={isin} translates between CUSIP, ISIN, FIGI, LEI, CIK and our symbols. Here it is once on Apple's ISIN, so you know what the answer looks like before a client is waiting on it: one row per listing, and the US identifiers filled only on the primary line.

5. Finally, the shape of the data itself. /eod/AAPL.US across Apple's 2020 split is below: read close against adjusted_close on the same rows. Nine times in ten, "your historical prices do not match somewhere else" is these two conventions rather than a data error — and now you have seen both columns.