บทช่วยสอน August 10, 2026

วิธีแก้ Telegram API_ID_PUBLISHED_FLOOD: เช็กลิสต์กู้คืน

API_ID_PUBLISHED_FLOOD หมายความว่า Telegram ระบุว่า api_id ในคำขอยืนยันตัวตนเคยถูกเผยแพร่ หรือไม่เหมาะกับแอปที่เปิดใช้งานจริง ให้หยุดลองซ้ำด้วยข้อมูลชุดนั้น ตรวจว่า build คัดลอก API ID ตัวอย่างแบบจำกัดของ Telegram มาหรือไม่ หรือข้อมูลแอปของคุณถูกเปิดเผยหรือไม่ แล้วเปลี่ยนไปใช้ API ID ที่สร้างสำหรับแอปของคุณเอง Telegram ไม่ได้ระบุ endpoint สำหรับปลดล็อกหรือหมุนเวียนข้อมูลนี้ด้วยตนเอง

สรุปสำคัญ

Telegram ระบุชัดว่า API ID ตัวอย่างใน source code ของ client มีไว้ทดสอบ และจะทำให้เกิด API_ID_PUBLISHED_FLOOD ในแอปที่เผยแพร่จริง
Telegram API Terms กำหนดให้แต่ละแอปใช้ api_id ของตนเอง
API_ID_INVALID, API_ID_PUBLISHED_FLOOD, AUTH_KEY_DUPLICATED และ SESSION_REVOKED เป็นคนละปัญหา
อย่าบันทึก api_hash, รหัสเข้าสู่ระบบ, QR token หรือ session export ลง log ระหว่างตรวจสอบ
BotFather token แทน API ID/API hash ไม่ได้ หากต้องการยืนยันตัวตนบัญชี Telegram ปกติ

วิธีแก้ Telegram API_ID_PUBLISHED_FLOOD

นี่คือปัญหาข้อมูลแอป ไม่ใช่คำสั่งให้รอแล้วลองใหม่ เอกสาร auth.exportLoginToken ของ Telegram ระบุ error 400 ว่า API ID ถูกเผยแพร่ที่ใดที่หนึ่งและใช้งานไม่ได้ คู่มือสร้างแอปยังระบุสาเหตุที่พบบ่อย: client แบบ open source ของ Telegram มี API ID ตัวอย่างที่ถูกจำกัดสำหรับการทดสอบ แต่แอปที่เผยแพร่ต้องใช้ ID ของตนเอง

แยกประเภท error ก่อนแก้ไข:

Error	สิ่งที่ Telegram ระบุ	การดำเนินการที่ถูกต้อง
`API_ID_PUBLISHED_FLOOD`	API ID ถูกเผยแพร่ หรือ sample แบบจำกัดถูกใช้นอกการทดสอบ	หยุด authorization ใหม่ หาแหล่งที่มา และแทนด้วยข้อมูลของแอปคุณ
`API_ID_INVALID`	คู่ `api_id` และ `api_hash` ไม่ถูกต้อง	ตรวจว่าทั้งคู่มาจากแอปเดียวกัน และ config parser ไม่ได้เปลี่ยนค่า
`AUTH_KEY_DUPLICATED`	authorization key เดียวถูกใช้กับ main session แบบขนานที่ขัดแย้งกัน	สร้าง authorization key ใหม่และเข้าสู่ระบบอีกครั้ง การเปลี่ยน API ID อย่างเดียวไม่ใช่วิธีที่เอกสารระบุ
`SESSION_REVOKED`	ผู้ใช้ยกเลิกหรือสิ้นสุด authorization	เริ่ม authorization ใหม่ด้วยข้อมูลแอปที่ถูกต้อง
`FLOOD_WAIT_X`	มีการลองมากเกินไป	รอตามเวลาที่ server ระบุ

บทความ เปรียบเทียบ API ID/API hash กับ bot token ช่วยเลือกข้อมูลให้ถูกประเภท ส่วนบทความนี้ตอบ intent ที่ต่างกัน คือการกู้คืนหลังคำขอ MTProto ล้มเหลวแล้ว

