LINE Login 與 Messaging API 用戶 ID 不同？先檢查 Provider
同一個人的 LINE Login 與 Messaging API 用戶 ID 不一致時，先確認兩個 channel 所屬的 LINE provider。LINE 按 provider 分配用戶 ID：同一用戶在同一 provider 下，不同類型的 channel 會取得相同 ID；跨 provider 則不同。不要按顯示名稱合併客戶，也不要以為更換 token 就可以統一 ID。
重點
- 先確認 provider 歸屬，再更改登入或 webhook 設定。
- API 用戶 ID、搜尋好友用的 LINE ID、顯示名稱是不同概念。
- 已建立的 channel 不能轉移到另一個 provider。
- 統一訊息格式不等於統一客戶身份。
為何兩種 API 的用戶 ID 會不同？
LINE 的取得用戶 ID 文件明確指出：身份命名空間由 provider 決定，而非 channel 類型。
| 比較情況 | 官方規則或判斷界線 | 應用程式處理 |
|---|---|---|
| 同一用戶、同一 provider 的 Login 與 Messaging API channel | ID 相同 | 在該 provider 內比較已驗證 ID |
| 同一用戶、不同 provider | ID 不同 | 完成明確的帳戶連結程序前，保持獨立 |
| 顯示名稱相同 | 不能證明是同一人 | 不自動合併 |
| 搜尋用 LINE ID 與 API 用戶 ID | 不同識別碼 | 取得正確 API 值，不使用個人資料中的搜尋 ID |
例如，網站登入 channel 與客服 Messaging API channel 可能由不同團隊建立於不同 provider。這只是設定示例，不是客戶事故。CRM 在這種情況下查詢失敗，並不代表 LINE 意外改變了用戶身份。
還要分清兩個概念：LINE provider 是 LINE Developers Console 中的渠道歸屬分組；UnifyPort 的 provider: line 表示訊息平台。兩者不是同一命名空間。
先查來源，再改設定
- 記錄 ID 來源。 確認各自的 channel，以及來自可信登入流程還是 Messaging API webhook。不要比較手動輸入的名字與 API 識別碼。
- 查看 provider。 在 LINE Developers Console 開啟兩個 channel，記錄歸屬，同時區分測試與正式環境。名稱相似不代表歸屬相同。
- 使用受控測試帳戶。 以指定帳戶登入並傳送訊息，比較伺服器端已驗證資料，不採用無關截圖或未驗證的客戶端資料。
- 檢查儲存及欄位映射。 若 provider 相同但記錄不同，先排查舊連線階段、實際登入者、環境混用及欄位對應錯誤。
- 暫停不確定的合併。 保留兩份來源記錄，不要為了讓查詢成功而直接覆寫其中一個 ID。
若實際問題是多個工具爭用同一官方帳戶的憑證或 webhook，請參考多工具共用 LINE 官方帳戶檢查清單。這與用戶 ID 的範圍是不同問題。
已建立在不同 provider 下，可以怎樣處理？
LINE 的登入設定指南說明，channel 建立後不能移到其他 provider；需要連結的 Login 與 Messaging API channel 應從一開始就建立在同一 provider。
對已上線系統，不要把刪除再建立當成沒有影響的修復。先盤點登入依賴、憑證、回調及已有身份參照，再制定替換方案。新建 channel 不代表舊 CRM 映射會自動保留。
建議將外部身份與內部客戶檔案分開：保存來源系統、LINE provider、channel 來源及用戶 ID，另外維護已驗證的客戶關聯。這是本地資料設計建議，不是 LINE webhook 新增欄位。
如需跨 provider 連結，應採用明確程序，驗證相關帳戶的控制權並取得用戶同意，保留關聯依據且支援解除連結。名稱或頭像相同都不足以證明身份。同一 provider 內 ID 相同，也不代表權限或同意可跨流程轉移。
分開保存 UnifyPort 身份與回覆目的地
UnifyPort 的非官方介面提供獨立的已連接帳戶訊息通道。標準事件文件包含 provider、account_id、data.sender.id 及 data.conversation.id：sender 是發送者，conversation 是對話。群組訊息尤其不能混用。
| 本地記錄 | 建議範圍 |
|---|---|
| 官方 LINE 身份 | 應用租戶、LINE provider、已驗證用戶 ID |
| UnifyPort 發送者 | 工作區、provider、account_id、data.sender.id |
| UnifyPort 對話 | 工作區、provider、account_id、data.conversation.id |
| 內部客戶關聯 | 指向指定來源身份的明確驗證關係 |
這是保守的應用設計，不代表 UnifyPort 能轉換官方 LINE 用戶 ID。公開契約沒有記載這種轉換。不要移除前綴、更改大小寫，或因字串看起來相似就視為等價。
聯絡人清單文件分別回傳 id、conversation_id、provider_user_id，並指示以 conversation_id 定位對話或發送訊息。保存回傳的映射，不要用聯絡人 ID 直接替代。WhatsApp 聯絡人名稱同步也涉及這個界線，但不能把其中的 contact.updated 行為套用至 LINE。
更改身份關聯前，按webhook 投遞契約驗證並持久化事件。有效簽章只能驗證收到的內容，不能證明兩個外部帳戶屬於同一人。
驗收與限制
啟用 CRM 自動關聯前，測試同一用戶同 provider、同一用戶跨 provider、兩個同名用戶，以及不同 UnifyPort 訊息帳戶。失敗或模糊配對應保持獨立，不能靜默合併聊天記錄。
同時測試群組訊息：不要把發送者誤當成原本要回覆的對話。訊息路由應獨立於後續客戶檔案合併。
若需求是 LINE Login 與官方帳戶身份連結，請使用官方 channel。UnifyPort 不會移動 channel、授予官方權限，或自動建立跨 provider 身份等價關係。
常見問題
LINE Login 與 Messaging API 應回傳相同用戶 ID 嗎？
同一 LINE 用戶且同一 provider 時，是。不同 provider 會分配不同 ID。
能透過轉移 channel 修復嗎？
不能。LINE 明確說明現有 channel 不能移到另一個 provider，建立前應先規劃歸屬。
顯示名稱或 UnifyPort sender ID 能自動解決不一致嗎？
不能。顯示名稱不是身份主鍵，公開文件亦沒有定義官方 LINE 用戶 ID 到 UnifyPort sender ID 的轉換。
下一步與參考資料
先記錄兩個官方 channel 的 provider 歸屬。若另建已連接帳戶收件匣，先閱讀 UnifyPort 事件結構，設計有範圍的身份儲存，再匯入聯絡人。
官方資料核對日期：2026-10-05。
令訊息接入變成一條穩定嘅產品管線。
先用統一嘅 API 跑通發送，再用標準事件將所有入站訊息接返去業務系統。