← All posts
Tutorial

TikTok Data Portability vs Live DMs: Build the Inbound Queue Your Support Team Actually Needs

TikTok’s developer surface keeps getting more precise, but precision does not always mean it solves the support problem in front of you.

On June 4, TikTok updated the Data Portability API changelog to say its Data Types documentation now reflects current supported categories and fields. The Data Portability API product page says the API lets TikTok users in the European Economic Area and United Kingdom authorize transfers of their information to another app. The current data types page lists direct message history as an export category, with fields such as date, sender, and content.

That is useful for portability, archive, backup, and compliance workflows. It is not the same thing as a live customer-service inbox.

If your team sells through TikTok Shop, runs creator campaigns, or receives product questions in direct messages, the operational need is immediate: every new message should hit your queue, get deduplicated, trigger a CRM lookup, and route to a teammate or AI assistant. A user-authorized archive export does not give you that event loop. A signed inbound webhook does.

The job you are hiring the integration to do

Before choosing an API, write down the job in plain language:

  1. A customer sends a TikTok direct message.
  2. Your backend receives the message within seconds.
  3. The delivery is signed, so your server can trust it.
  4. The payload is stored because missed events cannot be recovered later.
  5. The same queue can later receive WhatsApp, LINE, Zalo, Telegram, or X messages.

TikTok’s Data Portability API is not built around that sequence. It is a user-consented data transfer product. Applicants must serve EEA or UK users, pass privacy and security review, and request defined data scopes. The data model is about exports: posts and profile, activity, direct messages, or a full archive.

That is the wrong timing model for support. Support is not asking, “Can this user export yesterday’s archive?” It is asking, “Can we react to the message that arrived ten seconds ago?”

The UnifyPort webhook shape

UnifyPort’s TikTok unofficial interface is built for the second model. You connect the TikTok account, register a webhook endpoint, and subscribe to message.received. When a customer message arrives, UnifyPort sends one standard envelope to your 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": "Is the black tote still available before tonight's live?",
      "direction": "inbound",
      "sent_at": "2026-07-05T03:18:41Z"
    }
  }
}

The envelope is the important part: id, type, provider, account_id, occurred_at, and data. The same handler can process provider: "tiktok" today and provider: "zalo" tomorrow. Your routing layer should branch only where platform behavior truly differs.

Register the endpoint first

Create the webhook before you connect it to the queue. The endpoint stores the URL, subscribed events, signing state, and retry policy. Use signing_secret so each delivery includes X-Device-Timestamp and 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 signs the timestamp, a dot, and the raw request body with HMAC-SHA256. Verify against the raw bytes before parsing JSON. Do not parse and re-serialize the body first, because that changes the bytes you are checking.

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);

That is enough for the intake edge. Production code can place the event on a queue, but the boundary stays the same: signed delivery in, verified event out.

Store first, route second

UnifyPort’s documentation is explicit that webhook events are the only record of inbound traffic. There is no message read API and no backfill path for missed payloads. That should shape your queue.

The first write should store the event by id, with the raw body or parsed JSON, the provider, the account ID, and the occurred_at timestamp. Once that write succeeds, routing can happen asynchronously:

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

This is also where the Data Portability API belongs in your mental model. Exports are useful for user-authorized data movement. The live support queue is useful for operations. They can coexist, but they should not be confused.

Add replies only when the workflow needs them

Some teams only need inbound triage. Others want the queue to produce replies after a human or AI assistant decides what to send. Keep that as an explicit second step.

For outbound messaging, UnifyPort uses POST /v1/messages with the account, recipient, and normalized message body. Your inbound event gives you the provider, account, sender, conversation, and message text; your reply workflow decides whether to send anything back.

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": "Yes, the black tote is still available." }
}'

Inbound and outbound should stay separate in the codebase. The first path captures and stores what customers send. The second path sends a response only after your business logic makes that decision.

Why this matters in July 2026

The June 4 TikTok documentation update is a good reminder that platform APIs are often specific to a policy or product surface. Data portability is about user-controlled transfer. Content Posting is about publishing. Display APIs are about creator content. None of those names automatically mean “live direct-message inbox for support.”

Small teams lose time when they treat every newly documented API category as a customer-service event stream. The better pattern is to name the workflow first, then choose the interface that matches its timing.

If the workflow is export, use export tooling. If the workflow is support, use a webhook. If the workflow spans TikTok today and Zalo or LINE next month, keep the webhook envelope normalized from the start.

That is the practical split: TikTok Data Portability can help users move their data. UnifyPort helps your support system receive customer messages when they arrive.