Newsletter API - Плагин WordPress

Руководство по настройке и применению Newsletter API для WordPress

Newsletter API нужен не для ручной рассылки писем, а для связки сайта на WordPress с внешними формами, приложениями, личными кабинетами, посадочными страницами и внутренними сервисами. В этом руководстве разберём, как подойти к установке и настройке API-дополнения к The Newsletter Plugin, какие маршруты использовать для подписки и управления подписчиками, как проверить результат и где чаще всего ломается интеграция.

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

Главная идея Newsletter API - дать внешнему коду понятный способ работать с подписками The Newsletter Plugin через REST API. Часть маршрутов ориентирована на публичную подписку, а часть - на защищённое серверное управление подписчиками. Именно это разделение важно понять до настройки, потому что оно влияет на безопасность, архитектуру формы и место хранения ключей.

Какую задачу решает API-дополнение

В обычном сценарии The Newsletter Plugin собирает подписчиков через формы, виджеты, страницы подписки и инструменты самого WordPress. Newsletter API добавляет другой слой - программный доступ. Он полезен, когда подписка происходит не в стандартной форме плагина, а в другой точке: на отдельной посадочной странице, в пользовательском кабинете, в собственном приложении, в интеграционном сервере или в скрипте, который синхронизирует контакты между системами.

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

Типичные сценарии применения

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

• Посадочная страница передаёт email в подписку без отдельного плагина форм.
• Личный кабинет синхронизирует предпочтения пользователя с подписными списками.
• Внутренний сервис агентства добавляет подписчика после проверки заявки.
• Интеграционный сервер обновляет поля подписчика и не раскрывает ключ API в публичной части сайта.

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

Кому Newsletter API подходит, а кому лучше выбрать другой путь

Newsletter API стоит рассматривать как инструмент для технической интеграции. Он не заменяет редактор рассылок, не проектирует письма и не решает за сайт вопросы доставки почты. Его задача уже - связать внешний источник данных с подписчиками The Newsletter Plugin. Поэтому решение хорошо ложится на проекты, где есть разработчик или хотя бы человек, который может безопасно настроить серверный запрос и проверить ответ API.

Подходящие проекты

Лучше всего дополнение раскрывается там, где подписка связана с бизнес-логикой. Для контентного сайта это может быть лид-магнит: пользователь оставляет email, получает материал, а сайт добавляет его в нужный список. Для образовательного проекта - синхронизация подписки после записи на курс. Для агентства - единая форма на нескольких промо-страницах, которая отправляет контакты в один WordPress-сайт с The Newsletter Plugin.

Когда API может быть лишним

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

Практический ориентир: если подписка происходит внутри WordPress и её можно собрать штатной формой, начинайте без API. Если email приходит из внешнего кода, отдельного сервера или сложного сценария, Newsletter API становится оправданным.

Что проверить перед установкой на сайт

Подготовка важна не меньше, чем сам запрос к API. Большинство проблем с интеграцией возникает не из-за синтаксиса JSON, а из-за окружения: сайт доступен только по HTTP, сервер режет заголовок авторизации, REST API закрыт защитным плагином, на тестовом домене включена базовая авторизация или ключ API случайно попадает в публичный код.

Базовая проверка WordPress и The Newsletter Plugin

Перед установкой дополнения убедитесь, что основной The Newsletter Plugin уже установлен, активирован и корректно хранит подписчиков. Откройте админ-панель WordPress, проверьте раздел подписчиков, создайте тестовую запись штатным способом и убедитесь, что она появляется в списке. Это простая проверка, но она отделяет проблемы API от проблем основной рассылочной базы.

• Сайт должен принимать REST-запросы WordPress без блокировки со стороны защиты или сервера.
• Почтовые настройки The Newsletter Plugin должны быть рабочими, если сценарий включает подтверждение подписки или последующие письма.
• Тестовый email должен быть отдельным от реальной клиентской базы, чтобы не портить статистику.
• Доступ к ключу API должен быть только на серверной стороне, если маршрут управляет подписчиками.

Почему HTTPS и заголовок авторизации критичны

Документация API отдельно выделяет аутентификацию и работу с ключом. В реальном проекте это означает, что серверный код должен передавать заголовок авторизации так, как ожидает API, а веб-сервер не должен его удалять. Для продакшена используйте HTTPS. Тесты по обычному HTTP допустимы только в локальной среде, если вы понимаете риск и не передаёте реальные контакты.