ขั้นตอนที่ 1: หาแหล่งที่มาของ API ID

ติดตามค่าโดยไม่แสดงค่าจริง บันทึกเฉพาะ fingerprint ที่ปลอดภัย ชื่อ deployment และแหล่ง config แล้วตรวจว่า:

build คัดลอก sample ID จาก source code ของ Telegram หรือไม่
คู่ข้อมูลเดียวกันปรากฏใน public repository, package, image, browser bundle, ตัวอย่างเอกสาร, issue หรือ CI log หรือไม่
หลายผลิตภัณฑ์หรือลูกค้าใช้ข้อมูลแอปชุดเดียวที่ไม่ควรถูกแชร์หรือไม่
error เกิดกับ code login, QR login หรือทั้งสองแบบ

ทั้ง code และ QR login ใช้ api_id และ api_hash ของ client application การใช้ QR เปลี่ยนวิธีที่ผู้ใช้อนุมัติ แต่ไม่ได้แทนข้อมูลแอป เมธอด auth.exportLoginToken ต้องใช้ทั้งสอง field และอาจคืน API_ID_PUBLISHED_FLOOD

ขั้นตอนที่ 2: ใช้ข้อมูลแอปที่ถูกต้อง

เข้าสู่ระบบ my.telegram.org เปิด API development tools แล้วสร้างหรือดู API ID และ API hash ที่ผูกกับหมายเลข Telegram ที่ยังใช้งานอยู่ Telegram ระบุในปัจจุบันว่าหนึ่งหมายเลขมี API ID ได้เพียงหนึ่งรายการ

ข้อจำกัดนี้ทำให้ไม่ควรสัญญากระบวนการหมุนเวียนทันทีที่ Telegram ไม่ได้ระบุ หากค่าที่ล้มเหลวเป็นเพียง sample ของ Telegram หรือข้อมูลจาก project อื่น การเปลี่ยนเป็นคู่ของแอปคุณคือแนวทางทางการที่ชัดเจน หาก API ID ของคุณถูกเผยแพร่และถูกปฏิเสธ ให้ลบจุดที่เปิดเผย เก็บหลักฐานที่ไม่มีความลับ และใช้ช่องทาง support อย่างเป็นทางการของ Telegram อย่าคาดเดาว่าการ retry จะล้างสถานะเอง

เก็บ api_hash เฉพาะฝั่ง server โหลดจาก credential store ตอน runtime ไม่ใส่ใน browser bundle และ mask ใน log กับ error tracker ส่วน QR token, รหัสยืนยัน, ข้อมูล 2FA และ session export เป็นความลับคนละชุด

ขั้นตอนที่ 3: ย้ายระบบโดยไม่สร้าง incident เพิ่ม

หยุด login ใหม่ทั้งหมดที่ใช้ ID ซึ่งถูกปฏิเสธ
เปลี่ยน credential reference ใน test environment เดียวก่อน และอย่าวาง secret ใน source code
ทำ code หรือ QR authorization แบบควบคุมหนึ่งครั้ง บันทึกเฉพาะประเภท error ขั้นตอน และ timestamp
เมื่อสำเร็จ ให้ตรวจ identity ของบัญชีที่เชื่อมต่อก่อนเปิด traffic
rollout ทีละส่วนและติดตาม FLOOD_WAIT_X, SESSION_REVOKED และ duplicate-session error
ลบ reference เก่าจาก deployment manifest, ตัวอย่าง, cached CI artifact และ runbook

Session เก่าที่ยังทำงานไม่ได้พิสูจน์ว่า API ID ปกติ เพราะ session กับข้อมูลแอปอยู่คนละชั้น และ session เก่าไม่ได้ทดสอบเส้นทาง login ใหม่

UnifyPort รองรับตรงไหน

ขั้นตอนบัญชี Telegram ปกติของ UnifyPort ใช้ขอบเขตแอปเดียวกัน Code authorization ต้องมี provider_data.api_id, provider_data.api_hash และ provider_data.phone; QR authorization ยังต้องมี API ID และ API hash คู่มือ authorization ของ Telegram ระบุขั้นตอน code, QR, 2FA และ session ที่ใช้งานจริง

