WhatsApp Calling API: запись и транскрибация звонков не заменяют входящий чат
30 июня 2026 года в changelog WhatsApp Business Platform появился важный сигнал для support-команд: в Cloud API добавлены руководства по call recording и call transcription в рамках WhatsApp Business Calling API. Официальный слой звонков также описывает user-initiated calls, business-initiated calls, SIP, calling webhooks и pricing.
Если ваша поддержка в WhatsApp использует голос, это полезное обновление. Запись и транскрипт превращают разговор в проверяемый материал: что спросил клиент, что пообещал оператор, какие действия нужны дальше. Но отсюда легко сделать неверный вывод: если WhatsApp добавляет транскрибацию звонков, значит проблема клиентского контекста уже решена.
Нет. Решена задача артефактов голосового звонка. Задача входящего чата остается отдельной.
Голосовая аналитика и входящие сообщения работают по-разному
Транскрипт звонка появляется во время или после голосовой сессии. Он полезен для контроля качества, кратких summary, обучения и последующих действий. Входящий чат имеет другой контракт: быстро принять сообщение клиента, проверить подпись доставки, сохранить событие и передать его человеку, CRM, очереди или AI-worker.
Эти два слоя должны встречаться в одной клиентской timeline, но не должны зависеть друг от друга.
| Вопрос | WhatsApp Calling API recording/transcription | Подписанный inbound chat webhook |
|---|---|---|
| Основной объект | Голосовой звонок и его запись/транскрипт | Событие клиентского сообщения |
| Момент | Во время или после звонка | В момент прихода входящего сообщения |
| Лучше всего подходит для | QA, summary, compliance review, coaching, follow-up notes | Intake, routing, deduplication, CRM logging, AI triage |
| Какой сбой опасен | Потерять контекст после звонка | Потерять первое сообщение до попадания в очередь |
| Охват каналов | WhatsApp voice через официальную calling-поверхность | WhatsApp, Telegram, LINE, TikTok, Zalo и X в одном event stream |
Если ваша команда работает почти только с WhatsApp-звонками, официальный Calling API может быть центром архитектуры. Если же вы принимаете сообщения из WhatsApp, LINE, Zalo, Telegram, TikTok и X, транскрипт звонка является только одним артефактом в более широкой support timeline.
Сначала разделите границы
Официальный WhatsApp Calling API должен жить в voice-слое. Используйте его, когда клиент хочет звонить, когда нужна call button, маршрутизация звонков или когда QA-команде нужны запись и транскрипт.
Входящие сообщения должны жить в event-слое. Этот слой должен быть простым и строгим:
- Принять inbound delivery.
- Проверить подпись.
- Сохранить raw event по ID.
- Маршрутизировать по provider, account, conversation, sender и message type.
- Запускать AI, CRM и human queues после сохранения, а не до него.
Это важно, потому что чат асинхронен. Клиент может написать: “Можете подтвердить, изменилось ли время самовывоза после звонка?” и уйти. Если intake-путь ждет транскрипт звонка, CRM lookup или AI-summary, система рискует потерять именно то сообщение, которое нужно было сохранить первым.
Где здесь UnifyPort
UnifyPort не заменяет официальный WhatsApp Calling API. Если вам нужны WhatsApp voice calling, call recording или официальная транскрибация звонков, используйте официальный слой Meta для этой части системы.
Роль UnifyPort уже: принимать входящие сообщения от обычных messaging-аккаунтов через unofficial interface и доставлять их как подписанные, нормализованные webhook events. Один handler может принимать WhatsApp, Telegram, LINE, TikTok, Zalo и X.
Создайте webhook endpoint, подпишитесь на message.received и задайте signing_secret:
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://support.example.com/webhook",
"status": "active",
"subscribed_events": ["message.received"],
"signing_secret": "<WEBHOOK_SIGNING_SECRET>"
}'
Когда приходит WhatsApp-сообщение, receiver получает стандартное событие:
{
"id": "evt_20260710_01",
"type": "message.received",
"provider": "whatsapp",
"account_id": "acc_support_whatsapp",
"occurred_at": "2026-07-10T02:30:00Z",
"data": {
"conversation": { "id": "84901234567", "type": "user", "title": "Minh Tran" },
"sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
"message": {
"id": "wamid.HBgM20260710",
"type": "text",
"text": "Can someone confirm whether my pickup changed after the call?",
"direction": "inbound",
"sent_at": "2026-07-10T02:29:58Z"
},
"event": { "kind": "message_received" }
}
}
Если у endpoint есть signing_secret, доставка содержит X-Device-Timestamp и X-Device-Signature. Подпись — это hex HMAC-SHA256 от <X-Device-Timestamp>.<raw request body>. Так intake-service проверяет источник до записи в storage или передачи в AI.
Практичная архитектура выглядит так:
WhatsApp / LINE / Zalo / Telegram / TikTok / X message
-> UnifyPort message.received webhook
-> HMAC-SHA256 signature verification
-> Event store
-> Routing, CRM lookup, AI triage, or human queue
WhatsApp voice call
-> Official WhatsApp Calling API layer
-> Recording / transcript / summary artifact
-> Attach to the same customer timeline
Главный выбор — где начинается customer timeline. Она должна начинаться с первого входящего события. Запись звонка, транскрипт и summary добавляются позже как связанные артефакты.
Практическая проверка для небольшой команды
Для support-команды из 2-10 человек вопрос не в том, нужна ли транскрибация звонков. Вопрос в том, какая система владеет первой записью о контакте клиента.
Если WhatsApp voice — главный канал, официальный calling stack может быть центром опыта. Операторы отвечают на звонки, записи и транскрипты прикрепляются к звонкам, workflow остается voice-first.
Если главный канал — чат, intake-слой не должен ждать voice tooling. Сначала сохраните сообщение, затем обогащайте его:
- Если клиент позже звонит, прикрепите запись и транскрипт к той же conversation.
- Если AI готовит ответ, сохраняйте исходный
message.receivedкак источник. - Если отвечает человек, отправляйте через подключенный аккаунт и
POST /v1/messages. - Если второй канал приходит в ту же очередь, маршрутизируйте по
provider, а не создавайте новый inbox.
Обновление Meta по записи и транскрибации делает WhatsApp voice полезнее для поддержки. Но оно не отменяет необходимость чистого chat-intake слоя. Разделите эти два слоя, и команда сможет использовать оба без того, чтобы один становился входным барьером для другого.