Если сайт закрыт дополнительной защитой, сначала проверьте базовый REST API WordPress. Например, откройте системный маршрут WordPress в браузере или через инструмент запросов. Если уже он возвращает ошибку доступа, запросы Newsletter API тоже будут вести себя непредсказуемо.

Установка и первая проверка после активации

Установка Newsletter API похожа на установку обычного WordPress-плагина, но важно помнить о зависимости от The Newsletter Plugin. Сначала должен работать основной плагин рассылок, затем активируется API-дополнение. После этого в админ-панели появляется возможность настроить доступ и использовать документированные REST-маршруты.

Порядок безопасного первого запуска

1. Сделайте резервную копию сайта или хотя бы базы данных перед изменениями на рабочем проекте.
2. Установите основной The Newsletter Plugin, если он ещё не установлен, и проверьте, что подписчики создаются штатным способом.
3. Установите и активируйте Newsletter API как обычный плагин WordPress через раздел Plugins.
4. Откройте настройки дополнения и создайте или проверьте ключ доступа для защищённых маршрутов.
5. Сделайте первый тестовый запрос на безопасном тестовом email, а не на реальном клиентском адресе.

После активации не спешите подключать API к рабочей форме. Сначала проверьте простой запрос в инструменте вроде Postman, Insomnia или через серверный curl. Так вы увидите чистый ответ API без влияния JavaScript, темы, кеша, валидации формы и сторонних обработчиков.

Мини-проверка REST-маршрута

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

curl -X POST "https://example.com/wp-json/newsletter/v2/subscriptions" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.",
    "name": "Test Reader"
  }'

Если ответ успешный, проверьте не только сообщение в инструменте запросов, но и список подписчиков в WordPress. Правильная проверка всегда двусторонняя: API должен вернуть ожидаемый ответ, а запись должна появиться или измениться в админ-панели The Newsletter Plugin.

Настройка ключей, маршрутов и безопасной архитектуры

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

Где хранить ключ API

Ключ доступа нельзя вставлять в HTML-страницу, файл темы, который отдаётся в браузер, или JavaScript на посадочной странице. Если ключ нужен для маршрута управления подписчиками, создайте серверный посредник: ваш сайт или отдельный сервер получает данные формы, проверяет их, добавляет защиту от спама, а затем отправляет запрос к Newsletter API. Посетитель видит только вашу форму и не получает ключ.

Безопасный минимум для серверного посредника

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

Как выбрать маршрут под задачу

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

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

Маршруты API как цепочка данных: ввод, логика, результат

Чтобы не запутаться в маршрутах, полезно смотреть на Newsletter API как на цепочку: внешний источник даёт данные, сервер проверяет их, API применяет действие, The Newsletter Plugin меняет запись подписчика, а администратор проверяет результат в WordPress. Такая схема помогает заранее найти слабые места.

Что считать входными данными

Минимальный вход обычно начинается с email. Дальше идут имя, дополнительные поля, списки, источник подписки и согласие пользователя, если оно требуется вашей политикой. Не отправляйте в API всё подряд. Чем меньше случайных полей попадает в запрос, тем проще понять, почему запись создалась неправильно или почему плагин отклонил данные.

Что делает логика продукта

The Newsletter Plugin хранит подписчиков и работает с их статусами, списками и рассылками. API-дополнение не должно обходить эту логику прямой записью в базу. Его смысл как раз в том, чтобы внешний код обращался к документированному слою, а не ломал внутреннюю структуру плагина. Это снижает риск при обновлениях и делает интеграцию понятнее для поддержки.

Как выглядит результат

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

Мини-итог: успешный HTTP-ответ ещё не означает, что бизнес-сценарий завершён. Проверяйте запись подписчика, список, статус, письмо подтверждения и поведение повторной отправки.

Практический пример: внешняя форма подписывает пользователя на нужный список

Разберём реалистичный сценарий: у сайта есть отдельная посадочная страница с формой для скачивания материала. После отправки формы email должен попасть в The Newsletter Plugin, а администратор должен видеть, из какого источника пришёл подписчик. Пример не привязан к конкретному конструктору страниц, потому что API используется на уровне серверного запроса.

Цель сценария

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

Подготовка

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

Шаги настройки

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

