Telegram API_ID_PUBLISHED_FLOOD 點樣修復：復原檢查表
API_ID_PUBLISHED_FLOOD 代表 Telegram 已將授權請求所用的 api_id 判定為公開憑證，或認為它不適合已發布的應用程式。應立即停止用該憑證重試，確認 build 有否複製 Telegram 的受限範例 API ID，或自家應用程式憑證有否公開，再遷移至為自己應用程式申請的 API ID。Telegram 沒有為這個錯誤公開自助解鎖或輪替 endpoint。
重點速覽
- Telegram 清楚指出，開源 client 內的範例 API ID 只供測試；用於正式應用程式會觸發
API_ID_PUBLISHED_FLOOD。 - Telegram API 條款要求應用程式取得自己的
api_id，複製其他 project 的憑證並非 production 做法。 API_ID_INVALID、API_ID_PUBLISHED_FLOOD、AUTH_KEY_DUPLICATED及SESSION_REVOKED是不同故障。- 排查時不要記錄
api_hash、登入驗證碼、QR token 或匯出的 session。 - 如要連接一般 Telegram 帳戶，BotFather token 不能取代 API ID/API hash。
Telegram API_ID_PUBLISHED_FLOOD 修復方法
這是應用程式憑證問題，不是「等一等再試」的提示。Telegram 在 auth.exportLoginToken 文件將它列為 400：API ID 曾經公開，因此目前不能使用。官方應用程式指南亦指出常見原因：Telegram 開源 client 附帶受限測試 API ID，但正式發布的應用程式必須使用自己的 ID。
先按錯誤類型處理：
| 錯誤 | Telegram 定義 | 正確下一步 |
|---|---|---|
API_ID_PUBLISHED_FLOOD | API ID 已公開，或受限範例 ID 被用於測試以外 | 暫停新授權；找出來源，以自家應用程式憑證取代範例或共享憑證 |
API_ID_INVALID | api_id 與 api_hash 組合無效 | 確認兩者屬於同一應用程式，並檢查 config parsing 有否改動值 |
AUTH_KEY_DUPLICATED | 同一 authorization key 被衝突的平行 main session 使用 | 建立新的 authorization key 並重新登入；單純更換 API ID 並非官方處理方法 |
SESSION_REVOKED | 用戶已終止或撤銷授權 | 用正確應用程式憑證重新授權 |
FLOOD_WAIT_X | 嘗試次數太多 | 遵守 server 提供的等待時間，停止密集重試 |
本文不重複現有的 API ID/API hash 與 bot token 比較；該文協助選擇憑證，本文處理 MTProto 授權已失敗後的復原。
第一步：找出 API ID 來源
追蹤設定，但不要輸出原值。只保存安全 fingerprint、deployment 名稱及設定來源，並檢查：
- build 有否複製 Telegram 開源程式碼內的範例 ID；
- 同一組憑證有否出現在公開 repository、package、image、browser bundle、文件範例、issue 或 CI log；
- 多個產品或客戶有否共用原本不應共享的應用程式憑證；
- 錯誤發生於 code login、QR login，還是兩者都有。
Code 與 QR login 都使用 client application 的 api_id 及 api_hash。QR 只改變用戶批准登入的方式，不會取代應用程式憑證。Telegram 的 auth.exportLoginToken 同時需要兩個欄位，亦明確可能回傳 API_ID_PUBLISHED_FLOOD。
第二步：取得正確應用程式憑證
登入 my.telegram.org，打開 API development tools，建立或查看與有效 Telegram 手機號碼關聯的 API ID 及 API hash。Telegram 目前指出每個號碼只可以有一個 API ID。
這項限制表示不能承諾官方未提供的即時輪替流程。如失敗值只是 Telegram 範例或其他 project 的憑證，改用自家應用程式憑證就是清晰的官方路徑。如自己的 API ID 曾公開並被拒絕，應先移除公開內容、保留不含秘密的證據，再透過 Telegram 官方支援處理，不要假設重試會解除狀態。
api_hash 只應留在 server，由 credential store 在 runtime 注入，不得進入 browser bundle，並在 log 及 error tracker 遮蔽。QR token、驗證碼、2FA 資料及 session 匯出是不同、同樣敏感的秘密。
第三步：安全遷移及重新驗證
- 凍結所有繼續使用被拒絕 ID 的新登入。
- 只在一個 test environment 更新 credential reference，不要把秘密貼入 source code。
- 發起一次受控 code 或 QR 授權，只記錄錯誤類型、request stage 及 timestamp。
- 成功後先驗證實際連接的帳戶，再逐步開放流量。
- 監察
FLOOD_WAIT_X、SESSION_REVOKED及意外的 duplicate-session 錯誤。 - 從 deployment manifest、範例、cached CI artifact 及支援手冊移除舊 credential reference。
不要用仍可運作的舊 session 證明應用程式憑證健康。Session 與 API ID 位於不同授權層，舊 session 無法驗證新的登入路徑。
UnifyPort 如何承接
UnifyPort 的一般 Telegram 帳戶流程使用同一應用程式邊界。Code 授權需要 provider_data.api_id、provider_data.api_hash 及 provider_data.phone；QR 授權仍需要 API ID 及 API hash。Telegram 授權指南列出 code、QR、2FA 及 session 的真實步驟。
如果 Telegram 拒絕應用程式憑證，UnifyPort 無法令它變有效、代為建立 Telegram API ID，或把 BotFather token 轉成一般帳戶 session。請先解決 Telegram 憑證，再重新啟動相應流程。
授權完成後，入站訊息可以標準化 message.received event 送達。Telegram 到 Slack relay 建置指南展示後續 webhook workflow，但應與憑證復原分開。
限制與取捨
如獨立 bot 身份符合需求，應使用官方 Bot API。Bot token 專為此模式設計，亦毋須一般帳戶登入，但不能代表已有一般帳戶。
只有產品確實需要一般帳戶身份時，才使用 MTProto 用戶授權。它會產生敏感 session，並繼續受 Telegram API 條款及自動濫用控制約束。非官方介面不能移除這些規則、保證恢復被拒絕的 API ID，或授權大量發送未經請求的訊息。
FAQ
Telegram API_ID_PUBLISHED_FLOOD 為何出現？
Telegram 文件提供兩個直接線索：auth.exportLoginToken 在 API ID 曾公開時回傳此錯誤；應用程式指南則說，正式應用程式使用開源 client 的受限範例 API ID 會觸發它。
等待可以修復 API_ID_PUBLISHED_FLOOD 嗎？
Telegram 沒有把它描述為有等待秒數的 FLOOD_WAIT_X，亦沒有公開自助解鎖時間。應停止重試，以自家憑證取代範例或借用憑證；如自己的 ID 已公開，請使用官方支援。
API_ID_INVALID 是同一錯誤嗎？
不是。API_ID_INVALID 代表 API ID/API hash 組合無效；API_ID_PUBLISHED_FLOOD 代表 ID 被識別為公開或不適合目前用途。變更 session 或憑證前先確認錯誤類型。
BotFather token 可取代被拒絕的 API ID 嗎？
不能用於一般帳戶授權。Bot token 只驗證 Bot API 的 bot；現有用戶帳戶的 code 與 QR login 仍需 API ID 及 API hash。
可以把 API hash 寫入 log 比對環境嗎？
不可以。請比較單向 fingerprint 或 secret version ID。API hash、驗證碼、QR token、2FA 資料及 session 匯出都不應進入 log、ticket、截圖或公開範例。
下一步
先按 Telegram 的官方應用程式設定指南確認整合使用自己的 API ID。修正憑證來源後，再按 UnifyPort Telegram 授權指南完成一次受控 code 或 QR 授權。
來源
- Telegram：建立 Telegram 應用程式
- Telegram：auth.exportLoginToken 錯誤
- Telegram：錯誤處理
- Telegram：API 服務條款
- Telegram：用戶授權
來源及產品文件核驗日期：2026-08-10。