CIK, ISIN, LEI — what each identifier means and how to resolve them with a free API
Ask a vendor whether their cross-market feed keys off ticker or registry ID. The answer predicts most data bugs before you integrate.
Tickers are UI labels — they rename, they collide across exchanges, they disappear on delist. The stable keys are CIK (SEC registrant), LEI (legal entity, global), and ISIN (security). A European annual report embeds LEI in XBRL metadata. A GlobeNewswire wire lists ISIN before any ticker. A Form 4 insider filing keys off CIK. Three transports, three ID types — one company, if your catalogue links them.
OpenFilings maintains an entity catalogue across 20 markets and exposes
resolution as GET /api/v1/entities/search (REST) and MCP search_ticker
— authenticated, but no quota. Entity lookup does not consume API credits.
Why identifiers beat tickers
| Identifier | Scope | Stable? | Typical source |
|---|---|---|---|
| Ticker | One exchange listing | ❌ delist, rename, ADR vs home | Bloomberg, Yahoo, EDGAR symbol |
| CIK | US SEC filer | ✅ for US registrants | EDGAR submissions API |
| LEI | Legal entity (global) | ✅ GLEIF registry | ESEF filings, LEI issuers, wires |
| ISIN | One security | ✅ until redemption | Holdings, GNW Atom, fund data |
If you are comparing vendors: ask whether their global filings feed keys off ticker only, or whether CIK, ISIN, and LEI resolve to one issuer row. That single question predicts most cross-market data bugs before you integrate.
CIK — the US SEC key
CIK (Central Index Key) is the SEC's permanent numeric identifier for a registrant. EDGAR stores it zero-padded to 10 digits (0000320193 for Apple).
- One CIK per SEC registrant — subsidiaries may file separately
- Form 4, 10-K, 8-K, and proxy statements all reference CIK
- Not global: Toyota's CIK is its 20-F depositary filing, not its TSE listing
OpenFilings stores sec_cik on the entity row and resolves US symbols through EDGAR plus the entity catalogue — not a one-off ticker→CIK map that goes stale after a rename.
LEI — the global entity anchor
LEI (Legal Entity Identifier) is a 20-character alphanumeric code issued under the GLEIF framework. It identifies a legal entity, not a specific share class.
Why it matters for EU research:
- ESMA ESEF — since 2020, EU-listed issuers file annual reports in the European Single Electronic Format. The LEI is embedded in filing metadata and is the best stable key for cross-exchange European names (tickers differ between Euronext Amsterdam, Paris, and OTC US ADRs).
- Dual-listed groups — Samsung (KR listing + ESEF-GB depositary), Airbus, LVMH: one LEI, multiple listings.
- Wire feeds — press releases and MAR disclosures increasingly carry LEI or ISIN rather than a clean NASDAQ symbol.
OpenFilings uses LEI-first entity merge when known: canonical_key = lei:{LEI20} beats per-registry keys for dual-listed issuers.
ISIN — the security barcode
ISIN is a 12-character code (US0378331005 for Apple common stock). Structure: 2-letter country prefix + 9 alphanumeric + check digit.
- Standard for portfolio holdings, fund factsheets, and GlobeNewswire Atom entries
- One ISIN per security — common vs preferred vs ADR are different ISINs
- Maps to an issuer, but not uniquely: one company, many ISINs
Pass ISIN to entity search when a wire or custodian file gives you ISIN but no ticker.
OpenFilings canonical_key
Behind the API, each issuer has one canonical_key in the entities table:
| Pattern | Market / registry | Example |
|---|---|---|
lei:{LEI20} | Cross-registry anchor | lei:7245001I22ND646ZUW12 (ASML) |
sec:{CIK10} | US SEC-only | sec:0000320193 |
dart:{corp_code} | Korea OpenDART | dart:00126380 |
edinet:{code} | Japan EDINET | edinet:E02144 |
cninfo:{org_id} | China / HK CNINFO | cninfo:9900020469 |
ch:{company_number} | UK Companies House | ch:00445790 |
Resolution responses include canonical_key and entity.listings[] — each listing has market_id, ticker, registry, and optional lei. Read listings before calling filing APIs; do not assume market_id=us from a bare symbol (VU is Euronext, not US).
Free entity search API
Endpoint: GET https://api.openfilings.org/api/v1/entities/search
Auth: X-API-Key: of_… (create a key)
Quota: none — entity search does not consume REST or MCP credits.
| Parameter | Use for |
|---|---|
query | Company name (VusionGroup, Toyota, 汉朔科技) |
ticker | Exchange symbol (AAPL, VU, 7203) |
cn_ticker / hk_ticker | A-share 6-digit or HKEX code |
lei | 20-character LEI |
isin | 12-character ISIN |
ISIN is the least obvious — useful when a wire or custodian file gives you a security code but no ticker:
curl -s -H "X-API-Key: of_your_key" \
"https://api.openfilings.org/api/v1/entities/search?isin=US0378331005"
Name search works cross-market, including CJK characters:
curl -s -H "X-API-Key: of_your_key" \
"https://api.openfilings.org/api/v1/entities/search?query=Samsung+Electronics"
Response shape: entity.canonical_key, entity.lei, entity.listings[]
— each listing has market_id, ticker, registry. Inspect listings[]
before calling filing APIs; do not assume market_id=us from a bare symbol
(VU is Euronext).
Full curl examples for LEI, CIK, and ticker in the REST API docs.
MCP search_ticker
Same semantics in MCP — tool search_ticker on https://api.openfilings.org/mcp:
search_ticker(lei="7245001I22ND646ZUW12")
search_ticker(isin="US0378331005")
search_ticker(ticker="005930")
search_ticker(query="Airbus")
Agent workflow: list_markets → search_ticker → read entity.listings → list_filings with the right market_id and ticker. See the MCP setup guide.
Dual-listed and cross-registry
Real issuers span registries:
- Samsung — KR DART (
005930) + optional ESEF-GB annual report under the same LEI - Airbus — Euronext (
AIR) + US 20-F via SEC CIK on the depositary - Tencent — HK (
0700) + CN listings with different tickers
OpenFilings merges on LEI when present so watchlist matching, press release fan-out, and notification inbox hit the right subscribers whether they follow the home listing or the ADR.