---
title: "Email-дайджест на n8n: письма, фильтры — Nodbot"
source_url: "https://nodbot.ru/recipes/email-digest/"
canonical_url: "https://nodbot.ru/recipes/email-digest/"
language: "ru"
content_type: "HowToGuide"
section: "recipes"
generated_at: "2026-05-30"
word_count_source: 1085
---

# Email-дайджест на n8n: письма, фильтры, AI-суммаризация и отправка

## AI summary

Рецепт n8n «Email-дайджест на n8n: письма, фильтры»: логика workflow, входные данные, настройки, типовые ошибки и критерии готовности к запуску.

## Best used for

Страница объясняет «Email-дайджест на n8n: письма, фильтры — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Схема workflow
- Фильтрация
- Prompt для дайджеста
- Формат результата
- Защита данных
- Архитектура production workflow
- Минимальная схема данных
- Проверка на реальных крайних случаях

## Source outline

# Email-дайджест на n8n: письма, фильтры, AI-суммаризация и отправка

Обновлено: 2026-05-29

Email-дайджест собирает письма за период, фильтрует шум, делает краткую выжимку и отправляет результат в Telegram, Slack или обратно на email. Это хороший рецепт для руководителя, поддержки, продаж и личной продуктивности.

## Схема workflow

- Schedule Trigger запускает дайджест утром или вечером.
- Gmail / IMAP node получает письма за период.
- IF / Filter убирает рассылки, спам и нерелевантные темы.
- OpenAI суммаризирует письма по категориям.
- Telegram / Email отправляет итоговый дайджест.

## Фильтрация

Не отправляйте в AI все письма подряд. Сначала ограничьте период, отправителей, labels и ключевые слова. Отдельно храните список доменов, которые нужно исключить: no-reply, уведомления сервисов, рекламные рассылки.

## Prompt для дайджеста

```
Сделай дайджест писем за день.
Сгруппируй по категориям: срочно, клиенты, финансы, прочее.
Для каждого пункта дай: отправитель, тема, 1 строка сути, рекомендуемое действие.
Не выдумывай факты, которых нет в письмах.
```

## Формат результата

- Блок | Что включить
- Срочное | Письма, требующие ответа сегодня
- Клиенты | Запросы, возражения, согласования
- Финансы | Счета, оплаты, документы
- Можно позже | Информационные письма без дедлайна

## Защита данных

- Не отправляйте в модель вложения и персональные данные без необходимости.
- Обрезайте длинные треды до последних релевантных сообщений.
- Добавьте ссылку на оригинальное письмо, если интерфейс это поддерживает.
- Логируйте только статус дайджеста и число обработанных писем.

## Архитектура production workflow

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

- Слой | Задача | Что логировать
- Trigger | получить событие от внешний сервис, данные и execution history | event_id, source, время получения
- Normalize | привести поля к единой схеме | id события или записи, source, created_at, status, payload_hash
- Validate | отсечь пустые, повторные и рискованные входы | причину отказа и исходный payload_hash
- Action | выполнить главное действие рецепта | id созданной/обновлённой записи
- Notify | сообщить человеку или системе результат | канал, статус, ссылка на execution

## Минимальная схема данных

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

- id события или записи
- source
- created_at
- status
- payload_hash
Если поля отличаются у разных источников, добавьте отдельную нормализационную ноду сразу после trigger. Это снижает количество выражений в последующих нодах и упрощает поддержку.

## Проверка на реальных крайних случаях

- пустой payload или форма без обязательного поля
- повторная доставка одного и того же события
- частичный успех: внешняя запись создана, но уведомление не отправилось
- медленный API или временный 429/5xx
- ручной повтор старого execution через неделю после первого запуска

## MVP и production-версия рецепта

Рецепт Email-дайджест на n8n: письма, фильтры, AI-суммаризация и отправка не должен конкурировать со справочником нод. Здесь важен готовый сценарий: какие ноды соединить, какие данные передать и как проверить бизнес-результат.

