Telegram API_ID_PUBLISHED_FLOOD 怎麼修復：復原檢查表
API_ID_PUBLISHED_FLOOD 表示 Telegram 已把授權請求使用的 api_id 判定為公開憑證，或認為它不適合已發布的應用程式。請停止用該憑證重試，確認建置是否複製 Telegram 的受限範例 API ID，或自有應用程式憑證是否已公開，然後遷移到為自己應用程式申請的 API ID。Telegram 沒有為此錯誤公開自助解鎖或輪替 endpoint。
重點整理
- Telegram 明確指出，開源客戶端內的範例 API ID 只供測試；用於正式發布的應用程式會觸發
API_ID_PUBLISHED_FLOOD。 - Telegram API 條款要求每個應用程式取得自己的
api_id，複製其他專案的憑證並不是正式環境做法。 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 開源客戶端附帶受限的測試 API ID，但正式應用程式必須使用自己的 ID。
先依錯誤類型分流：
| 錯誤 | Telegram 的定義 | 正確處理 |
|---|---|---|
API_ID_PUBLISHED_FLOOD | API ID 已公開，或受限範例 ID 被用於測試以外 | 暫停新授權；找出來源，以自有應用程式憑證取代範例或共享憑證 |
API_ID_INVALID | api_id 與 api_hash 組合無效 | 確認兩者屬於同一應用程式，並檢查設定解析是否改動值 |
AUTH_KEY_DUPLICATED | 同一 authorization key 被衝突的平行主 session 使用 | 建立新的 authorization key 並重新登入；只換 API ID 並非官方處理方式 |
SESSION_REVOKED | 使用者已終止或撤銷授權 | 使用正確應用程式憑證重新授權 |
FLOOD_WAIT_X | 嘗試次數過多 | 遵守伺服器提供的等待時間，停止密集重試 |
本文不重複既有的 API ID/API hash 與 bot token 比較；該文解答如何選憑證，本文處理 MTProto 授權已經失敗後的復原。
第一步：找出 API ID 來源
追蹤設定，但不要輸出原值。只保存安全指紋、部署名稱與設定來源，並檢查：
- 建置是否複製 Telegram 開源程式碼中的範例 ID；
- 同一組憑證是否出現在公開 repository、套件、image、瀏覽器 bundle、文件範例、issue 或 CI log；
- 多個產品或客戶是否共用原本不應共享的應用程式憑證；
- 錯誤發生於 code login、QR login，還是兩者皆會發生。
Code 與 QR login 都使用客戶端應用程式的 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 範例或其他專案的憑證，改用自有應用程式憑證就是明確的官方路徑。若自己的 API ID 曾公開且現在被拒絕，請先移除公開內容、保留不含秘密的證據，再透過 Telegram 官方支援處理，不要假設重試會解除狀態。
api_hash 應只留在伺服器端，由憑證儲存服務在執行時注入，不得進入瀏覽器 bundle，並在 log 與錯誤追蹤中遮蔽。QR token、驗證碼、2FA 資料與 session 匯出是不同、同樣敏感的秘密。
第三步：安全遷移與重新驗證
- 凍結所有繼續使用被拒絕 ID 的新登入。
- 只在一個測試環境更新憑證 reference，不要把秘密貼進原始碼。
- 發起一次受控的 code 或 QR 授權，只記錄錯誤類型、請求階段與時間戳記。
- 成功後先驗證實際連接的帳號，再逐步開放流量。
- 觀察
FLOOD_WAIT_X、SESSION_REVOKED與意外的重複 session 錯誤。 - 從部署 manifest、範例、快取 CI artifact 與支援手冊移除舊憑證 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 工作流，但應與憑證復原分開。
限制與取捨
若獨立 bot 身分符合需求，請使用官方 Bot API。Bot token 專為此模型設計，也不需一般帳號登入，但不能代表既有一般帳號。
只有產品確實需要一般帳號身分時才使用 MTProto 使用者授權。它會產生敏感 session，並繼續受 Telegram API 條款與自動濫用控制約束。非官方介面不能移除這些規則、保證恢復被拒絕的 API ID，或授權大量發送未經請求的訊息。
FAQ
Telegram API_ID_PUBLISHED_FLOOD 為什麼會出現？
Telegram 文件提供兩個直接線索：auth.exportLoginToken 在 API ID 曾公開時回傳此錯誤；應用程式指南則說，正式應用程式使用開源客戶端的受限範例 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 來比對環境嗎？
不可以。請比較單向指紋或 secret 版本識別碼。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。