Уведомления
Telegram
Уведомления и документы в Telegram: обсудим события, бота и права в чате.
Оценить один допустимый сервисный повод и бизнес-отправителя, хранить связь сообщения с заказом и обрабатывать обратный результат. До подтверждения страны, аккаунта, шаблона и текущего API автоматическая отправка не считается готовой.
Зафиксируем нужные операции, направление данных и условия приёмки.
| Операция | Направление | Состав и готовность |
|---|---|---|
| Событие и бизнес-отправитель | Skirbo → WhatsApp Business Platform | Нужна проверка Только после текущей проверки страны/аккаунта: событие, согласованный тип сообщения и минимальные переменные. |
| Идентификатор и результат | Business Platform → Skirbo | Нужна проверка Текущий официальный контракт и проверка подлинности обязательны; историческая конфигурация SDK недостаточна. |
| Решение о недоступности | Ответственный → процесс уведомлений | Обсудим в составе подключения Явная остановка канала и согласованный альтернативный маршрут, без личных аккаунтов. |
На узком экране таблицу можно прокрутить в сторону.
Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.
Для продавца, которому покупатель предпочёл бизнес-канал WhatsApp, и склада, передающего подтверждённые события заказа. Рассматривается официальная Business Platform/Cloud API, а не личный аккаунт сотрудника. Применимость к РФ, Казахстану и Узбекистану пока не установлена: каждая страна и организация требует проверки актуальных официальных условий.
Архивированный официальный SDK сохранён как историческая модель идентификаторов. Дополнительно прочитана политика WhatsApp Business от 23.09.2026. Текущую версию Cloud API, формат проверки событий и применимость страны/аккаунта нужно подтвердить до настройки отправки.
Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.
Задача: Проверить полный официальный маршрут одного сообщения для выбранного клиента.
Когда начинается: Склад подтвердил готовность заказа, а продавец выбрал разрешённый бизнес-канал.
Результат: Решение о подключении опирается на проверенный официальный маршрут и реальные права клиента.
Задача: Не применить параметры другого клиента к прежнему событию.
Когда начинается: Продавец меняет шаблон, номер или бизнес-аккаунт.
Результат: Переключение сохраняет принадлежность сообщений клиенту и версию содержания.
Задача: Сохранить коммуникацию и честно обозначить границу продукта.
Когда начинается: Проверка условий или аккаунта не позволяет использовать канал.
Результат: Складской процесс продолжается с согласованным способом уведомления.
| Данные | Ответственный источник | Правило обмена |
|---|---|---|
| Заказ, SKU и остатки | Продавец и система склада | В уведомление попадает только согласованный снимок события; сервис рассылки не меняет заказ или запас. |
| Складские статусы и возвраты | Система физического исполнения | Выдача, приёмка возврата и результат осмотра подтверждаются складом; сообщение WhatsApp не создаёт эти факты. |
| Контакт и выбор канала | CRM продавца / подтверждённый контакт | Заказчик определяет адресата и назначение сообщения; сведения разных клиентов не объединяются. |
| Документы | Система, выпустившая документ | В сообщении — разрешённая ссылка или согласованное вложение, а не новая юридическая версия документа. |
| Результат сообщения | Поставщик канала связи | Принятие запроса, доставка и прочтение хранятся отдельно, если выбранный продукт их предоставляет. |
| Согласие, отказ и шаблон | Продавец и администратор бизнес-канала | CRM хранит основание обращения и отказ; администратор проверяет отправителя и содержание, а склад передаёт только подтверждённое событие. |
На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.
Сначала подтвердите текущую официальную применимость Business Platform для страны и вашей организации; затем можно оценивать один допустимый складской повод и бизнес-номер.
Этот сценарий относится к официальной бизнес-платформе. Сначала проверим допустимый бизнес-номер и аккаунт, а не личную переписку сотрудника.
Проверим допустимую схему прямого подключения или действующего провайдера вашего аккаунта; условия и технические права подтвердим до разработки.
Нет. Репозиторий подтверждает лишь описанную модель API. Нужны актуальные официальные условия страны и права организации; в этом материале они остаются открытыми.
SDK прямо помечен архивированным. Реализация должна опираться на действующую официальную версию и правила; пример конфигурации не устанавливает их актуальность.
Нужно согласие и одобренный шаблон. По прочитанной политике свободный ответ допустим в течение 24 часов после сообщения пользователя; вне этого окна используется разрешённый шаблон. Применимость аккаунта всё равно проверяется отдельно.
Остановить ожидающие отправки этому адресату и сохранить отказ в CRM продавца. Уже переданное сообщение не отменяет заказ; другой канал используют только на самостоятельном допустимом основании.
Он открывает обращение продавцу. Менеджер проверяет клиента и исходный заказ, согласует возврат; физическую приёмку и состояние товара подтверждает склад отдельно.
Материал описывает предложение обмена. Работающий коннектор Skirbo, пилот и приёмка на заказах вашего клиента не подтверждены; способ реализации определяется после проверки доступов и операций. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.
Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.
Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.
Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.
Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.