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

Skirbo +
SendPulse

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

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

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

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

ОперацияНаправлениеСостав и готовность
Письмо по шаблонуSkirbo → SendPulseОбсудим в составе подключения

Выбранный SMTP-продукт через REST, template_id и проверенные переменные; точный контракт уточняется.

Адресная книгаПродавец ↔ SendPulseОбсудим в составе подключения

Отдельная операция только по согласованной необходимости, не побочный эффект заказа.

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

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

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

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

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

Для продавца с разрешённым SendPulse-аккаунтом и склада, который сообщает результат обработки заказа. Рассматривается SMTP-продукт через REST; адресные книги, кампании, боты и SMS — отдельные области. По прочитанным условиям услуги пользователям РФ не предоставляются, поэтому подключение для них не предлагается. Казахстан, Узбекистан и другие страны требуют самостоятельной проверки организации, аккаунта и сценария; российское ограничение на них автоматически не переносится.

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

Прочитаны README и пример официального Python REST SDK: авторизация приложения, операции адресных книг, smtp_send_mail и отправка по template_id. Это REST-вызовы SMTP-продукта; параметры обычного SMTP-соединения из них не выводятся. Дополнительно прочитаны текущие REST-методы, режимы Bearer-авторизации, настройка SMTP и обратные события. Схема подтверждения и подлинности webhook, сопоставление ID и доступ конкретного аккаунта остаются предметом проверки. Все предлагаемые ниже процессы применимы только к пользователям и сценариям, допускаемым текущими условиями; они не являются предложением запуска для пользователей РФ.

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

  1. Получить событие, номер заказа, клиентский контакт и разрешённое описание результата.
  2. Сопоставить аккаунт/продукт SendPulse, отправителя и template_id с версией переменных конкретного клиента.
  3. Выполнить согласованную серверную отправку и сохранить внешний результат рядом с внутренним ключом события.
  4. Оператор склада отдельно фиксирует фактическую передачу/приёмку; письмо лишь сообщает уже подтверждённый факт.
  5. Вернуть в Skirbo доступное подтверждение отправки и связать его с той же попыткой.
  6. Получить разрешённый итог по актуальному контракту и подтвердить обработку, не считая сам SDK-вызов доказательством доставки.
  7. При ошибке авторизации, невалидном шаблоне или неопределённом ответе остановить повтор и проверить прежнюю попытку.

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

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

Письмо о результате обработки заказа

Задача: Сообщить конкретный результат без раскрытия данных другого клиента.

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

  1. Получить событие, номер заказа, клиентский контакт и разрешённое описание результата.
  2. Сопоставить аккаунт/продукт SendPulse, отправителя и template_id с версией переменных конкретного клиента.
  3. Выполнить согласованную серверную отправку и сохранить внешний результат рядом с внутренним ключом события.
  4. Оператор склада отдельно фиксирует фактическую передачу/приёмку; письмо лишь сообщает уже подтверждённый факт.
  5. Вернуть в Skirbo доступное подтверждение отправки и связать его с той же попыткой.
  6. Получить разрешённый итог по актуальному контракту и подтвердить обработку, не считая сам SDK-вызов доказательством доставки.
  7. При ошибке авторизации, невалидном шаблоне или неопределённом ответе остановить повтор и проверить прежнюю попытку.

Результат: Уведомление связано с фактом и клиентом; письмо не создаёт складскую операцию.

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

  • В письмо не включаются заказы другого продавца через общие копии или переменные.
  • Результат приёма API не равен прочтению.

Шаблон и адресная книга

Задача: Использовать письмо по шаблону без лишнего импорта контактов.

Когда начинается: Продавец хочет применять существующий шаблон SendPulse.

  1. Проверить принадлежность template_id выбранному продукту/аккаунту и требуемые переменные.
  2. Определить, нужна ли операция адресной книги; отправка SMTP-продукта и управление списком рассматриваются раздельно.
  3. Проверить текст на одном обезличенном заказе каждого клиента и запретить отсутствующие обязательные переменные.

Результат: Сервисное письмо не становится массовой кампанией из-за общего списка.

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

  • template_id другого аккаунта не подставляется по совпадению названия.

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

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

Когда начинается: Отправка перестала проходить для аккаунта клиента.

  1. Определить, относится ли ошибка к доступу приложения, продукту, отправителю или конкретному письму.
  2. Приостановить отправку этого клиента, сохранить неподтверждённые попытки и ответственного.
  3. После восстановления проверить актуальность событий и прежние результаты перед повтором.

