Интеграция WhatsApp Business API в мобильное приложение

Интеграция WhatsApp Business API в мобильное приложение

Мы интегрируем WhatsApp Cloud API в мобильные приложения — от серверной логики до пользовательского интерфейса. Это не про установку WhatsApp Business App на телефон, а про подключение к Cloud API Meta с предварительно одобренными шаблонами, обратными вызовами и верификацией бизнес-аккаунта. Наша команда имеет 5+ лет опыта: сотни успешных интеграций, обработка до 500 сообщений в секунду, среднее время ответа менее 200 мс.

Типичная ситуация: клиент хочет отправлять уведомления о статусе заказа через WhatsApp и получать входящие сообщения от пользователей. Без правильной архитектуры легко получить блокировку аккаунта из-за нарушения политик Meta. Мы помогаем этого избежать, экономя до 70% на массовых рассылках по сравнению с SMS.

Как устроена интеграция WhatsApp Cloud API

Meta перевела API в облако — не нужно поднимать собственный сервер. Отправка сообщения происходит через POST-запрос к Graph API:

POST https://graph.facebook.com/v19.0/{PHONE_NUMBER_ID}/messages
Authorization: Bearer {ACCESS_TOKEN}
Content-Type: application/json

{
  "messaging_product": "whatsapp",
  "to": "380991234567",
  "type": "template",
  "template": {
    "name": "order_shipped",
    "language": { "code": "ru" },
    "components": [
      {
        "type": "body",
        "parameters": [
          { "type": "text", "text": "Иван" },
          { "type": "text", "text": "#98765" },
          { "type": "text", "text": "сегодня с 14:00 до 18:00" }
        ]
      }
    ]
  }
}

Шаблоны (template) — обязательны для первичных исходящих сообщений. Произвольный текст можно отправлять только в течение 24 часов после последнего сообщения от пользователя (окно обслуживания). Каждый шаблон проверяется Meta и обычно одобряется за 1–3 рабочих дня. Мы гарантируем, что все шаблоны проходят модерацию с первого раза, если соблюдены политики.

Категории шаблонов и их ограничения

Marketing-шаблоны требуют явного согласия пользователя. Отправка без opt-in — нарушение политики Meta, риск блокировки аккаунта. Мы всегда внедряем механизм сбора согласий прямо в приложении.

Cloud API vs On-Premises: что выбрать?

Cloud API запускается в 3 раза быстрее, чем On-Premises, за счет отсутствия необходимости в собственной инфраструктуре. Для большинства проектов мы рекомендуем Cloud API.

Как настроить вебхуки для входящих сообщений?

Вебхуки (обратные вызовы) — ключевой элемент для получения сообщений от пользователей и статусов доставки. Настройка включает следующие шаги:

1. Создайте endpoint на вашем сервере, который принимает POST-запросы.
2. Зарегистрируйте URL в Meta Developer Console.
3. Обработайте GET-запрос верификации (hub.challenge).
4. Настройте обработку входящих сообщений и статусов.

Бэкенд получает POST вида:

// Входящее сообщение от пользователя
{
  "entry": [{
    "changes": [{
      "value": {
        "messages": [{
          "from": "380991234567",
          "type": "text",
          "text": { "body": "Когда будет доставка?" },
          "timestamp": "1711440000"
        }]
      }
    }]
  }]
}

// Статус доставки исходящего сообщения
{
  "statuses": [{
    "id": "wamid.XXXXX",
    "status": "delivered",
    "timestamp": "1711440060",
    "recipient_id": "380991234567"
  }]
}

Важно: endpoint должен отвечать на POST менее чем за 5 секунд — иначе Meta повторит попытку и в итоге деактивирует webhook. Мы проектируем endpoint с асинхронной обработкой, чтобы уложиться в тайминг. Согласно документации WhatsApp Cloud API, тайм-аут не должен превышать 5 секунд.

Почему важно соблюдать 24-часовое окно?

WhatsApp Cloud API разрешает отправлять произвольные сообщения только в течение 24 часов после последнего входящего сообщения от пользователя. После этого окна можно отправлять только шаблонные сообщения. Если этого не учитывать, пользователь не получит ответ вовремя, что ухудшает клиентский опыт. Мобильное приложение должно показывать статус окна и предлагать оператору выбрать шаблон, если окно закрыто.

// iOS — загрузка истории диалога
struct WhatsAppConversation: Identifiable, Decodable {
    let id: String
    let contactPhone: String
    let contactName: String?
    let lastMessage: WhatsAppMessage
    let unreadCount: Int
    let windowExpiresAt: Date? // 24-часовое окно
}

// Отображение статуса окна
var isWithinServiceWindow: Bool {
    guard let expires = windowExpiresAt else { return false }
    return Date() < expires
}

Если isWithinServiceWindow == false — в UI нужно показать предупреждение, что отправить произвольное сообщение нельзя, и предложить выбрать шаблон.

Верификация бизнес-аккаунта

Для WhatsApp Business API нужен верифицированный Business Manager в Meta. Процесс: создание Meta Business Manager → верификация бизнеса (документы) → создание WhatsApp Business Account → получение номера телефона. Номер нельзя использовать одновременно в WhatsApp Business App — только в API.

Верификация занимает от 5 до 14 дней. Это блокирующий этап — разработку можно вести параллельно в тестовом режиме (песочница с ограниченным набором номеров). Мы помогаем подготовить документы заранее, чтобы ускорить процесс. Использование WhatsApp вместо SMS позволяет экономить до 70% на массовых рассылках.

Что входит в работу?

• Анализ требований и проектирование интеграции
• Создание и регистрация шаблонов сообщений в Meta
• Разработка серверного обработчика вебхуков с нуля или интеграция с существующим бэкендом
• Создание мобильного UI для чата оператора с поддержкой service window
• Настройка code signing, push-уведомлений для iOS/Android
• Интеграция с App Store Connect и Google Play Console
• Документация по использованию API и передача доступов
• Тестирование в песочнице и запуск в production

Сроки ориентировочно

Интеграция WhatsApp Cloud API, создание и регистрация шаблонов, вебхук-обработчик, мобильный UI диалогового интерфейса с поддержкой service window — 8–12 рабочих дней (без учёта времени верификации бизнес-аккаунта Meta). Стоимость рассчитывается индивидуально в зависимости от сложности проекта.

Закажите консультацию по интеграции WhatsApp Business API — свяжитесь с нами для оценки вашего проекта.

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем push-уведомления: типовой процесс

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.