TikTok Shop держит ваши DM в Seller Center под замком — как команда из трёх человек начала получать их через Webhook — UnifyPort
Команда из трёх человек торговала косметикой через TikTok Shop из Хошимина. На первом живом эфире один SKU разлетелся за одиннадцать минут: на пике 400 человек смотрели одновременно, комментарии летели быстрее, чем их можно было читать, заказы оформлялись в реальном времени. Когда трансляция закончилась и открыли Seller Center, их ждали 140 непрочитанных DM. У большинства из них таймер 12-часового ответа уже отработал два часа.
Проблема была не в людях — три человека справлялись с обычным потоком обращений. Проблема была в доступе. Каждое DM лежало внутри TikTok Seller Center — платформы, спроектированной для ручного управления почтовым ящиком, без какого-либо способа передать эти сообщения в инструмент поддержки, который команда уже использовала для WhatsApp и Zalo. Кто-то должен был следить за двумя экранами, вручную копировать сообщения и отвечать из Seller Center. На 140 DM после одного эфира такая схема не работала.
Вопрос был понятен: есть ли способ получать TikTok DM программно через вебхук — так же, как они получали сообщения из WhatsApp? Они потратили день, проверив все доступные варианты. Их оказалось три.
Путь 1: ручная почта в Seller Center
В Seller Center TikTok есть встроенная вкладка сообщений. Все DM от покупателей приходят туда — их можно читать и отвечать, не выходя из интерфейса TikTok. Никакого API, никаких вебхуков, никакого экспорта. Кто-то наблюдает за вкладкой, вручную переносит сообщения в CRM или таблицу и отвечает через Seller Center.
При небольшом потоке — допустим, 10–15 сообщений в день в спокойном режиме — это как-то работает. Но волна после живого эфира такой подход не выдерживает: пока читаешь первое сообщение, в очереди добавляется двадцать новых. Плюс это требует постоянного внимания к отдельному приложению, полностью оторванному от инструментов, которыми пользуется вся остальная команда.
Вывод: терпимо при малом объёме; ломается при скачках нагрузки после эфиров.
Путь 2: официальный API TikTok для разработчиков или Shop Partner API
Консоль TikTok for Developers изучили внимательно. Эндпоинта для DM нет. Официальный API TikTok создан для публикации контента — загрузки видео, чтения публичной аналитики, управления материалами. Приватные сообщения явно выходят за пределы этого API; TikTok прямо указывает, что по соображениям конфиденциальности доступ к DM третьим сторонам не предоставляется.
Существует более узкий путь — TikTok Shop Partner API, который даёт одобренным партнёрам некоторый доступ к сообщениям в контексте магазина. Но для этого нужен одобренный аккаунт партнёра или продавца TikTok Shop в подходящем рынке, прошедший процедуру проверки TikTok. Аккаунт команды — вьетнамский магазин, открытый через стандартную регистрацию продавца TikTok Shop — под эти требования не подходил. Сам процесс проверки занимал несколько недель, без каких-либо гарантий одобрения.
Вывод: общий API разработчиков не даёт доступа к DM; путь через Shop Partner закрыт для большинства аккаунтов.
Путь 3: неофициальный входящий интерфейс
Третий путь подходит к DM TikTok совсем с другой стороны. Вместо API для разработчиков — который изначально не создавался для открытия личных сообщений — неофициальный входящий интерфейс подключается к TikTok так же, как это делает приложение: на уровне аккаунта. Каждое входящее DM превращается в HTTP-событие и отправляется на вебхук, зарегистрированный на вашем сервере. Никакой проверки партнёра, никаких требований к рынку, никаких настроек консоли разработчика. Достаточно уже имеющегося аккаунта.
| Путь 1: Seller Center | Путь 2: официальный API | Путь 3: неофициальный входящий интерфейс | |
|---|---|---|---|
| Время запуска | мгновенно | несколько недель (проверка), одобрение не гарантировано | менее 1 дня |
| Доступ к DM через API | нет (только вручную) | недоступно для обычных аккаунтов | полный вебхук |
| Автоматизация | нет | нет | да |
| Выдержит нагрузку после эфира | нет | — | да |
| Доступен любому аккаунту | да | нет | да |
Таблица расставила всё по местам. Путь 2 закрыт. Путь 1 не выдержит нагрузки. Реально работает только путь 3.
Как выглядит путь 3 на практике
Команда подключила свой аккаунт TikTok через UnifyPort, зарегистрировала вебхук-эндпоинт и настроила signing_secret. После этого каждое входящее DM от TikTok приходит на бэкенд как нормализованное событие message.received:
{
"event": "message.received",
"account_id": "acct_tk_9Zp2",
"provider": "tiktok",
"from": "user_c14f8b",
"text": "Добрый день, я вчера на эфире купила розовый набор — когда отправите?",
"timestamp": 1750060800,
"message_id": "tt_msg_c14f8b"
}Бэкенд проверяет каждую доставку через HMAC-SHA256 по signing_secret, указанному в настройках вебхук-эндпоинта, затем помещает сообщение в ту же очередь поддержки, что используется для WhatsApp и Zalo:
app.post("/webhook", (req, res) => {
if (!verifySignature(req)) return res.sendStatus(401);
const evt = req.body;
if (evt.event === "message.received") {
supportQueue.add({
channel: evt.provider, // "tiktok", "whatsapp", "zalo" и т.д.
customer: evt.from,
text: evt.text,
messageId: evt.message_id,
});
}
res.sendStatus(200);
});Поле provider сообщает логике маршрутизации, с какого канала пришло сообщение. Логика очереди, запись в CRM, интерфейс агента — всё остаётся без изменений, потому что message.received от TikTok структурно идентично message.received от WhatsApp. TikTok просто добавился к уже существующей очереди — никакой отдельной инфраструктуры не потребовалось.
Что изменилось, что осталось прежним
На следующем эфире DM из TikTok приходили в ту же очередь вместе с WhatsApp и Zalo. Агенты работали с единым списком. Показатель 12-часового ответа — официальная метрика TikTok, влияющая на видимость магазина — перестал вызывать беспокойство: сообщения попадали в систему в течение нескольких секунд после отправки, а не ждали ручной обработки.
Команда обратила внимание на одну деталь: DM после живых эфиров короткие и насыщенные — вопросы об отправке, запасах, статусе заказа. Поскольку каждое сообщение приходит в виде структурированного события с уже разобранными ID отправителя, текстом и временной меткой, агент не тратит время на ручной перенос данных из TikTok-приложения. Сообщение сразу в том формате, который ожидает остальная часть процесса.
Никаких новых инструментов в стеке команды не появилось. Никого не наняли. Один вебхук-эндпоинт, один секрет подписи — и TikTok DM начали работать так же, как все остальные каналы. Для продавцов, одновременно работающих в TikTok и WhatsApp или Zalo, тот же message.received означает, что один обработчик покрывает все каналы — потому что неофициальный входящий интерфейс нивелирует разницу между ними ещё до того, как они достигают кода.