Результат: Сбой уведомления не отменяет фактическую выдачу и не запускает массовый повтор старых писем.

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

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

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

Задача: Объяснить новый складской факт и не возобновить старое сообщение после сбоя.

Когда начинается: Склад подтвердил приёмку возврата либо продавец отменил прежний запрос обработки.

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

Результат: Сообщения отражают последовательность фактов заказа, а восстановление доступа не создаёт устаревшие письма.

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

  • Soft bounce сам по себе не запускает новую отправку: сначала выясняются судьба текущей попытки и правила поставщика.
  • Жалоба или отписка не снимается повтором и не переносится на другой аккаунт.
  • Непроверенное обратное событие не считается доказательством доставки.

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

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

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

  • Речь о REST-доступе SMTP-продукта или обычном SMTP-соединении?
  • Принадлежит ли шаблон нужному аккаунту и какие переменные обязательны?
  • Как подтверждаются региональная доступность и итоговый статус письма?
  • Какой режим доступа включён в аккаунте: API key или client credentials, и кто отвечает за отзыв?
  • Как отличить тестового отправителя от согласованного рабочего адреса и сохранить версию шаблона?
  • Какая схема подтверждает подлинность webhook и связывает REST ID с message_id/task_id?
  • Кто разрешает повтор после bounce, разбирает пропущенный результат и отменяет устаревшее письмо?
Перед оценкой

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

  • Подтверждённая доступность продукта для организации и разрешённый аккаунт.
  • Идентификаторы приложения, отправитель, шаблон и состав переменных.
  • Правила обработки ошибок доступа и актуальности накопившейся очереди.
  • Администратор аккаунта выбирает режим REST-авторизации и управляет отдельным секретом интеграции; оператор склада не получает ключи в карточке заказа.
  • Владелец бренда подтверждает домен, разрешённый адрес отправителя и шаблон; результат тестового режима не принимается за проверку реального отправителя.
  • Владелец коммуникаций задаёт назначение сообщений, допустимые контакты и отписки; согласие на рекламу не выводится из складского события.
  • Ответственный за эксплуатацию определяет проверку подлинности обратного события и способ сверки через аккаунт; до этого webhook не выполняет авторитетные изменения.
Границы сценария

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

  • Действующая страница условий ограничивает использование для пользователей РФ и кампаний, связанных с бизнесом РФ. Другой аккаунт или страна не рассматриваются как способ обхода ограничения.
  • Данные SMTP-продукта в REST SDK не являются параметрами SMTP-сервера.
  • Адресные книги, кампании и сервисные письма — разные операции; готовый коннектор Skirbo не подтверждён.
  • Документированная отправка не устанавливает серверную идемпотентность. Тайм-аут не считается доказательством неотправленного письма.
  • Идентификаторы результата REST, message_id и task_id из примеров событий нельзя считать взаимозаменяемыми без проверенного сопоставления.
  • Отмена собственной очереди не отзывает уже отправленное письмо. Возврат товара и денежных средств подтверждают склад и платёжная система.
Стоимость и запуск

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

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

Для самостоятельной организации, которой условия SendPulse разрешают использование, выберите SMTP-продукт, аккаунт и шаблон одного события. Подключение для пользователей РФ и обход региональных ограничений не предлагаются.

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

Можно использовать уже существующий SMTP-аккаунт?

Проверим его права, домен отправителя и доступные статусы, затем согласуем, нужен ли REST API дополнительно.

Что проверить до разработки международного подключения?

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

Зачем отделять SMTP-продукт от SMTP-протокола?

В прочитанном SDK письмо отправляется REST-методом продукта. Хост, порт и механизм обычного почтового соединения нужно подтвердить отдельно, если выбран именно он.

Что делать с очередью после восстановления доступа?

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

Почему тестовое письмо пришло от другого отправителя?

В новом тестовом режиме SendPulse заменяет отправителя и добавляет отметку к теме. Проверка собственного бренда проводится отдельно после настройки домена и разрешённого адреса; тестовый результат не подтверждает их готовность.

Можно включить интеграцию для пользователя из РФ через зарубежный аккаунт?

Такой обход не предлагается. В прочитанных условиях есть прямые ограничения для пользователей РФ и кампаний, связанных с бизнесом РФ. Для самостоятельной организации другой страны проверяются её собственные условия и доступ.

Почему письмо принято, а результат ещё неизвестен?

Приём запроса и доставка происходят на разных этапах. Сохраняем ID, сверяем сведения и проверяем обратное событие; до выяснения прежней попытки не создаём дубль. Уведомление о возврате также не доказывает возврат денег.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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