เปรียบเทียบ June 13, 2026

X ปรับโครงสร้างราคา API ปี 2026: การคิดค่าใช้จ่ายตามปริมาณการใช้งานหมายความว่าอย่างไรสำหรับการรับ DM และการ @ mention — UnifyPort

ถ้าคุณลงทะเบียน X API เป็นครั้งแรกในปีนี้ คุณจะเจอกำแพงที่ไม่มีอยู่ในปี 2025: ไม่มีแพ็กเกจฟรีอีกแล้ว ในเดือนกุมภาพันธ์ 2026 X เปลี่ยน API สำหรับนักพัฒนาให้เป็นแบบคิดค่าใช้จ่ายตามปริมาณการใช้งาน แทนที่แพ็กเกจราคาคงที่เดิม (ซึ่งอยู่ระหว่าง $0 ถึง $5,000 ต่อเดือนตามระดับ) นักพัฒนาใหม่ต้องเติมเครดิตก่อนจะเรียก API ได้สักครั้ง — ไม่มีตัวเลือก “ลองใช้ฟรีสักสองสามครั้ง” อีกแล้ว

สำหรับทีมที่ต้องการแค่รับข้อความส่วนตัว (DM) และการ @ mention บนบัญชี X — คือฝั่งรับข้อความเข้า ไม่ใช่การโพสต์หรือการวิเคราะห์ข้อมูล — สิ่งนี้เปลี่ยนลักษณะของการตัดสินใจไปโดยสิ้นเชิง เดิมคำถามคือ “แพ็กเกจราคาคงที่แบบไหนครอบคลุมปริมาณการใช้งานของเรา” แต่ตอนนี้กลายเป็น “ข้อความทุกข้อความที่เราได้รับจะมีค่าใช้จ่ายเท่าไหร่ และจะเป็นรายการค่าใช้จ่ายที่เกิดขึ้นซ้ำตลอดไป”

สิ่งที่เปลี่ยนไปจริง ๆ และเปลี่ยนถึงสองครั้ง

การปรับโครงสร้างในเดือนกุมภาพันธ์ 2026 กำหนดพื้นฐานไว้ว่า: คิดค่าใช้จ่ายตามการเรียกแต่ละครั้ง การอ่านและการเขียนคิดราคาแยกกัน ไม่มีเพดานการใช้งาน — เรียกเท่าไหร่จ่ายเท่านั้น จากนั้นในวันที่ 20 เมษายน 2026 X ออกประกาศปรับราคาแบบไม่ทันตั้งตัว การอ่านข้อมูลของบัญชีตัวเอง — โพสต์ ผู้ติดตาม และ DM ของตัวเอง — ลดลงอย่างมากเหลือ $0.001 ต่อรีซอร์ส ลดลง 5 เท่าจากราคาคิดตามการใช้งานเดิม ในขณะเดียวกัน คำขอเขียนแบบมาตรฐานเพิ่มขึ้นจาก $0.010 เป็น $0.015 ต่อคำขอ

สำหรับ pipeline การรับ DM/@ mention นั่นหมายความว่ามีมิเตอร์คิดราคาทำงานพร้อมกันสองตัว:

การอ่าน DM และ @ mention ที่เข้ามา — หลังการปรับเดือนเมษายน ค่าใช้จ่ายค่อนข้างต่ำที่ $0.001 ต่อการอ่านรีซอร์สของตัวเอง
การส่งคำตอบกลับ — เป็นคำขอเขียน ตอนนี้อยู่ที่ $0.015 ต่อการเรียก

ตัวเลข $0.001 ฟังดูเล็กน้อย จนกว่าคุณจะคำนวณตามการทำงานจริงของทีมซัพพอร์ต ทีมเล็ก ๆ ที่จัดการ DM และ @ mention เข้ามาหลายร้อยข้อความต่อวัน แต่ละข้อความที่ต้องตอบจะเสียทั้งค่าอ่านและค่าเขียน — และนี่ยังไม่รวมต้นทุนการ polling เพราะการ “รับ” DM ผ่าน API ของ X โดยพื้นฐานแล้วยังคือการ query เพื่อเช็กว่ามีกิจกรรมใหม่หรือไม่ ไม่ใช่ webhook แบบ push ความถี่ของการ polling จะขยายต้นทุนการอ่านโดยไม่ขึ้นกับจำนวนข้อความจริงที่เข้ามา

ที่ปริมาณการใช้งานต่ำ เรื่องนี้ยังไม่ถึงกับร้ายแรง — อย่างที่บทวิเคราะห์ราคาช่วงต้นปีระบุไว้ว่าการใช้งานเบา ๆ อยู่ที่ไม่กี่ดอลลาร์ต่อเดือน แต่นี่เป็นโครงสร้างต้นทุนที่ต่างจาก “จ่ายค่าคงที่ต่อเดือนแล้วไม่ต้องคิดอะไรอีก” โดยสิ้นเชิง ทุกครั้งที่ปริมาณข้อความจากลูกค้าพุ่งขึ้น — การเปิดตัวสินค้า โพสต์ที่ถูก @ mention จนไวรัล หรือกองข้อความซัพพอร์ตที่ค้างอยู่ — จะสะท้อนตรงไปยังบิล คิดตามข้อความ ตามคำตอบ และตามจำนวนครั้งที่ polling

มองในอีกมุม: การรับข้อความไม่ควรต้อง “เรียก API”

