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

Skirbo +
Sendsay

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

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

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

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

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

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

Индивидуальный выпускАдаптер → основное API SendsayОбсудим в составе подключения

Выбрать согласованный саблогин/отправителя и шаблон, определить email или users.list, связать неизменяемое событие с request.id и сохранить track.id.

Статистика письмаSendsay → журнал сообщения SkirboОбсудим в составе подключения

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

Ошибка адреса или отпискаSendsay → владелец клиентского контактаОбсудим в составе подключения

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

Потоковая очередьАдаптер → Stream API при отдельной приёмкеОбсудим в составе подключения

Развести uuid письма, customer.id и локальное событие; проверить текущую версию, очереди и гарантии повторов до смены интерфейса.

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

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

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

Для магазина и обслуживающего его фулфилмента, которым нужны адресные email-уведомления об исполнении заказа. Тема — Sendsay и его основное API/Stream API в коммуникационном процессе. Письмо не оформляет физическую выдачу, платёж, чек или приёмку возврата. Массовая рекламная кампания и сервисное уведомление имеют разные основания и очереди; применимость к стране и аккаунту проверяется отдельно.

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

В текущей документации основного Sendsay API транзакционное письмо отправляется через issue.send с group=personal. Результат прослеживается через track.id, track.get и статистику письма. Вебхуки описывают события доставки, ошибок и отписки. Сохранённая спецификация Stream API 1.6 от 2022 года использует uuid письма и отдельный способ обмена; её параметры не переносятся автоматически в основное API.

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

  1. Зафиксировать бизнес-событие: продавец, заказ, версия, время, подтверждённый этап и необходимые строки. При возврате не заявлять возврат денег без подтверждения учёта.
  2. Получить утверждённый адрес и назначение сообщения; сопоставить продавца с саблогином Sendsay, доменом и шаблоном. Проверить разрешения канала и обязательные подстановки.
  3. Выбрать email либо users.list с одним адресатом. Если нужен точный снимок события, передать согласованные данные явно и проверить care_vars, чтобы пустая ссылка или номер заказа не ушли клиенту.
  4. Склад сохраняет этап и выполняет физический процесс. Адаптер вызывает персональный выпуск с устойчивым request.id для этой неизменяемой попытки и сохраняет ответ track.id.
  5. Через track.get получить идентификатор letter и связать его с событием; затем запросить статистику конкретного письма или принять подходящее событие доставки.
  6. Проверить входящее уведомление по актуальному контракту, сохранить результат и различать принято, обработано, доставлено, открыто и ошибка только в пределах подтверждённых данных.
  7. При тайм-ауте повторять прежний запрос с тем же request.id только по согласованным гарантиям; при неизвестности сверять трекер/статистику. При ошибке персонализации или адреса отправка переходит ответственному.

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

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

Письмо о готовности заказа или принятом возврате

Задача: Отправить покупателю точный результат складского этапа и увидеть судьбу конкретного письма.

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

  1. Зафиксировать бизнес-событие: продавец, заказ, версия, время, подтверждённый этап и необходимые строки. При возврате не заявлять возврат денег без подтверждения учёта.
  2. Получить утверждённый адрес и назначение сообщения; сопоставить продавца с саблогином Sendsay, доменом и шаблоном. Проверить разрешения канала и обязательные подстановки.
  3. Выбрать email либо users.list с одним адресатом. Если нужен точный снимок события, передать согласованные данные явно и проверить care_vars, чтобы пустая ссылка или номер заказа не ушли клиенту.
  4. Склад сохраняет этап и выполняет физический процесс. Адаптер вызывает персональный выпуск с устойчивым request.id для этой неизменяемой попытки и сохраняет ответ track.id.
  5. Через track.get получить идентификатор letter и связать его с событием; затем запросить статистику конкретного письма или принять подходящее событие доставки.
  6. Проверить входящее уведомление по актуальному контракту, сохранить результат и различать принято, обработано, доставлено, открыто и ошибка только в пределах подтверждённых данных.
  7. При тайм-ауте повторять прежний запрос с тем же request.id только по согласованным гарантиям; при неизвестности сверять трекер/статистику. При ошибке персонализации или адреса отправка переходит ответственному.

Результат: Есть связь подтверждённого складского события с конкретным письмом и наблюдаемым результатом доставки.

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

  • Новый текст для исправленного заказа не маскируют тем же request.id: это новое бизнес-решение и новая попытка.
  • Успех HTTP без результата обработки письма не закрывает задачу коммуникации.

Недоставка, отписка и исправление контакта

Задача: Предотвратить повторную отправку на неподходящий адрес и дать поддержке понятную причину.

Когда начинается: Статистика или вебхук сообщает об ошибке доставки либо изменении подписки.

  1. Обработчик различает JSON events и JSON Stream, сохраняет каждый элемент и сопоставляет письмо с попыткой/продавцом.
  2. Результат относится к коммуникации. При постоянной ошибке или стоп-листе автоматические повторы прекращаются; складской заказ при этом остаётся в своём фактическом состоянии.
  3. Ответственный проверяет контакт и разрешённый альтернативный способ связи. Сервисное письмо не оправдывает снятие маркетинговой отписки или безусловный обход стоп-листа.
  4. После подтверждения исправления создать отдельную согласованную попытку, указав причину и связь с прежней. Историю ошибки сохранить для последующей сверки.

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

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

  • Повтор вебхука не создаёт повторную отправку.
  • Открытие письма и переход по ссылке не подтверждают физическое получение товара.

Перевод большой очереди на Stream API

