AI‑асистент, який відповідає на листи, надсилає вітальні повідомлення й розсилки, звучить як класичний кейс для інтеграції штучного інтелекту в повсякденну роботу з поштою. У новому проєкті на базі Next.js та Anthropic Claude саме таку систему збирають навколо одного ключового елемента — сервісу Postmark, який бере на себе все, що стосується надсилання, отримання та шаблонізації листів.
Цей матеріал зосереджується на тому, як саме налаштовано Postmark: від серверного токена й message streams до inbound‑вебхука, підпису відправника та шаблонів вітальних листів. Це окрема, самодостатня інструкція з побудови email‑інфраструктури для AI‑асистента, незалежно від того, чи знайомі ви з іншими частинами проєкту.
Postmark як єдиний центр поштової логіки
У проєкті Postmark використовується як універсальний поштовий бекенд: через нього проходять усі листи, пов’язані з асистентом — вхідні, вихідні, автоматичні відповіді та вітальні повідомлення.
Замість того щоб розподіляти функції між кількома сервісами (окремо для SMTP, окремо для вебхуків, окремо для шаблонів), уся логіка зосереджена в одному інструменті. Це спрощує архітектуру: Next.js‑бекенд спілкується лише з Postmark, а вже Postmark відповідає за доставку, приймання та форматування листів.
Ключовий момент — проєкт одразу працює з Postmark у «живому» режимі, а не в sandbox. Це означає, що всі операції відбуваються з реальними адресами й реальними доставками, а не в тестовому середовищі. Для навчального проєкту це нетипове, але показове рішення: замість абстрактної демо‑логіки розробник одразу отримує бойову конфігурацію, яку можна адаптувати під власні потреби.
Щоб підключити Postmark до застосунку, спершу створюється сервер у Postmark‑акаунті, після чого з нього береться API‑токен. У дашборді це робиться через розділ Servers → API tokens. Саме цей токен стає основним ключем доступу до всіх поштових операцій із боку Next.js‑бекенда.
У проєкті токен зберігається в окремому файлі середовища як змінна POSTMARK_SERVER_TOKEN. Поруч із ним у тому ж env‑файлі оголошуються й інші критичні параметри:
ANTHROPIC_API_KEY— для AI‑відповідей (хоча логіка роботи з Claude виходить за межі цієї статті, важливо, що ключ зберігається разом із поштовими налаштуваннями);SENDER_EMAIL— адреса, з якої асистент надсилатиме листи й на яку приходитимуть відповіді;POSTMARK_WELCOME_TEMPLATE_ALIAS— псевдонім шаблону вітального листа в Postmark.
Такий підхід до конфігурації дозволяє чітко відокремити секрети й змінні середовища від коду, а також легко змінювати поштову інфраструктуру без редагування логіки застосунку.
Message streams: розділення транзакційних, масових та вхідних листів
Одна з найважливіших концепцій Postmark, яку використовує проєкт, — message streams. Це логічні «потоки» листів, що дозволяють розділяти різні типи поштового трафіку за призначенням і правилами обробки.
У конфігурації AI‑асистента застосовуються три типи потоків.
Перший — transactional stream. У ньому проходять листи, що надсилаються як реакція на конкретну подію: відповідь асистента на вхідний запит, вітальний лист після першого звернення, будь‑які інші індивідуальні повідомлення, які не є масовою розсилкою. Для подібних листів критично важлива швидка й надійна доставка, а також чітка історія взаємодії з кожним контактом.
Другий — broadcast stream. Він використовується для масових розсилок: наприклад, коли власник асистента хоче надіслати всім контактам промокод, оголошення чи інше повідомлення. У проєкті передбачено можливість формувати такі розсилки через дашборд, де зібрані всі контакти, що коли‑небудь взаємодіяли з асистентом. Розділення broadcast‑потоку від транзакційного важливе не лише з точки зору організації, а й для репутації домену та керування відписками.
Третій — inbound stream. Саме він робить можливим сценарій, коли асистент «прокидається» від звичайного листа. Inbound‑потік приймає всі вхідні повідомлення, що надходять на спеціальну адресу, і далі передає їх на бекенд через вебхук. У Postmark для цього створюється inbound message stream, після чого в його налаштуваннях вказується URL вебхука на стороні Next.js‑застосунку.
Цей вебхук стає точкою входу для всієї логіки AI‑асистента: він отримує дані про вхідний лист, передає їх далі в систему (зокрема, в AI‑модель), а потім ініціює відправлення відповіді через відповідний транзакційний потік Postmark. Таким чином, message streams дозволяють чітко розвести три різні сценарії: індивідуальні відповіді, масові розсилки та приймання листів.
Inbound‑вебхук: як асистент «чує» вхідні листи
Щоб AI‑асистент міг реагувати на звичайні email‑повідомлення, Postmark inbound stream підключається до бекенда через вебхук. У цьому проєкті бекенд реалізовано на Next.js, і саме там створюється HTTP‑ендпоінт, який приймає POST‑запити від Postmark.
Схема роботи виглядає так. Користувач надсилає листа на адресу, прив’язану до inbound‑потоку Postmark. Postmark приймає цей лист, перетворює його на структуровані дані (з темою, тілом, адресами відправника й одержувача, вкладеннями тощо) і надсилає їх як запит на вказаний webhook‑URL. Next.js‑ендпоінт отримує цей запит, розбирає payload і далі вирішує, що робити: створити новий контакт, зафіксувати повідомлення в базі, викликати AI‑модель для генерації відповіді, ініціювати відправлення вітального листа, якщо це перше звернення.
Важливо, що вся ця логіка побудована навколо Postmark як єдиного шлюзу. Бекенд не працює з «сирим» SMTP, не приймає листи напряму, не обробляє низькорівневі протоколи. Усе, що йому потрібно, — коректно обробити HTTP‑запит від Postmark і сформувати відповідь у вигляді нового листа, який знову ж таки надсилається через Postmark‑SDK.
Така архітектура спрощує як розробку, так і подальшу підтримку. Вебхук стає єдиною точкою інтеграції між поштовим світом і AI‑логікою, а всі складнощі, пов’язані з доставкою, форматами листів і чергами, залишаються на боці Postmark.
Підпис відправника: від особистої адреси до продакшен‑домену
Щоб листи від AI‑асистента виглядали як нормальна кореспонденція, а не як анонімні системні повідомлення, у Postmark налаштовується так званий sender signature — підпис відправника. Це підтверджена адреса, від імені якої сервіс має право надсилати листи.
У прикладі використовується особиста адреса на домені techwithtim.net. Вона проходить верифікацію в Postmark і далі використовується як значення для змінної середовища SENDER_EMAIL. Саме ця адреса з’являється в полі From у всіх листах асистента, а також може слугувати адресою для відповіді (Reply‑To), якщо потрібно зберегти єдину точку контакту.
Для невеликих проєктів або навчальних сценаріїв такого підпису цілком достатньо. Однак у туторіалі окремо наголошується: якщо йдеться про високі обсяги розсилок або продакшен‑сервіс, варто піти далі й верифікувати весь домен у Postmark. Це передбачає налаштування DNS‑записів (SPF, DKIM та інших), що суттєво покращує доставлюваність листів і знижує ризик потрапляння в спам.
Таким чином, проєкт демонструє два рівні підготовки інфраструктури. Перший — швидкий старт із підтвердженою адресою, коли достатньо просто мати робочий email на власному домені. Другий — продакшен‑рівень, де до гри вступають DNS‑налаштування, репутація домену й більш тонке керування поштовими потоками. Обидва варіанти інтегруються в застосунок через одну й ту саму змінну SENDER_EMAIL, що дозволяє легко масштабувати рішення без змін у коді.
Шаблони й вітальні листи: як Postmark спрощує контент
Окремий акцент у проєкті зроблено на шаблонах листів у Postmark. Замість того щоб формувати HTML‑контент у коді Next.js, вітальний лист створюється як окремий шаблон у Postmark‑інтерфейсі. Це дає одразу кілька переваг.
По‑перше, контентом можна керувати без зміни коду. Текст, верстку, стилі вітального листа можна редагувати прямо в Postmark, не торкаючись репозиторію й не запускаючи деплой. Це особливо зручно, коли над продуктом працюють не лише розробники, а й маркетингова чи контент‑команда.
По‑друге, шаблони в Postmark мають власні ідентифікатори й псевдоніми. У цьому проєкті для вітального листа створюється окремий шаблон, якому присвоюється alias welcome. Саме цей псевдонім потім зберігається в змінній середовища POSTMARK_WELCOME_TEMPLATE_ALIAS. У коді застосунку достатньо звернутися до цієї змінної, щоб викликати потрібний шаблон, не «зашиваючи» конкретну назву чи ID в логіку.
По‑третє, шаблони добре поєднуються з транзакційною природою листів асистента. Коли користувач уперше надсилає листа на адресу асистента, система фіксує, що це новий контакт, і тригерить вітальний шаблон. У результаті користувач отримує два листи: перший — вітальний, другий — уже з відповіддю AI‑моделі на його запит. Обидва листи надсилаються через Postmark, але формуються по‑різному: вітальний — через шаблон, відповідь — динамічно на основі контенту.
Важливо, що alias welcome — не просто умовна назва, а конкретне значення, яке використовується в конфігурації. У туторіалі прямо зазначено, що саме цей псевдонім вказується в env‑файлі, щоб застосунок міг однозначно ідентифікувати потрібний шаблон. Якщо в майбутньому знадобиться змінити шаблон або додати нові, достатньо оновити alias у Postmark та/або змінну середовища, не торкаючись бізнес‑логіки.
Чому live‑режим і продумана конфігурація мають значення
Рішення налаштовувати Postmark‑сервер одразу в live‑режимі, а не в sandbox, задає певний тон усьому проєкту. Це не просто демо, яке працює лише в умовному «лабораторному» середовищі. Система з перших кроків орієнтована на реальні сценарії: справжні адреси, реальні вхідні листи, реальні відповіді.
У такій конфігурації особливо важливими стають:
коректне зберігання токенів і ключів у змінних середовища, щоб уникнути витоків;
розділення message streams для транзакційних, масових і вхідних листів, щоб не змішувати різні типи трафіку;
налаштування sender signature й, за потреби, верифікація домену для кращої доставлюваності;
використання шаблонів із чіткими alias‑ами, щоб контентом можна було керувати незалежно від коду.
У сукупності це перетворює Postmark на повноцінний поштовий шар інфраструктури AI‑асистента. Next.js‑бекенд зосереджується на бізнес‑логіці та інтеграції з AI, тоді як Postmark відповідає за все, що пов’язано з доставкою, прийманням і оформленням листів.
Висновок: Postmark як фундамент для «розумної» пошти
AI‑асистент, який працює через email, — це не лише про модель штучного інтелекту. Без надійної поштової інфраструктури та продуманої інтеграції з сервісом на кшталт Postmark такий проєкт швидко впирається в технічні обмеження: від проблем із доставкою до складнощів із обробкою вхідних листів.
У розглянутому проєкті Postmark виступає саме тим фундаментом, на якому будується вся взаємодія з користувачем. Серверний токен із розділу Servers → API tokens, live‑режим замість sandbox, розділені message streams, inbound‑вебхук у Next.js, підтверджений sender signature та шаблон вітального листа з alias welcome, винесений у змінну POSTMARK_WELCOME_TEMPLATE_ALIAS, — це не просто набір налаштувань. Це цілісна стратегія, яка дозволяє AI‑асистенту працювати як повноцінний поштовий сервіс, а не як лабораторний експеримент.
Для розробників, які планують будувати власні AI‑сервіси навколо email, цей підхід може стати практичною дорожньою картою: від перших кроків із Postmark до продакшен‑рівня з високою доставлюваністю та гнучким керуванням контентом.