TikTok Data Portability ไม่ใช่ DM แบบเรียลไทม์: สร้างคิวขาเข้าสำหรับทีมซัพพอร์ต

พื้นผิวสำหรับนักพัฒนาของ TikTok ชัดเจนขึ้นเรื่อย ๆ แต่เอกสารที่ชัดขึ้นไม่ได้แปลว่ามันตอบโจทย์งานซัพพอร์ตที่ทีมต้องทำตอนนี้เสมอไป

วันที่ 4 มิถุนายน TikTok ระบุใน Data Portability API changelog ว่าเอกสาร Data Types ถูกอัปเดตให้ตรงกับหมวดหมู่และฟิลด์ที่รองรับในปัจจุบัน หน้า Data Portability API อธิบายว่า API นี้ให้ผู้ใช้ TikTok ในเขตเศรษฐกิจยุโรปและสหราชอาณาจักรอนุญาตให้ถ่ายโอนข้อมูลของตัวเองไปยังแอปอื่นได้ ส่วน หน้า data types ปัจจุบันระบุ Direct Messages เป็นหมวดข้อมูลที่ export ได้ พร้อมฟิลด์ เช่น วันที่ ผู้ส่ง และเนื้อหา

สิ่งนี้มีประโยชน์กับ data portability, archive, backup และ compliance workflow แต่ไม่ใช่ inbox สำหรับงานซัพพอร์ตแบบเรียลไทม์

ถ้าทีมของคุณขายผ่าน TikTok Shop ทำแคมเปญ creator หรือรับคำถามระหว่างไลฟ์ สิ่งที่ต้องการคืออีกแบบหนึ่ง: ข้อความใหม่ทุกข้อความควรเข้าคิวภายในไม่กี่วินาที ถูก deduplicate เรียกดู CRM แล้วถูกส่งต่อให้ทีมงานหรือ AI assistant การ export ประวัติที่ผู้ใช้อนุญาตไม่สามารถสร้าง event loop แบบนี้ได้ แต่ inbound webhook ที่มีลายเซ็นทำได้

เริ่มจากนิยามงานที่ integration ต้องทำ

ก่อนเลือก API ให้เขียน workflow เป็นภาษาธรรมดา:

1. ลูกค้าส่ง direct message บน TikTok
2. backend ได้รับข้อความภายในไม่กี่วินาที
3. delivery มีลายเซ็น เพื่อให้ server ตรวจสอบแหล่งที่มาได้
4. ข้อความถูกบันทึก เพราะ event ที่พลาดไปจะ backfill ภายหลังไม่ได้
5. คิวเดียวกันในอนาคตรับ WhatsApp, LINE, Zalo, Telegram หรือ X ได้

TikTok Data Portability API ไม่ได้ออกแบบมารอบลำดับนี้ มันเป็นผลิตภัณฑ์ถ่ายโอนข้อมูลโดยอาศัยความยินยอมของผู้ใช้ ผู้สมัครต้องให้บริการผู้ใช้ใน EEA หรือ UK ผ่านการตรวจ privacy และ security และขอ data scope ที่ชัดเจน โมเดลข้อมูลเน้น export: posts and profile, activity, direct messages หรือ full archive

นี่ไม่ใช่ timing model ของซัพพอร์ต ทีมซัพพอร์ตไม่ได้ถามว่า “ผู้ใช้ export archive ของเมื่อวานได้ไหม” แต่ถามว่า “ข้อความที่เพิ่งเข้ามาเมื่อสิบวินาทีก่อน เราจัดการได้ทันทีไหม”

รูปแบบ webhook ของ UnifyPort

TikTok unofficial interface ของ UnifyPort เหมาะกับโมเดลที่สอง คุณเชื่อมต่อบัญชี TikTok ลงทะเบียน webhook endpoint และ subscribe message.received เมื่อลูกค้าส่งข้อความ UnifyPort จะส่ง envelope มาตรฐานมาที่ backend:

{
  "id": "evt_7a4d2c91b6",
  "type": "message.received",
  "provider": "tiktok",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-05T03:18:42Z",
  "data": {
    "conversation": { "id": "tt_conv_9172", "type": "user", "title": "Mai Nguyen" },
    "sender": { "id": "tt_user_4839", "name": "Mai Nguyen", "type": "user" },
    "message": {
      "id": "tt_msg_20260705_001",
      "type": "text",
      "text": "กระเป๋า tote สีดำยังมีของก่อน live คืนนี้ไหม?",
      "direction": "inbound",
      "sent_at": "2026-07-05T03:18:41Z"
    }
  }
}

สิ่งสำคัญคือ envelope: id, type, provider, account_id, occurred_at และ data handler เดียวกันวันนี้รับ provider: "tiktok" ได้ และวันพรุ่งนี้รับ provider: "line" ได้ ในไทย LINE เป็นช่องทางหลักของหลายทีม ดังนั้นการทำ schema ให้เหมือนกันตั้งแต่แรกช่วยลดงานเมื่อเพิ่ม LINE ภายหลัง

ลงทะเบียน endpoint ก่อน

ก่อนต่อเข้าคิว ให้สร้าง webhook endpoint ก่อน endpoint จะเก็บ URL, subscribed events, สถานะการเซ็น และ retry policy ตั้งค่า signing_secret เพื่อให้ delivery ทุกครั้งมี X-Device-Timestamp และ X-Device-Signature