Задача: Оценить потоковую отправку отдельно от уже принятого основного API.

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

  1. Разделить сервисную очередь и массовый маркетинговый тираж; получить текущие параметры аккаунта и контракта Stream, не использовать старые числовые лимиты как обещание.
  2. Сопоставить локальный ID события с uuid письма, а клиента с customer.id. Принять отдельную процедуру повторов и неизвестного результата; request.id основного API не переносится как готовая гарантия.
  3. Проверить текущую авторизацию, шаблон, sender, ошибки и статистику конкретного письма на разрешённых тестовых данных. Для пачки анализировать каждый ответ отдельно.
  4. При отложенном письме перед отправкой учитывать актуальность события и возможность отмены по текущему контракту. Если заказ уже отменён, не отправлять устаревшее подтверждение готовности.

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

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

  • Старый Stream API описывает смешение очередей массовой и транзакционной нагрузки; фактический приоритет должен быть согласован.
  • Возвращённый uuid означает приём запроса, не доказанную доставку.

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

ДанныеОтветственный источникПравило обмена
Заказ, строки и этап исполненияПродавец и WMSСнимок события исходит из подтверждённой операции склада; сообщение не меняет запас и резерв.
Адрес и разрешение на коммуникациюCRM продавца / владелец клиентских данныхСогласия, отписки и назначение сообщения учитываются отдельно; контакт другого продавца не используется.
Шаблон и персонализацияВладелец коммуникаций SendsayУтверждает черновик, источник email/users.list и обязательные значения; адаптер передаёт только разрешённые данные.
Домен, саблогин и ключВладелец аккаунта SendsayРазделение отправителей и доступов фиксируется явно; секрет не попадает в заказ или публичную заявку.
Трекер, письмо и результат каналаSendsaytrack.id, letter, статистика и событие доставки имеют отдельный смысл; их не приравнивают к этапу заказа.
Возврат денег и документыУчёт продавца / издатель документаВ письме можно сообщить подтверждённый факт или ссылку; само письмо не выполняет финансовую операцию.

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

  • Какой интерфейс и саблогин используется для сервисных уведомлений каждого продавца?
  • Как подтверждены sender/domain и откуда берутся адрес и разрешение на сообщение?
  • Нужны данные CDP или неизменяемый снимок через users.list/extra?
  • Как хранятся request.id, track.id, letter либо uuid и как сверяется неизвестный результат?
  • Как устроены подлинность, повтор и формат вебхука; какие ошибки останавливают отправку?
Перед оценкой

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

  • Аккаунт Sendsay, саблогин и API-ключ с нужным доступом; подтверждённый адрес отправителя и согласованная email-аутентификация домена.
  • Выбор основного API либо Stream API и актуальный контракт именно выбранного интерфейса; собственная связь продавца, саблогина и домена.
  • Источник адреса и разрешения на сервисное сообщение, версия шаблона, обязательные подстановки и правила безопасной ссылки на заказ.
  • Журнал event → request.id/uuid → track.id/letter по применимому интерфейсу; правила неизменности запроса, тайм-аутов и сверки результата.
  • Обработчик выбранного формата вебхуков, проверка подлинности по действующему контракту и процедура исправления контакта, отписки и постоянной ошибки доставки.
Границы сценария

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

  • Принятый запрос или track.id не подтверждает вручение письма, а доставленное письмо не подтверждает выдачу заказа.
  • users.list и email имеют разный источник персонализации. Нельзя предполагать, что актуальные складские данные автоматически заменят старую карточку CDP.
  • Повтор request.id в основном API не доказывает те же гарантии у uuid Stream API; область и срок действия защиты проверяются отдельно.
  • Событие завершения выпуска из общей инструкции вебхуков исключает транзакционные выпуски; для них нужна прослеживаемость конкретного письма.
  • Сохранённая версия Stream API датирована 2022 годом. Текущие лимиты, сроки хранения идентификаторов, поведение отложенной отправки и доступ аккаунта требуют подтверждения перед реализацией.
  • Одиночная отправка через Stream может относиться к массовой рассылке. Маркетинговая нагрузка и сервисные уведомления не должны конкурировать без согласованного решения.
  • Отмена заказа не отзывает уже доставленное письмо. Изменение контакта или корректирующее уведомление оформляются отдельным подтверждённым действием.
Стоимость и запуск

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

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

Для оценки подготовьте один подтверждённый этап заказа, обезличенное письмо с обязательными подстановками, выбранный интерфейс Sendsay и схему sender/саблогина; отдельно покажите ожидаемое поведение при недоставке и отмене.

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

Что выбрать — основное API или Stream?

Для первого сценария полезно принять конкретное персональное письмо основного API и его сверку. Stream оценивают отдельно при нужной нагрузке и доступе; его идентификаторы и гарантии не совпадают автоматически с основным API.

Почему лучше заранее выбрать email или users.list?

При email данные могут подтянуться из карточки CDP, а users.list с одним адресатом использует переданные данные. Для статуса заказа важно исключить старые подстановки.

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

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

track.id означает, что покупатель получил письмо?

Нет. Он нужен для отслеживания запроса; далее получают letter и проверяют статистику конкретного письма. Результат доставки отделён от результата заказа.

Можно использовать uuid Stream как request.id основного API?

Это разные роли и контракты. Документация основного API описывает повтор request.id, а сохранённый Stream связывает uuid со статистикой письма; гарантии дублей нужно проверить отдельно.

Что делать после отмены заказа, если письмо уже ушло?

Доставленное письмо не отзывается изменением заказа. Ответственный решает, нужно ли отдельное корректирующее уведомление, а ещё не выполненные действия останавливает только поддерживаемым способом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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