TikTok Shop держит ваши DM в Seller Center под замком — как команда из трёх человек начала получать их через Webhook
Команда из трёх человек торговала косметикой через 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 означает, что один обработчик покрывает все каналы — потому что неофициальный входящий интерфейс нивелирует разницу между ними ещё до того, как они достигают кода.