Пример серверного запроса для защищённого действия

Ниже условный пример структуры запроса. Значения ключа, поля и точный маршрут сверяйте с документацией вашей версии API. Не вставляйте такой запрос в публичный JavaScript:

curl -X PUT "https://example.com/wp-json/newsletter/v2/subscribers" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_PRIVATE_API_KEY" \
  -d '{
    "email": "Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.",
    "name": "Test Reader",
    "lists": [1],
    "source": "lead-magnet"
  }'

После теста откройте карточку подписчика и проверьте, что изменились именно те данные, которые вы передали. Если API вернул успех, но список не назначился, не пытайтесь сразу менять код формы. Сначала убедитесь, что используемый параметр поддерживается маршрутом, список существует, а значение передано в ожидаемом формате.

Проверка и нюанс повторной отправки

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

Проверка результата в WordPress и в пользовательском сценарии

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

Админ-проверка

Откройте раздел подписчиков The Newsletter Plugin и найдите тестовый email. Проверьте поля, статус, список и дату изменения в рамках доступных данных интерфейса. Если вы передавали дополнительные поля, сверяйте их по одному. Не делайте вывод о корректности интеграции по одному успешному ответу в консоли.

Проверка публичной части

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

Контроль повторной отправки

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

Проверка почты и согласия

Если в The Newsletter Plugin включён режим подтверждения подписки, пользователь должен получить письмо. Если письмо не приходит, отделяйте проблему API от проблемы доставки: сначала проверьте, создался ли подписчик и какой у него статус. Затем смотрите журнал отправки, настройки почты и ограничения хостинга. Для сайтов с юридически важным согласием храните источник и состояние согласия так, как требует ваша внутренняя политика.

Ограничения, безопасность и поддержка интеграции

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

Не используйте API как прямую замену CRM

The Newsletter Plugin остаётся WordPress-плагином для рассылок и подписчиков. Newsletter API удобно связывает его с внешним кодом, но не превращает сайт в полноценную CRM с воронками, сделками, сложными ролями продаж и автоматизацией всех касаний. Если проекту нужна именно CRM-логика, рассмотрите специализированные решения из раздела альтернатив.

Не раскрывайте ключ и не обходите REST API

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

Как планировать обновления

Перед обновлением WordPress, The Newsletter Plugin или API-дополнения держите короткий тестовый сценарий: подписка нового email, повторная отправка, обновление списка, проверка ошибки авторизации. Такой набор занимает мало времени, но быстро показывает, осталась ли интеграция рабочей. Если сайт критически зависит от API, сначала тестируйте обновления на копии сайта.

Журналирование без лишних персональных данных

Для поддержки API-интеграции нужен журнал, но журнал не должен превращаться во вторую базу подписчиков. Записывайте технические детали, которые помогут отладке: время попытки, маршрут, общий статус ответа, код ошибки, источник формы и внутренний идентификатор сценария. Email можно маскировать или хранить только в тех случаях, где это разрешено политикой проекта. Не сохраняйте API-ключи, полные заголовки авторизации и сырой ответ с чувствительными данными в обычный файл логов, особенно если к нему имеют доступ подрядчики или система мониторинга.

Практичный формат журнала - короткая строка на одну попытку. Например: источник формы, результат валидации, был ли отправлен запрос к API, что вернул сервер, найден ли подписчик после проверки. Такой журнал помогает быстро понять, где остановилась цепочка. Если запись не дошла до WordPress, смотрите серверный обработчик. Если дошла, но письмо не ушло, переходите к почтовой диагностике. Если всё прошло, но пользователь видит ошибку, проблема может быть в публичной форме или кешируемом сообщении.

Что передать разработчику или поддержке

Если интеграцию будет обслуживать другой человек, оставьте короткую техническую памятку. В ней должны быть не секреты, а карта сценария: какая форма отправляет данные, какой серверный обработчик принимает запрос, какой маршрут Newsletter API используется, где лежит закрытая конфигурация, как сделать тестовую подписку и где проверять результат. Это сильно сокращает время диагностики, когда через несколько месяцев нужно поменять поле, список или источник подписки.

• Опишите маршрут пользователя: страница, форма, сообщение после отправки, письмо подтверждения.
• Опишите технический маршрут: обработчик, API endpoint, проверка ответа, журнал.
• Укажите, какие данные считаются обязательными, а какие передаются только при наличии.
• Запишите тестовый сценарий отката: как временно отключить внешний обработчик и вернуть штатную форму.

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

