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 跑通傳送，再用標準事件把所有入站訊息接回業務系統。