curl -X POST https://api.unifyport.ai/v1/webhook-endpoints \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://example.com/webhook",
  "status": "active",
  "subscribed_events": ["message.received"],
  "signing_secret": "<WEBHOOK_SIGNING_SECRET>"
}'

UnifyPort เซ็น timestamp จุดหนึ่งตัว และ raw request body ด้วย HMAC-SHA256 ให้ตรวจลายเซ็นจาก raw bytes ก่อน parse JSON อย่า parse แล้ว serialize body ใหม่ก่อนตรวจ เพราะ bytes จะเปลี่ยน

import crypto from "crypto";
import express from "express";

const app = express();
const signingSecret = process.env.WEBHOOK_SIGNING_SECRET;

app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const timestamp = req.get("X-Device-Timestamp");
  const signature = req.get("X-Device-Signature");

  const hmac = crypto.createHmac("sha256", signingSecret);
  hmac.update(timestamp);
  hmac.update(".");
  hmac.update(req.body);
  const expected = hmac.digest("hex");

  const valid =
    signature.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));

  if (!valid) {
    res.status(401).end();
    return;
  }

  const event = JSON.parse(req.body.toString("utf8"));
  if (event.type === "message.received") {
    console.log(event.provider, event.data.sender.id, event.data.message.text);
  }

  res.status(200).end();
});

app.listen(3000);

แค่นี้พอสำหรับขอบของ inbound intake แล้ว production สามารถนำ event ไปวางใน queue ต่อได้ แต่ boundary เหมือนเดิม: signed delivery เข้า verified event ออก

บันทึกก่อน route ทีหลัง

เอกสาร UnifyPort ระบุชัดว่า webhook events คือบันทึกเดียวของ inbound traffic ไม่มี message read API และไม่มีทาง backfill payload ที่พลาดไป ดังนั้น queue ควรออกแบบให้บันทึกก่อน

write แรกควรบันทึก event ตาม id พร้อม raw body หรือ parsed JSON, provider, account ID และ occurred_at หลังจาก write สำเร็จ routing จึงทำแบบ asynchronous:

TikTok message
  -> UnifyPort message.received webhook
  -> Signature verification
  -> Event store keyed by id
  -> Routing queue
  -> CRM lookup, Slack alert, helpdesk ticket, or AI triage

ตรงนี้ทำให้เห็นตำแหน่งของ Data Portability API ชัดขึ้น export เหมาะกับการถ่ายโอนข้อมูลที่ผู้ใช้อนุญาต live support queue เหมาะกับการปฏิบัติงาน ทั้งสองอยู่ร่วมกันได้ แต่ไม่ควรสับสนว่าเป็นอย่างเดียวกัน

เพิ่ม reply เฉพาะเมื่อ workflow ต้องการ

บางทีมต้องการแค่ inbound triage บางทีมต้องการให้ queue สร้างคำตอบหลังจากคนหรือ AI assistant ตัดสินใจ ให้ถือ reply เป็นขั้นที่สองอย่างชัดเจน

สำหรับ outbound messaging, UnifyPort ใช้ POST /v1/messages พร้อม account, recipient และ normalized message body inbound event ให้ provider, account, sender, conversation และ message text ส่วน reply workflow ตัดสินใจว่าจะส่งอะไรกลับหรือไม่

curl -X POST https://api.unifyport.ai/v1/messages \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "account_id": "acc_8c21d0",
  "to": { "id": "tt_user_4839", "type": "user" },
  "message": { "type": "text", "text": "ยังมีของ กระเป๋า tote สีดำสั่งได้ก่อน live คืนนี้" }
}'

Inbound และ outbound ควรแยกกันใน codebase path แรกจับและเก็บข้อความจากลูกค้า path ที่สองส่งคำตอบเฉพาะหลังจาก business logic ตัดสินใจแล้ว

ทำไมเรื่องนี้สำคัญในเดือนกรกฎาคม 2026

การอัปเดตเอกสารของ TikTok วันที่ 4 มิถุนายนเตือนว่า platform APIs มักเจาะจง policy surface หรือ product surface บางอย่าง Data portability คือการถ่ายโอนข้อมูลที่ผู้ใช้ควบคุม Content Posting คือการเผยแพร่ Display API คือการแสดง creator content ชื่อเหล่านี้ไม่ได้แปลว่าเป็น “live direct-message inbox สำหรับ support” โดยอัตโนมัติ

ทีมเล็กเสียเวลาเมื่อมอง API category ที่เพิ่งถูก document ว่าเป็น customer-service event stream ทั้งหมด รูปแบบที่ดีกว่าคือเรียกชื่อ workflow ก่อน แล้วเลือก interface ที่ตรงกับ timing ของมัน

ถ้า workflow คือ export ให้ใช้เครื่องมือ export ถ้า workflow คือ support ให้ใช้ webhook ถ้าวันนี้เป็น TikTok และเดือนหน้าเพิ่ม LINE หรือ Zalo ให้รักษา webhook envelope ที่ normalized ตั้งแต่แรก

สรุปการแบ่งหน้าที่คือ TikTok Data Portability ช่วยผู้ใช้ย้ายข้อมูลของตัวเอง ส่วน UnifyPort ช่วยให้ระบบซัพพอร์ตของคุณรับข้อความลูกค้าในเวลาที่ข้อความมาถึง