LEI 法人實體查詢 API
透過 GLEIF 註冊庫以 LEI 代碼或名稱解析法人實體，回傳法定名稱、地址、司法管轄區、本國商業登記號、BIC 代碼與母子公司關係。
整合指南
複製程式碼片段，替換你的 API 金鑰，執行即可。適用於任何 HTTP 用戶端——下方提供 cURL、JavaScript 與 Python 範例。
/api/lei-lookuphttps://www.apipick.comResolve a legal entity through the GLEIF LEI register
leistring選填20-character LEI code. Mutually exclusive with name. HWUPKR0MPOU8FGXBT394
namestring選填Legal entity name to search for. Mutually exclusive with lei. Tesla, Inc.
countrystring選填ISO 3166-1 alpha-2 code narrowing a name search. US
include_relationshipsboolean選填With lei, also return direct parent, ultimate parent, and subsidiary count. true
curl -X GET "https://www.apipick.com/api/lei-lookup" \
-H "x-api-key: YOUR_API_KEY"{
"mode": "lei",
"query": "HWUPKR0MPOU8FGXBT394",
"found": true,
"record": {
"lei": "HWUPKR0MPOU8FGXBT394",
"legal_name": "Apple Inc.",
"other_names": [
"Apple Computer, Inc."
],
"legal_address": {
"lines": [
"C/O C T Corporation System",
"330 N. Brand Blvd"
],
"city": "Glendale",
"region": "US-CA",
"country": "US",
"postal_code": "91203"
},
"jurisdiction": "US-CA",
"legal_form": "H1UM",
"entity_status": "ACTIVE",
"registered_as": "806592",
"bic": [
"APLEUS66XXX"
],
"registration_status": "ISSUED",
"next_renewal_date": "2027-03-08T17:27:20Z"
},
"relationships": {
"direct_parent": null,
"ultimate_parent": null,
"direct_children_count": 8
},
"source": "GLEIF",
"credits_used": 3,
"remaining_credits": 97
}為實際使用情境打造
實體解析
把 CRM 裡雜亂的公司名稱統一成單一標準識別碼，跨系統、跨管轄區都能乾淨地勾稽。
交易對象 KYC
對照官方資料源核實交易對象的登記法定名稱、司法管轄區與本國商業登記號。
股權關係梳理
在授信或簽約前，順著母公司與子公司鏈路查清究竟由誰最終控制該實體。
研究型代理
為研究型代理提供可引用的身分資料源，讓其輸出中的實體資訊能回溯到註冊庫，而不是靠猜。
回應欄位
| 欄位 | 類型 | 說明 |
|---|---|---|
| mode | string | 本次執行的查詢方式：lei 或 search |
| record.lei | string | 20 碼的 ISO 17442 識別碼 |
| record.legal_name | string | null | 官方登記的法定名稱 |
| record.other_names | string[] | 記錄在案的曾用名與別名 |
| record.legal_address | object | null | 註冊地址，拆分為地址行、城市、地區、國家與郵遞區號 |
| record.jurisdiction | string | null | 設立所在的司法管轄區，例如 US-CA |
| record.registered_as | string | null | 本國商業登記號 —— 通往當地公開申報的橋樑 |
| record.entity_status | string | null | ACTIVE 或 INACTIVE |
| record.bic | string[] | 該實體已對應的 SWIFT/BIC 代碼（若有） |
| record.registration_status | string | null | LEI 生命週期狀態，例如 ISSUED 或 LAPSED |
| relationships | object | 帶 include_relationships 時回傳：直接母公司、最終母公司與子公司數量 |
| total_matches | integer | 僅依名稱搜尋時回傳：命中該名稱的紀錄總數 |
| credits_used | integer | 本次請求扣除的點數 |
| remaining_credits | integer | 您帳戶中剩餘的點數 |
速率限制
限流以 API 金鑰計，採用 60 秒滑動視窗。觸發限制時會回傳乾淨的 429，並帶 Retry-After 回應標頭。
30req/min
以 API 金鑰、以端點計。60 秒滑動視窗。
3concurrent
每個 API 金鑰同時進行中的最大請求數。
X-RateLimit-Limit每分鐘允許的最大請求數X-RateLimit-Remaining目前視窗內剩餘的請求數X-RateLimit-Reset目前視窗重設前的秒數Retry-After重試前需等待的秒數（僅在 429 時）HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-RateLimit-Limit: 30
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 12
{
"error": "rate_limit_exceeded",
"message": "Rate limit exceeded: 30 requests/minute per API key. Retry after 12s.",
"retry_after": 12
}資料來源與授權
紀錄來自全球法人識別碼基金會 GLEIF，該機構受監理監督委員會委託維護 LEI 註冊庫。GLEIF 以 CC0 授權發布第一層參考資料與第二層股權資料 —— 屬公眾領域，無須署名，對下游使用亦無任何限制。
常見問題
問: 什麼是 LEI？為什麼適合當主鍵？
答: 法人識別碼是一組 20 碼的 ISO 17442 代碼，在全球範圍內唯一標識一個法人實體 —— 凡在受監理金融市場交易者皆須持有。它不像公司名稱那樣有歧義，也不像本國登記號那樣會跨管轄區重號，因此是實體解析中最合適的勾稽主鍵。
問: 不知道 LEI 也能查嗎？
答: 可以。以 name 取代 lei 即可依法定名稱搜尋註冊庫，還能用 country 進一步收斂。GLEIF 的名稱篩選是相關性比對而非精確比對，因此 total_matches 可能很大 —— 回傳的紀錄是該清單中排序靠前的部分。
問: 如何取得集團股權結構？
答: 在依 LEI 查詢時加上 include_relationships=true。你會取得直接母公司、最終母公司以及直接子公司數量，且每個母公司都以自己的 LEI 標識，方便你再發出呼叫沿樹狀結構向上或向下追查。
問: 資料有多新？
答: GLEIF 每日發布一份新的註冊庫黃金副本，而本介面查詢的是他們的線上 API，而非本地快照。實體必須每年續期 LEI，因此 registration_status 與 next_renewal_date 能告訴你某筆紀錄是仍在積極維護，還是已經失效。
問: 資料可以自由再散布嗎？
答: GLEIF 以 CC0 授權把 LEI 參考資料置於公眾領域，對下游使用沒有任何授權限制。這在實體資料領域相當罕見，也正是這個介面存在的理由 —— 同樣的查詢若來自商業資料商，通常都會附帶再散布條款。