หาก Telegram ปฏิเสธข้อมูลแอป UnifyPort ไม่สามารถทำให้ข้อมูลนั้นใช้ได้ สร้าง Telegram API ID แทนคุณ หรือเปลี่ยน BotFather token เป็น session ของบัญชีปกติได้ ให้แก้ข้อมูล Telegram ก่อนแล้วเริ่ม flow ที่เกี่ยวข้องใหม่

หลัง authorization ข้อความ inbound จะถูกส่งเป็น message.received event แบบ normalized ส่วน คู่มือสร้าง Telegram-to-Slack relay แสดง webhook workflow หลังจากนั้น ซึ่งควรแยกจากการกู้ credential

ข้อจำกัดและทางเลือก

ใช้ Bot API อย่างเป็นทางการเมื่อ bot identity แยกต่างหากตรงกับความต้องการ Bot token ออกแบบมาสำหรับรูปแบบนี้และไม่ต้อง login บัญชีผู้ใช้ แต่ไม่สามารถทำงานเป็นบัญชีปกติที่มีอยู่แล้ว

ใช้ MTProto user authorization เฉพาะเมื่อจำเป็นต้องใช้ identity ของบัญชีเดิมจริง ๆ เพราะจะสร้าง session material ที่ละเอียดอ่อน และยังอยู่ภายใต้ Telegram API Terms กับระบบควบคุม abuse อินเทอร์เฟซที่ไม่เป็นทางการไม่สามารถยกเลิกกฎเหล่านี้ รับประกันการคืน API ID ที่ถูกปฏิเสธ หรืออนุญาตการส่งข้อความที่ผู้รับไม่ได้ร้องขอจำนวนมาก

FAQ

Telegram API_ID_PUBLISHED_FLOOD เกิดจากอะไร

Telegram ระบุสองสัญญาณโดยตรง: auth.exportLoginToken คืน error เมื่อ API ID ถูกเผยแพร่ และการใช้ sample API ID แบบจำกัดในแอปที่เปิดจริงจะทำให้ผู้ใช้พบ error นี้

รอแล้ว API_ID_PUBLISHED_FLOOD จะหายหรือไม่

Telegram ไม่ได้อธิบายว่าเป็น FLOOD_WAIT_X ที่มีเวลารอ และไม่ได้ประกาศเวลาปลดล็อกด้วยตนเอง ให้หยุด retry เปลี่ยน sample หรือข้อมูลที่ยืมมาเป็นคู่ของคุณเอง และใช้ official support หาก ID ของคุณถูกเปิดเผย

API_ID_INVALID คือ error เดียวกันหรือไม่

ไม่ใช่ API_ID_INVALID หมายถึงคู่ API ID/API hash ไม่ถูกต้อง ส่วน API_ID_PUBLISHED_FLOOD หมายถึง ID ถูกระบุว่าเผยแพร่แล้วหรือไม่เหมาะกับการใช้งานนี้

BotFather token แทน API ID ที่ถูกปฏิเสธได้หรือไม่

ไม่ได้สำหรับบัญชีปกติ Bot token ยืนยันตัวตน bot กับ Bot API แต่ code และ QR login ของผู้ใช้เดิมยังต้องใช้ API ID และ API hash

ควรเขียน API hash ลง log เพื่อเทียบ environment หรือไม่

ไม่ควร ให้เทียบ fingerprint แบบทางเดียวหรือ secret version ID แทน อย่าใส่ API hash, รหัส login, QR token, 2FA หรือ session export ใน log, ticket, screenshot หรือตัวอย่างสาธารณะ

ขั้นตอนถัดไป

ใช้ คู่มือสร้างแอปอย่างเป็นทางการของ Telegram เพื่อยืนยันว่า integration ใช้ API ID ของตัวเอง หลังแก้แหล่งข้อมูลแล้ว ให้ทำ code หรือ QR authorization แบบควบคุมหนึ่งครั้งตาม คู่มือ UnifyPort Telegram

แหล่งข้อมูล

ตรวจสอบแหล่งข้อมูลและเอกสารผลิตภัณฑ์เมื่อ 2026-08-10