Cách sửa lỗi Telegram API_ID_PUBLISHED_FLOOD: checklist khôi phục

API_ID_PUBLISHED_FLOOD có nghĩa là Telegram đã xác định api_id trong yêu cầu xác thực là thông tin từng được công khai hoặc không phù hợp với ứng dụng đã phát hành. Hãy dừng thử lại bằng thông tin đó, kiểm tra bản build có sao chép API ID mẫu bị giới hạn của Telegram hay không, hoặc thông tin ứng dụng của bạn có bị lộ hay không, rồi chuyển sang API ID được tạo cho chính ứng dụng của bạn. Telegram không công bố endpoint tự mở khoá hoặc xoay vòng cho lỗi này.

Điểm chính

• Telegram nói rõ API ID mẫu trong mã nguồn client chỉ dành cho thử nghiệm; dùng trong ứng dụng phát hành sẽ gây API_ID_PUBLISHED_FLOOD.
• Điều khoản Telegram API yêu cầu ứng dụng lấy api_id riêng, không dùng cặp thông tin của dự án khác.
• API_ID_INVALID, API_ID_PUBLISHED_FLOOD, AUTH_KEY_DUPLICATED và SESSION_REVOKED là các lỗi khác nhau.
• Không ghi api_hash, mã đăng nhập, QR token hoặc session đã export trong lúc chẩn đoán.
• BotFather token không thay thế API ID/API hash khi cần xác thực tài khoản Telegram thông thường.

Cách sửa Telegram API_ID_PUBLISHED_FLOOD

Đây là lỗi thông tin định danh ứng dụng, không phải yêu cầu chờ rồi thử tiếp. Trong tài liệu auth.exportLoginToken, Telegram liệt kê phản hồi 400: API ID đã được công khai ở đâu đó nên không thể dùng. Hướng dẫn tạo ứng dụng cũng nêu nguyên nhân phổ biến: client mã nguồn mở của Telegram có API ID mẫu bị giới hạn cho thử nghiệm, nhưng ứng dụng phát hành phải dùng ID riêng.

Hãy phân loại chính xác trước khi thay đổi:

Lỗi quan sát được	Telegram mô tả	Hành động đúng
API_ID_PUBLISHED_FLOOD	API ID đã công khai hoặc ID mẫu bị dùng ngoài thử nghiệm	Dừng xác thực mới, tìm nguồn và thay bằng cặp thông tin của ứng dụng bạn
API_ID_INVALID	Cặp api_id và api_hash không hợp lệ	Kiểm tra hai giá trị thuộc cùng ứng dụng và không bị parser cấu hình thay đổi
AUTH_KEY_DUPLICATED	Một authorization key chạy trên các main session song song xung đột	Tạo authorization key mới và đăng nhập lại; chỉ đổi API ID không phải cách Telegram hướng dẫn
SESSION_REVOKED	Người dùng đã huỷ hoặc chấm dứt uỷ quyền	Bắt đầu lại xác thực với thông tin ứng dụng đúng
FLOOD_WAIT_X	Có quá nhiều lần thử	Tuân thủ thời gian chờ server trả về

Bài phân biệt API ID/API hash và bot token giúp chọn loại thông tin. Bài này phục vụ ý định khác: khôi phục sau khi yêu cầu MTProto đã thất bại.

Bước 1: tìm nguồn của API ID

Theo dõi giá trị mà không in chính giá trị đó. Chỉ lưu fingerprint an toàn, tên deployment và nguồn config. Kiểm tra:

1. bản build có sao chép ID mẫu từ mã nguồn client Telegram hay không;
2. cùng cặp thông tin có xuất hiện trong public repository, package, image, browser bundle, ví dụ tài liệu, issue hoặc CI log hay không;
3. nhiều sản phẩm hoặc khách hàng có đang dùng chung thông tin ứng dụng vốn không dành để chia sẻ hay không;
4. lỗi xảy ra với code login, QR login hay cả hai.

Cả code và QR login đều cần api_id và api_hash của client application. QR chỉ thay đổi cách người dùng phê duyệt, không thay thế thông tin ứng dụng. auth.exportLoginToken yêu cầu cả hai trường và có thể trả về API_ID_PUBLISHED_FLOOD.

Bước 2: lấy đúng thông tin ứng dụng

Đăng nhập my.telegram.org, mở API development tools, rồi tạo hoặc xem API ID và API hash gắn với số Telegram đang hoạt động. Telegram hiện nói mỗi số chỉ có thể có một API ID.

Giới hạn này có nghĩa là không nên hứa một quy trình xoay vòng tức thời mà Telegram chưa tài liệu hoá. Nếu giá trị lỗi chỉ là ID mẫu của Telegram hoặc thông tin của dự án khác, thay bằng cặp của ứng dụng bạn là hướng chính thức rõ ràng. Nếu chính API ID của bạn từng bị công khai và hiện bị từ chối, hãy xoá nơi công khai, giữ bằng chứng không chứa bí mật và dùng kênh hỗ trợ chính thức của Telegram. Đừng đoán rằng thử lại nhiều lần sẽ tự xoá trạng thái.