Диагностика ошибок Newsletter API без хаотичных правок

Ошибки API обычно выглядят одинаково для пользователя: форма не сработала, подписчик не появился или внешний сервис получил отказ. Но причины разные. Чтобы не менять код вслепую, идите от симптома к проверке: доступен ли REST API, проходит ли авторизация, поддерживается ли маршрут, корректны ли данные, не мешает ли защита или кеш.

Запрос возвращает отказ авторизации

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

Что проверить

• Сравните формат авторизации с официальной страницей API Authentication.
• Проверьте запрос из серверной консоли, а не только из браузера.
• Убедитесь, что веб-сервер передаёт заголовок Authorization в WordPress.
• Создайте новый тестовый ключ и повторите запрос на тестовом email.

Если сервер не передаёт заголовок авторизации, документация API предлагает настроить передачу заголовка на уровне окружения. Делайте это только после резервной копии конфигурации и проверки на тестовом сайте. Пример ниже показывает типовую идею для Apache, но конкретная строка зависит от хостинга:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

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

Маршрут не найден или возвращает странный ответ

Симптом: запрос к /wp-json/newsletter/v2/... возвращает ошибку маршрута, HTML-страницу, редирект или ответ защитного плагина. Возможная причина - не активировано API-дополнение, закрыт REST API, указан неверный маршрут, сайт за прокси меняет адрес или запрос уходит не на тот домен.

Сначала проверьте системный REST API WordPress. Затем убедитесь, что Newsletter API активно и что маршрут соответствует документации выбранной версии. Если ответом приходит HTML, а не JSON, посмотрите редиректы, базовую авторизацию, защитные плагины и правила CDN.

Подписчик не появился после успешного ответа

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

Ищите email глобальным поиском по подписчикам, проверьте статус и фильтры списка. Если сценарий использует подтверждение, запись может быть не в том состоянии, которое вы ожидаете после обычной подписки. Не выключайте подтверждение только ради теста, если оно нужно проекту. Лучше понять, какой статус должен быть после выбранного маршрута.

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

Симптом: после одного клика внешний обработчик отправляет два или больше запросов. Причина чаще всего в публичной форме: двойной обработчик JavaScript, повторная отправка по нажатию Enter, отсутствие блокировки кнопки или повтор webhook-события во внешнем сервисе.

Добавьте защиту от повторной отправки на уровне интерфейса и серверной логики. Серверный обработчик должен уметь безопасно повторить запрос без создания дублей. Если API уже корректно обновляет существующего подписчика, проблема решается на уровне формы и логики внешнего сценария.

Письмо подтверждения не приходит

Симптом: подписчик появился, но письмо подтверждения не доставлено. Возможная причина может быть не в Newsletter API, а в почтовой доставке, статусе подписчика, настройках подтверждения или ограничениях хостинга. Проверьте журнал отправки, SMTP-настройки, статус контакта и обычную подписку через штатную форму.

Когда откатывать изменение: если после включения API перестали работать штатные формы или массово меняются статусы подписчиков, отключите внешний обработчик, сохраните логи и вернитесь к последнему рабочему состоянию. Не продолжайте тесты на реальной базе без понимания причины.

Когда Newsletter API будет удачным выбором

Newsletter API стоит использовать, если у сайта уже есть The Newsletter Plugin, а подписчики должны попадать в него из внешней формы, сервера, приложения или нестандартного WordPress-сценария. Сильная сторона продукта - не красивые формы, а документированный программный мост между внешним действием и базой подписчиков.

Перед рабочим запуском проверьте четыре вещи: основной плагин рассылок корректно хранит подписчиков, REST API WordPress доступен, ключ не раскрывается в публичной части сайта, а тестовый запрос проверен в админ-панели и в пользовательском сценарии. Если эти условия выполнены, можно загрузить Newsletter API, установить его на тестовую копию сайта и пройти контрольный сценарий перед подключением к реальной форме.

Если же проекту нужна полноценная CRM, сложные цепочки автоматизации или внешняя инфраструктура доставки, сначала сравните альтернативы. API-дополнение хорошо решает конкретную задачу интеграции, но не должно становиться универсальной заменой всей рассылочной архитектуры.