Обсудить задачу
Уведомления

Skirbo +
edna Pulse

Передавать в Pulse согласованный снимок складского события, а в Skirbo возвращать наблюдаемый результат сообщения. Разделять продавцов, отправителей и права ключей; принимать входящий ответ покупателя как обращение, требующее проверки перед изменением заказа.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
Событие заказаSkirbo / склад → адаптер PulseОбсудим в составе подключения

Версия события, клиент, склад, согласованный контакт и текст; канал выбирается по доступному отправителю.

Сообщение и попыткаАдаптер / оператор → edna PulseОбсудим в составе подключения

Проверенный контракт выбранного канала и локальная связь с заказом; тестовые поля не распространяются на все продукты.

Результат и ответedna Pulse → Skirbo / очередь обращенийОбсудим в составе подключения

Событие проверяется и сохраняется до подтверждения; ответ покупателя не меняет заказ без разрешённого процесса.

Доступ и отправительВладелец аккаунта → конфигурация связиОбсудим в составе подключения

Дополнительный ключ ограничивается выбранными каналами и группами методов; секреты не входят в заказ.

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

Для продавца и фулфилмент-оператора, которые хотят сообщать о готовности заказа или исключении обработки через выбранный канал edna Pulse. Центральная задача — связать событие склада с правильным отправителем и ограниченными полномочиями. Доступность конкретного канала и страны проверяется для аккаунта до выбора рабочего сценария.

Как организовать обмен

API edna Pulse использует X-API-KEY. Для рабочего каскада и обратного статуса прочитаны отдельные методы; параметры сообщения зависят от выбранного канала. Дополнительный ключ ограничивается подключёнными отправителями и группами методов. Вебхук получает собственную настройку аутентификации. Допуск конкретного аккаунта, рабочий шаблон и обработку ошибок нужно подтвердить до запуска.

Предлагаемый порядок работы

  1. Зафиксировать версию заказа, склад, факт готовности и контакт, утверждённый продавцом. Подготовить минимальный текст с понятным способом получения.
  2. Сопоставить клиента с аккаунтом Pulse, подключённым отправителем и разрешённым каналом. Проверить, что дополнительный ключ допускает этот канал и нужную группу методов.
  3. По проверенному рабочему контракту отправить сообщение или передать его назначенному оператору; связать локальное событие с идентификатором запроса. Поля requestId и cascadeId из тестового примера не считать готовым контрактом всех каналов.
  4. Склад сохраняет факт готовности и продолжает физический процесс; наличие отправленного сообщения не отмечает заказ выданным.
  5. Вернуть в Skirbo наблюдаемый результат отправки и сведения о попытке. Принятие запроса, доставка и ответ покупателя учитывать раздельно по доступным подтверждениям.
  6. Полученный webhook сначала проверить по согласованной схеме, устойчиво сохранить и сопоставить с попыткой, затем подтвердить приём по текущему контракту Pulse.
  7. При отсутствии разрешённого отправителя, истёкшем ключе или неоднозначном результате остановить автоматический повтор и открыть очередь оператора; резервный канал использовать только по заранее согласованному правилу.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Сообщение о готовности заказа от нужного продавца

Задача: Передать покупателю проверенный факт готовности, сохранив разделение клиентов общего склада.

Когда начинается: Склад завершил комплектацию и подтвердил готовность заказа к согласованному способу выдачи.

  1. Зафиксировать версию заказа, склад, факт готовности и контакт, утверждённый продавцом. Подготовить минимальный текст с понятным способом получения.
  2. Сопоставить клиента с аккаунтом Pulse, подключённым отправителем и разрешённым каналом. Проверить, что дополнительный ключ допускает этот канал и нужную группу методов.
  3. По проверенному рабочему контракту отправить сообщение или передать его назначенному оператору; связать локальное событие с идентификатором запроса. Поля requestId и cascadeId из тестового примера не считать готовым контрактом всех каналов.
  4. Склад сохраняет факт готовности и продолжает физический процесс; наличие отправленного сообщения не отмечает заказ выданным.
  5. Вернуть в Skirbo наблюдаемый результат отправки и сведения о попытке. Принятие запроса, доставка и ответ покупателя учитывать раздельно по доступным подтверждениям.
  6. Полученный webhook сначала проверить по согласованной схеме, устойчиво сохранить и сопоставить с попыткой, затем подтвердить приём по текущему контракту Pulse.
  7. При отсутствии разрешённого отправителя, истёкшем ключе или неоднозначном результате остановить автоматический повтор и открыть очередь оператора; резервный канал использовать только по заранее согласованному правилу.

