Руководство по продукту
Что означают скрытые проверки регистрации на платформе
Узнайте, как скрытая проверка регистрации на платформе даёт синхронный сигнал достижимости и доставляемости, не уведомляя владельца аккаунта.
Подробное руководство по скрытым проверкам регистрации на платформе: как они дают синхронные сигналы достижимости, не уведомляя владельцев аккаунтов.
Скрытая проверка регистрации на платформе — это метод проверки, который определяет, зарегистрирован ли переданный номер телефона на конкретной платформе обмена сообщениями в данный момент, не оповещая владельца аккаунта, не отправляя сообщений и не требуя действий со стороны пользователя. Организации используют такие проверки, чтобы убедиться, что номер активен на целевой платформе, прежде чем начинать коммуникацию. Это помогает командам сегментировать аудиторию и планировать процессы коммуникации на основе наличия аккаунта на платформе.
Что такое скрытые проверки регистрации на платформе
Скрытая проверка регистрации на платформе оценивает, связан ли конкретный номер телефона с аккаунтом на платформе обмена сообщениями. Слово «скрытая» описывает способ работы: проверка обращается непосредственно к каталогу платформы, не взаимодействуя с устройством конечного пользователя. Система не отправляет SMS, не вызывает push-уведомления приложения и не запрашивает у пользователя аутентификацию. Чтобы начать проверку, организация передаёт номер телефона в стандартном формате E.164. Платформа проверки обрабатывает эти данные и возвращает синхронный ответ. Поскольку процесс синхронный, результат приходит в ответе на исходный HTTP-запрос, а не через асинхронные обратные вызовы или механизмы опроса. Такая немедленная обратная связь позволяет приложениям принимать решения о маршрутизации в реальном времени на основе сигнала наличия аккаунта.
Чем скрытые проверки отличаются от сетевой аутентификации
При проектировании процессов коммуникации организации часто рассматривают как проверки на уровне платформы, так и проверки на уровне сети. Хотя обе работают без усилий со стороны пользователя, они обращаются к совершенно разным уровням инфраструктуры. Скрытая сетевая аутентификация (Silent Network Authentication, SNA) обычно использует сигнализацию на уровне оператора связи. Она взаимодействует с операторами мобильной связи, чтобы подтвердить, что конкретная SIM-карта или устройство в данный момент активны в сотовой сети. SNA тесно привязана к физической телекоммуникационной инфраструктуре. Скрытая проверка регистрации на платформе, напротив, сосредоточена исключительно на наличии аккаунта на уровне приложения. Она проверяет, зарегистрирован ли номер в конкретном сервисе, например в WhatsApp. У пользователя может быть действующий номер оператора, не зарегистрированный в WhatsApp, или, наоборот, он может зарегистрировать в WhatsApp VoIP-номер, которого нет в традиционной сотовой сети.
| Характеристика | Проверка регистрации на платформе | Скрытая сетевая аутентификация |
|---|---|---|
| Целевая инфраструктура | Приложение для обмена сообщениями (например, WhatsApp) | Оператор мобильной связи |
| Основной сигнал | Наличие аккаунта в приложении | Присутствие в сотовой сети |
| Поддерживаемые типы номеров | Мобильные, стационарные, VoIP (если зарегистрированы) | Преимущественно мобильные (на основе SIM) |
| Интеграция в процессы | Омниканальная маршрутизация, сегментация аудитории | Проверка устройства на уровне оператора |
Что такое сигнал достижимости
Сигнал регистрации подтверждает, что переданный номер в формате E.164 в данный момент связан с аккаунтом на целевой платформе, то есть инфраструктура платформы способна принимать сообщения, адресованные этому идентификатору. Он служит базовыми входными данными для процесса. Подтверждая достижимость, сигнал помогает командам эффективно распределять ресурсы, чтобы сообщения для конкретной платформы формировались только для номеров, у которых действительно есть соответствующий аккаунт в приложении.
Практические сценарии использования сигналов регистрации
Организации встраивают скрытые проверки регистрации на платформе в различные рабочие процессы, чтобы поддерживать чистоту данных и планировать коммуникацию.
Сегментация аудитории
Команды маркетинга и отдела продаж используют сигналы регистрации, чтобы сегментировать списки контактов по доступности на платформе. Определив, какие контакты достижимы в WhatsApp, команды могут адаптировать стратегию коммуникации: направлять кампании с мультимедийным контентом пользователям платформы, а обычные SMS оставлять для контактов без аккаунтов в приложении.
Омниканальная маршрутизация
Платформы поддержки клиентов используют синхронные проверки для маршрутизации сообщений. Когда клиент создаёт обращение, система может мгновенно проверить указанный номер телефона. Если номер возвращает положительный сигнал регистрации на платформе, система может отправлять последующие уведомления через мессенджер; если нет — по умолчанию использует электронную почту или SMS.
Чистота данных CRM
Администраторы баз данных периодически проверяют устаревшие записи CRM с помощью пакетных проверок. Это помогает организациям поддерживать точные сведения о том, у каких контактов сохраняется активная регистрация на платформе, что улучшает аналитику и повышает точность планирования кампаний.
Интеграция с API и синхронные процессы
Технические команды реализуют скрытые проверки регистрации на платформе с помощью синхронного REST API. Документированный контракт запроса использует эндпоинт POST /api/v1/check. Для запросов требуется заголовок X-API-Key для аутентификации и заголовок Content-Type: application/json. JSON-тело должно содержать два основных поля: service_type, определяющее запрашиваемый продукт, и identifier, содержащее целевой номер телефона в формате E.164. Архитектура API строго синхронная. Каждый эндпоинт проверки возвращает результат в ответе на исходный HTTP-запрос. Внешняя оболочка ответа для завершённой проверки состоит из code, msg и data. Если система не может принять решение по проверке, API возвращает ненулевой бизнес-код, а не объект завершённого результата. Для операций с большим объёмом платформа предоставляет синхронный пакетный эндпоинт. Он принимает до 100 идентификаторов в одном запросе, синхронно обрабатывает весь пакет и возвращает полный набор результатов в одном ответе, избавляя от сложности процессов с отправкой задач, опросом или обратными вызовами.
Типы проверок для WhatsApp
При запросе статуса регистрации в WhatsApp организации могут выбрать один из трёх типов проверки с помощью параметра service_type. Все три продукта используют одни и те же синхронные эндпоинты, а service_type определяет, какие поля возвращаются в публичном объекте data.
Стандартная проверка регистрации (ws)
Тип сервиса ws даёт базовый сигнал регистрации на платформе. Возвращаемый объект данных содержит service_type, identifier и булево поле registered, указывающее на наличие аккаунта.
Проверка с обогащением аватаром (ws_avatar)
Тип сервиса ws_avatar включает базовый сигнал регистрации и добавляет данные обогащения профиля. Ответ содержит булево поле avatar и строку avatar_url. Поле URL указывает расположение изображения профиля, однако в зависимости от настроек аккаунта оно может вернуться пустой строкой.
Проверка бизнес-профиля (ws_business)
Тип сервиса ws_business проверяет стандартную регистрацию и оценивает, использует ли аккаунт приложение WhatsApp Business. Ответ добавляет к стандартному объекту данных булево поле business, помогая командам отделять обычных пользователей от бизнес-аккаунтов.
Интеграция через Model Context Protocol (MCP)
Командам, использующим процессы на базе ИИ, скрытые проверки регистрации на платформе доступны непосредственно через ИИ-ассистентов. WA Lookup предоставляет официальный сервер Model Context Protocol (MCP), доступный по пути /mcp сайта через Streamable HTTP / JSON-RPC. Эта интеграция позволяет MCP-совместимым ИИ-клиентам, таким как Claude Code, Cursor и Claude Desktop, выполнять проверки в реальном времени с использованием существующего ключа API организации. Сервер MCP использует те же продукты, баланс, аутентификацию, ограничения параллелизма и семантику синхронных результатов, что и стандартный REST API. Инструменты, доступные ИИ-ассистенту, включают получение списка доступных продуктов, проверку одного номера в формате E.164, синхронную проверку небольшого пакета до 100 номеров и запрос баланса аккаунта. Поскольку вызовы MCP выполняются в реальном времени и синхронно, они органично встраиваются в диалоговые ИИ-процессы без необходимости управлять асинхронными задачами.
Часто задаваемые вопросы
Что возвращает скрытая проверка регистрации на платформе?
Для WhatsApp проверка подтверждает, связан ли переданный номер телефона в формате E.164 в данный момент с аккаунтом WhatsApp.
В каком формате должны быть номера телефонов для проверки регистрации?
Все передаваемые номера телефонов должны соответствовать стандарту E.164. Это гарантирует, что платформа сможет точно разобрать код страны и абонентский номер во время синхронного запроса.
Можно ли проверить несколько номеров одновременно?
Да. API предоставляет синхронный пакетный эндпоинт, который принимает до 100 идентификаторов в одном запросе. Система обрабатывает весь пакет и возвращает полный набор результатов в том же HTTP-ответе.
Что происходит, если по проверке невозможно принять решение?
Если система не может определить статус регистрации, API возвращает ненулевой бизнес-код, а не объект завершённого результата. Оплата взимается за каждую проверку, а за неудачные или неопределённые проверки средства возвращаются автоматически.