จุดที่มองข้ามได้ง่ายคือ: โครงสร้างต้นทุนข้างต้นเป็นคุณสมบัติของ API หลักของ X ไม่ใช่คุณสมบัติของ “การรับข้อความบน X” เอง ถ้าสิ่งที่คุณต้องการจริง ๆ คือ “เมื่อมีคนส่ง DM หรือ @ mention บัญชีของเรา ระบบหลังบ้านของเราต้องรู้ทันทีและสามารถตอบกลับได้” — ความต้องการนี้ไม่ได้บังคับให้คุณต้องจ่ายเงินให้ X ทุกครั้งที่อ่านและทุกครั้งที่เขียน

นี่คือช่องว่างที่ unofficial inbound interface ของ UnifyPort สำหรับ X เข้ามาเติมเต็ม แทนที่ระบบหลังบ้านของคุณจะต้อง polling API ของ X (และเสียค่าใช้จ่ายทุกครั้งที่อ่าน) UnifyPort เชื่อมต่อกับบัญชี X โดยตรง และส่งกิจกรรมที่เข้ามาไปยัง webhook ของคุณทันทีที่เกิดขึ้น — ไม่มีการนับจำนวนการอ่าน ไม่มี polling loop และไม่มีค่าใช้จ่ายต่อข้อความจากฝั่งแพลตฟอร์ม

สำหรับทีมในไทย X มักไม่ใช่ช่องทางเดียว — LINE ยังคงเป็นช่องทางหลักสำหรับการติดต่อลูกค้าในหลายธุรกิจ การนำ X มารวมไว้ใน webhook ที่ normalize แล้วชุดเดียวกับ LINE หมายความว่าคุณไม่ต้องแยกจัดการโมเดลค่าใช้จ่ายของแต่ละแพลตฟอร์มเอง — ทุกอย่างไหลผ่าน message.received ตัวเดียวกัน

วิธีการเชื่อมต่อในทางปฏิบัติ

การเชื่อมต่อบัญชี X กับ UnifyPort ใช้ flow แบบ session เดียวกับที่อธิบายไว้ใน ส่วนขยาย UnifyPort Exporter: สร้างเรคคอร์ดบัญชีด้วย provider: "twitter" และ auth_mode: "session" ส่งออก session ของบัญชีที่คุณล็อกอินอยู่แล้ว แล้วเริ่ม runtime

POST /v1/accounts
Content-Type: application/json

{
  "provider": "twitter",
  "auth_mode": "session"
}

จากนั้น DM และ @ mention ทุกรายการที่เข้ามาในบัญชีนี้จะถูกส่งไปยัง webhook ของคุณในรูปแบบ event message.received — รูปแบบ normalized เดียวกันกับที่ UnifyPort ใช้สำหรับ WhatsApp, Telegram, LINE, TikTok และ Zalo:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "twitter",
  "from": "user_3f9c1a",
  "text": "Hey, do you ship to the EU?",
  "timestamp": 1749427200,
  "message_id": "x_msg_7c1f9d"
}

การตอบกลับก็ใช้ POST /v1/messages เดียวกัน โดยระบุปลายทางด้วย account_id และ from — เหมือนกับช่องทางอื่นทุกอย่าง ไม่มีขั้นตอน “อ่าน” DM แยกก่อนประมวลผล เพราะ event มีข้อมูลที่ต้องใช้ครบอยู่แล้ว และไม่มีการคิดค่าใช้จ่ายตามปริมาณข้อความหรือความถี่ในการ query เลย

X (Twitter) ──► UnifyPort ──► message.received ──► webhook ของคุณ
                    ▲                                    │
                    │                                    ▼
              POST /v1/messages ◄──────────── โค้ดตอบกลับของคุณ

ทุกการส่งข้อมูลจะถูกลงนามด้วย HMAC-SHA256 โดยใช้ signing_secret ที่คุณตั้งค่าไว้ ดังนั้นการตรวจสอบจึงเป็นโค้ดชุดเดียวกันกับช่องทางอื่น ๆ ที่คุณเชื่อมต่ออยู่

สรุปในทางปฏิบัติ

ถ้าปริมาณการใช้งาน X ของคุณเบามากจริง ๆ — DM ไม่กี่ข้อความต่อสัปดาห์ ไม่มีการทำ automation อื่น — ราคาอ่าน $0.001 หลังการปรับเดือนเมษายนถูกพอที่ API ทางการจะใช้ได้สบาย ๆ การสร้างการเชื่อมต่อแยกอีกชุดอาจไม่คุ้มความพยายาม

แต่ถ้า X เป็นหนึ่งในหลายช่องทางที่ทีมของคุณคอยรับข้อความเข้า โดยเฉพาะเมื่อปริมาณคาดเดาไม่ได้ — โพสต์ไวรัล ซัพพอร์ตพุ่งสูง หรือเปิดตัวสินค้าใหม่ — โมเดลคิดราคาแบบอ่าน+เขียนต่อครั้งจะแปลง “เราได้รับความสนใจมากขึ้น” ให้กลายเป็น “บิลแพงขึ้น” โดยตรง ซึ่งเป็นทิศทางที่ผิดสำหรับแรงจูงใจแบบนี้ การเชื่อมต่อ X ผ่าน unified webhook ของ UnifyPort จะทำให้มันอยู่บนพื้นฐานเดียวกัน เป็น normalized และไม่ถูกคิดค่าใช้จ่ายตามปริมาณ เหมือนกับช่องทางอื่น ๆ ของคุณ — event message.received เดียวกัน endpoint สำหรับตอบกลับเดียวกัน ไม่มีชั้นการคิดค่าใช้จ่ายเพิ่มเติม