Результат: Покупатель получает событие от своего продавца, а склад видит подтверждение коммуникации без подмены факта выдачи.

Если возникло исключение

  • Повтор события склада не должен создавать новое сообщение с тем же основанием.
  • Если контакт исправлен после отправки, новое сообщение согласуется как отдельная попытка, а прежняя история сохраняется.

Подключение клиента и ротация ключей

Задача: Ограничить доступ общему оператору ровно теми каналами и действиями, которые нужны процессу.

Когда начинается: Новый продавец подключает Pulse либо меняет доступ существующего аккаунта.

  1. Зафиксировать доступные отправители и группы методов; владелец аккаунта выбирает дополнительный ключ, подходящие каналы и при необходимости дату окончания.
  2. Перед обновлением основного ключа определить использующие его процессы: инструкция предупреждает о немедленной потере работы по старому ключу.
  3. Проверить новый доступ в разрешённом объёме, сменить ссылку на секрет в конфигурации и сверить очередь неизвестных результатов. Не передавать сам ключ в журнал заказа или переписку склада.

Результат: Отзыв доступа одного клиента не нарушает данные другого, а смена ключа остаётся управляемой операцией.

Если возникло исключение

  • Ограниченный ключ не даёт подтверждения прав на весь аккаунт.
  • Канал, отсутствующий среди подходящих подключённых отправителей, не включается в обещание запуска.

Приёмка тестового чата и граница рабочего сообщения

Задача: Не принять успешный тест чат-сообщения за готовность производственной рассылки.

Когда начинается: Команда проверяет потенциальный канал WhatsApp в Pulse.

  1. При допустимости выбранного канала использовать тестовую процедуру: назначенный номер отправляет сообщение на тестовый аккаунт, оператор сверяет его в аналитике Pulse.
  2. Отправить предусмотренный инструкцией ответ через API и проверить его получение тестовым устройством; связать событие и запись аналитики.
  3. Отдельно проверить рабочий отправитель, нужный тип сообщения, текущие требования канала и регион. Источник прямо исключает шаблонные сообщения из описанного тестирования.

Результат: Есть раздельные результаты проверки тестового чата и неизвестных рабочего сценария, без заявления готовой интеграции.

Если возникло исключение

  • Старый пример номера с кодом страны не доказывает текущую доступность WhatsApp в РФ.
  • Казахстан и Узбекистан оцениваются отдельно, даже если тест прошёл в другом аккаунте.

Отмена или возврат после постановки уведомления

Задача: Сохранить верную историю заказа, если подготовленное сообщение успело устареть.

Когда начинается: Продавец отменил выдачу либо склад подтвердил приём возврата, пока по предыдущему сообщению нет окончательного результата.

  1. Получить подтверждённое событие владельца заказа и сопоставить tenant, заказ, его версию и прежнюю попытку сообщения.
  2. Приостановить локальные ещё не отправленные сообщения о готовности; уже принятые edna попытки оставить в журнале до выяснения результата. Наличие API отмены этой страницей не утверждается.
  3. Склад отдельно фиксирует отмену выдачи или фактическую приёмку возврата. Сообщение не изменяет физический остаток.
  4. Владелец коммуникации проверяет необходимость отдельного сообщения об изменении и разрешённый канал. Для рекламы требуется самостоятельное основание, а не только наличие заказа.
  5. Поступивший результат сопоставить с исходной попыткой, а корректирующее сообщение — с новой версией события. Поздний результат первого сообщения не возвращает заказ в прежнее состояние.
  6. Если ответ поставщика потерян, сначала выполнить сверку по доступной истории или через поддержку; новый запрос с новым идентификатором не отправлять автоматически только ради устранения таймаута.

Результат: Оператор видит фактическое состояние заказа и обе коммуникационные попытки, не смешивая возврат товара с доставкой сообщения.

Если возникло исключение

  • Статус CANCELLED сообщения не доказывает отмену заказа или наличие доступного клиенту метода отмены.
  • Один входящий результат может прийти повторно; повторная запись не запускает новое уведомление.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