- Уровень | Что включить | Что пока не делать
- MVP | Webhook/Trigger, нормализация, основное действие, короткий ответ | сложные retry, multi-tenant логику, лишние ветки
- Production | idempotency, error workflow, лог статусов, ручная очередь, alert | хранить токены в тексте нод или логировать полный payload
- Scale | очередь, лимиты, batch processing, SLA-метрики | раздувать один workflow до нечитабельной схемы

### Как понять, что рецепт готов

- Есть один владелец процесса и понятный критерий успеха: лид создан, письмо отправлено, документ сохранён, задача закрыта.
- Повторный запуск с тем же payload не создаёт дубль.
- Ошибочный payload не теряется, а попадает в manual review или alert.
- Все внешние API вызываются через credentials, а не через токен в plain text.
- К рецепту привязан готовый шаблон в разделе workflow или указано, почему шаблон не нужен.

## Production-сценарий и проверка рецепта

Рецепт «Email-дайджест на n8n» стоит собирать в два прохода: сначала минимальный happy path, затем production-слой. В production-слое появляются dedupe, retry, error branch, audit trail и уведомление владельцу процесса, а не только красивые ноды на canvas.

Источник события для проверки: нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ. Сразу подготовьте три теста: обычный вход, повтор того же события и ошибку внешнего API.

- Слой | Что зафиксировать | Зачем
- Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам
- Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Email-дайджест на n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "request_id": "req_demo_001",
  "prompt_version": "2026-05-29",
  "input": "краткое нормализованное сообщение пользователя",
  "allowed_actions": ["read", "draft", "classify"],
  "forbidden_actions": ["send_without_review", "change_payment"],
  "expected_output": {
    "intent": "technical|support|sales|unknown",
    "confidence": 0.0,
    "needs_human_review": true,
    "sources": []
  }
}
```

### Критерий готовности

- рецепт проходит на тестовых данных и не создаёт дубли при повторном запуске
- ошибка внешнего сервиса уходит в отдельную ветку с понятным уведомлением
- результат можно найти по execution_id или external_id
- у workflow есть владелец, описание и ссылка на runbook

## Что читать дальше

Для AI-блока смотрите OpenAI , для расписания — Schedule Trigger , для условий — IF / Switch .

## Production-контекст и проверка внедрения

Материал «Email-дайджест на n8n: письма, фильтры, AI-суммаризация и отправка» стоит использовать не только как пример настройки, но и как мини-runbook для внедрения в реальный n8n. Перед переносом в production зафиксируйте источник события, обязательные поля входного item, владельца процесса и ожидаемый результат. Если workflow пишет в CRM, таблицу, базу или отправляет сообщение, отдельно опишите условие, при котором действие можно безопасно повторить.

Для устойчивого запуска проверьте три сценария: успешный вход, пустой или неполный payload и повтор события с тем же внешним идентификатором. Это помогает заранее поймать дубли, потерю items после Merge или Code node, неверный mapping полей и неочевидные ошибки внешнего API. Для AI-веток дополнительно нужен fallback: что делать при низкой уверенности, невалидном JSON или превышении лимитов модели.

### Чеклист перед публикацией workflow

- Добавьте тестовый payload без секретов и персональных данных.
- Проверьте retry, error branch, idempotency и ручной override.
- Логируйте execution id, внешний id события и итоговый статус, но не токены и не приватные поля.
- Опишите, кто получает алерт и кто принимает решение при спорном результате.
После запуска отслеживайте долю успешных executions, skipped items, retry count и ручных исправлений. Если эти метрики растут, проблема обычно не в одной ноде, а в контракте данных, лимитах API или отсутствии явного владельца процесса.

### Связанные материалы для углубления

- Все рецепты — открыть связанный материал для проверки контекста.
- Workflow JSON — открыть связанный материал для проверки контекста.
- Диагностика — открыть связанный материал для проверки контекста.
- Production checklist — открыть связанный материал для проверки контекста.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.