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

Skirbo +
DashaMail

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

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

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

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

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

route_id и message_id связываются с клиентом и проверенным заказом; payload уточняется.

Диагностика доставки письмаDashaMail → технический журналОбсудим в составе подключения

delivery_id, status, http_code, attempts и response_body для конкретной попытки передачи, без изменения склада.

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

Подтверждённый адрес и минимально необходимые scopes; отправка — отдельный подтверждаемый метод.

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

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

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

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

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

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

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

Прочитаны архивные auth/scopes, account/senders и router/deliveries, затем отдельные текущие transactional send/status, автоматизации, управление маршрутами REST v2 и протокол Даша.Роутер. Входящий маршрут, исходящее служебное письмо и триггерная рассылка имеют разные контракты; права аккаунта и Skirbo-обмен не испытывались.

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

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

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

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

Обращение о недостаче и надёжное принятие

Задача: Не потерять письмо покупателя из-за сбоя сервера при передаче в рабочую очередь.

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

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

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

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

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

Проверить отправителя перед сервисным письмом

Задача: Не отправить клиентское сообщение от чужого или неподтверждённого адреса.

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

  1. Выбрать аккаунт и отправителя клиента, сверить его с разрешёнными данными account/senders.
  2. Проверить права transactional.send и схему выбранного метода отправки; сформировать минимальные переменные.
  3. Сохранить отдельную попытку исходящего письма и получить подтверждённый результат по его контракту.

Результат: Ответ отправляется от согласованного бренда, а входящее обращение не теряется при ошибке отправки.

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

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

Разделение прав для нескольких клиентов

Задача: Дать процессу только необходимые полномочия.

Когда начинается: Фулфилмент подключает DashaMail нового продавца.

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

Результат: Ошибка доступа не превращается в утечку данных соседнего клиента.

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

  • Ограниченные ключи API v2 нельзя молча использовать в старом API.

От обращения о возврате до подтверждённого ответа

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

Когда начинается: Покупатель прислал заявление о возврате или уточнил прежнее обращение.

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

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

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

  • Если покупатель отменил обращение до отправки ответа, локальная очередь останавливается; уже отправленное письмо остаётся в истории.
  • После ротации подписи недоставленные сообщения сверяются с журналом, без ослабления проверки подлинности.
  • Почтовый Bounced не означает возврат товара; статус Delivered не означает согласие покупателя с решением.

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

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

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

  • Нужны исходящие сервисные письма, обработка входящих или оба процесса?
  • Какие scopes необходимы конкретному рабочему процессу?
  • Как проверяется принадлежность входящего письма клиенту и когда подтверждается его приём?
  • Как связаны MIME Message-Id и внутренний ID сохранённого письма в фактическом webhook вашего маршрута?
  • Кто обеспечивает совместное переключение signing_key и обработчика и разбирает доставки при ротации?
  • Какой срок актуальности у служебного ответа и кто решает повтор после почтового отказа?
  • Нужна ли самостоятельная маркетинговая автоматизация? Если да, кто владеет её базой, событием и основаниями рассылки?
Перед оценкой

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

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

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

  • router/deliveries описывает передачу входящей почты на сервер, а не статусы отправления или доставку исходящего письма покупателю.
  • Архивные извлечения OpenAPI дополнены чтением методов и протокола. Остаются проверка форматов на выбранном аккаунте, сопоставление входящих ID и поведение повторного исходящего запроса.
  • API-ключ действует в пределах аккаунта/прав; тарифные условия и численные лимиты из архива не обещаются.
  • MIME Message-Id письма, внутренний ID сохранённого сообщения, delivery_id попытки и transaction_id ответа хранятся раздельно. Совпадение имени поля не доказывает одинаковый смысл.
  • Успешное принятие исходящего запроса не исключает последующего отказа по отписке. Ограничение контакта не снимается повтором.
  • Своя метка message_id не доказывает серверную защиту от дубля. При неопределённом ответе сначала сверяется прежняя попытка.
  • Отмена обращения не отзывает отправленное письмо и не отменяет уже выполненную складскую операцию; товарный возврат и деньги имеют свои подтверждения.
Стоимость и запуск

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

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

Выберите один входящий маршрут или одно сервисное письмо DashaMail; нужны пример ответа доставки маршрута и список минимальных прав.

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

Почему delivery_id нельзя записать как трек посылки?

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

Письмо покупателя может автоматически оформить возврат?

Предлагаемый процесс сначала связывает обращение с клиентом и заказом, затем оператор проверяет товарный факт. Текст письма не является разрешением изменить запас или деньги.

Нужно давать ключу полный доступ?

Документация v2 описывает ограниченные права. Для диагностики маршрута и для отправки нужны разные полномочия, поэтому доступ выбирается по процессу.

Если сервер ответил ошибкой, письмо потеряно?

Нужно проверить запись конкретной попытки и историю по контракту маршрута. Повтор связывается с прежним обращением; новый товарный возврат не создаётся.

Можно заменить служебный ответ обычным триггерным письмом?

Сначала выбирается назначение сообщения. В DashaMail триггер работает по событию подписчика, а одиночный transactional-ответ имеет отдельный путь. Входящее обращение не должно само включать рекламную цепочку.

Почему запрос отправки успешен, а письма нет?

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

Нужно ли ждать решения по возврату, прежде чем подтвердить webhook?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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