Заказ, SKU и остаткиПродавец и система складаВ уведомление попадает только согласованный снимок события; сервис рассылки не меняет заказ или запас.
Складские статусы и возвратыСистема физического исполненияВыдача, приёмка возврата и результат осмотра подтверждаются складом; письмо или SMS не создаёт эти факты.
Контакт и выбор каналаCRM продавца / подтверждённый контактЗаказчик определяет адресата и назначение сообщения; сведения разных клиентов не объединяются.
ДокументыСистема, выпустившая документВ сообщении — разрешённая ссылка или согласованное вложение, а не новая юридическая версия документа.
Результат сообщенияПоставщик канала связиПринятие запроса, доставка и прочтение хранятся отдельно, если выбранный продукт их предоставляет.
Каналы, ключи и праваВладелец аккаунта edna PulseСвязь tenant → аккаунт → отправитель → версия доступа задаётся явно; складской номер заказа не определяет канал.
Назначение сообщения и согласияПродавец — владелец отношений с покупателемПродавец определяет допустимый контакт, цель и канал; подтверждённый заказ не превращается в подписку на рекламу. Фулфилмент не объединяет согласия разных продавцов.

Что обсудить перед пилотом

  • Какой канал действительно подключён и допустим для продавца и получателя?
  • Какие группы методов нужны отдельному ключу и кто вправе менять основной?
  • Где различаются принятие, доставка, прочтение и входящий ответ?
  • Что подтверждает рабочее шаблонное сообщение, если тестовая процедура его не поддерживает?
  • Какое правило антидубликата действует для выбранного канала и как проверить результат, если ответ на отправку потерян?
Перед оценкой

Что нужно уточнить

  • Аккаунт, доступный отправитель и подтверждённая применимость канала к выбранной стране.
  • Согласованный тип сообщения, контакт и один владелец отправки.
  • Карта клиентов/каналов, хранение секретов и план смены основного ключа.
  • Актуальная схема события, проверка подлинности, подтверждение приёма и процедура неизвестного результата.
  • Назначение сообщения и разрешение на канал задаёт продавец: сервисное событие заказа и рекламная рассылка учитываются раздельно.
Границы сценария

Что учесть заранее

  • Описанный тест WhatsApp ограничен чат-сообщениями; он не подтверждает рабочую отправку шаблонов и доступность канала в РФ.
  • Прочитаны формат статусного вебхука и настройки его аутентификации. Рабочий payload канала, проверка ключа получателем и поведение при потере подтверждения требуют отдельной приёмки.
  • Истечение или смена ключа требуют остановки неподтверждённых отправок и сверки, а не безусловного повтора.
  • Регион, правила канала и доступ аккаунта проверяются отдельно. Тарифы, сроки подключения и готовность коннектора Skirbo не установлены.
  • В разных разделах edna указаны 20 минут для защиты от дубликатов при каскадной отправке и 5 минут в описании ошибки duplicated. Не установлено, относятся ли эти интервалы к одному механизму и каналу; они не принимаются за гарантию единственной отправки.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

Для оценки выберите аккаунт edna Pulse, конкретный рабочий канал и одно складское событие; подготовьте обезличенный пример сообщения, карту отправителей и наблюдаемый результат теста.

Вопросы о подключении

Почему ключи важны для общего склада?

Оператор работает с несколькими продавцами и отправителями. Дополнительные ключи Pulse позволяют ограничить каналы и группы методов; соответствие клиента, ключа и отправителя предотвращает отправку от чужого имени.

Что произойдёт при замене основного ключа?

По инструкции взаимодействие со старым ключом прекращается. Перед заменой нужно определить зависимые процессы, подготовить смену доступа и отдельно сверить попытки с неизвестным результатом.

Успешный тест WhatsApp означает готовность уведомлений?

Он подтверждает лишь проверенный тестовый чат-обмен. Инструкция исключает шаблонные сообщения из теста; рабочий отправитель, тип сообщения и текущая региональная доступность проверяются отдельно.

Может ответ покупателя сразу изменить адрес доставки?

Предлагаемый процесс направляет его в очередь обращения. Оператор проверяет автора, актуальность заказа и возможность изменения; входящий текст сам по себе не является командой складу.

Можно ли автоматически повторить отправку после таймаута?

В предлагаемом процессе сначала сохраняют попытку и выясняют её результат. Новый идентификатор может означать новое сообщение, поэтому таймаут не служит разрешением повторить отправку. Правило антидубликата для выбранного канала нужно уточнить отдельно.

Как учитывать отмену заказа и рекламную отписку?

Это разные события. Отмена приходит от владельца заказа, а разрешённые цели и каналы сообщения — из правил продавца и состояния контакта. Перед ещё не отправленным сообщением перепроверяют оба основания; уже отправленное остаётся в истории.

Интеграция уже готова?

Материал описывает предложение обмена. Работающий коннектор Skirbo, пилот и приёмка на заказах вашего клиента не подтверждены; способ реализации определяется после проверки доступов и операций. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.