Chỉ giữ api_hash ở server, nạp từ credential store lúc runtime, không đưa vào browser bundle và luôn che trong log cùng error tracker. QR token, mã xác thực, dữ liệu 2FA và session export là các bí mật riêng biệt.

Bước 3: di chuyển mà không tạo sự cố thứ hai

• Đóng băng mọi lần đăng nhập mới dùng ID bị từ chối.
• Cập nhật credential reference trước ở một test environment; không dán bí mật vào source code.
• Thực hiện đúng một lần code hoặc QR authorization có kiểm soát, chỉ ghi loại lỗi, giai đoạn và timestamp.
• Sau khi thành công, xác minh identity của tài khoản đã kết nối trước khi mở traffic.
• Triển khai dần và theo dõi FLOOD_WAIT_X, SESSION_REVOKED cùng duplicate-session error.
• Xoá reference cũ khỏi deployment manifest, ví dụ, cached CI artifact và runbook hỗ trợ.

Một session cũ còn chạy không chứng minh thông tin ứng dụng đang khoẻ. Session và API ID nằm ở hai lớp xác thực khác nhau; session cũ không kiểm thử đường đăng nhập mới.

UnifyPort phù hợp ở đâu

Luồng tài khoản Telegram thông thường của UnifyPort dùng cùng ranh giới ứng dụng. Code authorization cần provider_data.api_id, provider_data.api_hash và provider_data.phone; QR authorization vẫn cần API ID và API hash. Hướng dẫn xác thực Telegram ghi đúng các bước code, QR, 2FA và session.

Nếu Telegram từ chối thông tin ứng dụng, UnifyPort không thể làm thông tin đó hợp lệ, tạo Telegram API ID thay bạn hoặc biến BotFather token thành session tài khoản thông thường. Hãy xử lý thông tin Telegram trước, rồi khởi động lại luồng phù hợp.

Sau xác thực, tin nhắn đến có thể được chuyển thành event message.received chuẩn hoá. Hướng dẫn dựng Telegram-to-Slack relay trình bày webhook phía sau, nên tách riêng khỏi việc khôi phục thông tin.

Giới hạn và đánh đổi

Dùng Bot API chính thức khi một bot identity riêng đáp ứng yêu cầu. Bot token được thiết kế cho mô hình đó và không cần đăng nhập tài khoản người dùng, nhưng không thể hoạt động như tài khoản thông thường có sẵn.

Chỉ dùng MTProto user authorization khi sản phẩm thật sự cần identity của tài khoản hiện có. Nó tạo session material nhạy cảm và vẫn chịu Điều khoản Telegram API cùng cơ chế kiểm soát lạm dụng. Giao diện không chính thức không loại bỏ các quy tắc này, không bảo đảm khôi phục API ID bị từ chối và không cho phép gửi hàng loạt tin nhắn không được yêu cầu.

FAQ

Nguyên nhân Telegram API_ID_PUBLISHED_FLOOD là gì?

Telegram đưa ra hai tín hiệu trực tiếp: auth.exportLoginToken trả lỗi khi API ID đã được công khai, và hướng dẫn ứng dụng nói dùng API ID mẫu bị giới hạn trong ứng dụng phát hành sẽ gây lỗi cho người dùng.

Chờ một lúc có sửa được API_ID_PUBLISHED_FLOOD không?

Telegram không mô tả đây là FLOOD_WAIT_X có thời gian chờ và không công bố thời hạn tự mở khoá. Hãy dừng retry, thay ID mẫu hoặc mượn bằng cặp riêng; nếu ID của bạn bị lộ, dùng hỗ trợ chính thức.

API_ID_INVALID có phải cùng lỗi không?

Không. API_ID_INVALID nghĩa là cặp API ID/API hash không hợp lệ. API_ID_PUBLISHED_FLOOD nghĩa là ID bị xác định đã công khai hoặc không phù hợp cho mục đích hiện tại.

BotFather token có thay API ID bị từ chối không?

Không cho xác thực tài khoản thông thường. Bot token xác thực bot với Bot API. Code và QR login của người dùng hiện có vẫn cần API ID và API hash.

Có nên ghi API hash vào log để so sánh môi trường không?

Không. Hãy so sánh fingerprint một chiều hoặc secret version ID. Không đưa API hash, mã đăng nhập, QR token, dữ liệu 2FA và session export vào log, ticket, ảnh chụp hay ví dụ công khai.

Bước tiếp theo

Dùng hướng dẫn ứng dụng chính thức của Telegram để xác nhận integration dùng API ID riêng. Sau khi sửa nguồn thông tin, thực hiện một code hoặc QR authorization có kiểm soát theo hướng dẫn UnifyPort Telegram.

Nguồn

• Telegram: Creating your Telegram Application
• Telegram: auth.exportLoginToken errors
• Telegram: Error handling
• Telegram: API Terms of Service
• Telegram: User Authorization

Nguồn và tài liệu sản phẩm được kiểm tra ngày 2026-08-10.