Průvodce pro týmy, které mají e-maily v kódu: sepiš je s programovacím agentem, přes MCP je dej na jedno plátno v Brew a pak je bezpečně převeď a vylepši.
E-maily v kódu jsou produktové e-maily definované ve tvém kódu a nasazované jako kterákoli jiná funkce. Zeptej se týmu postaveného na Resend a React Email, jaké e-maily produkt posílá, a nastane chvíle ticha. Uvítací e-mail je komponenta v emails/. Obnova hesla žije v administraci poskytovatele autentizace. E-mail o konci zkušební verze je řetězec v úloze v cronu. Účtenku posílá Stripe. A co posílá e-mail „chybíš nám“, si nepamatuje nikdo.
Každý e-mail šlo snadno nasadit, a tak celkový přehled nemá nikdo na starosti. My bychom to řešili v tomto pořadí: nejdřív viditelnost, pak migrace a nakonec vylepšení. Většinu práce zvládne programovací agent, kterého už používáš, když ho přes MCP připojíš k Brew.
import_email. Import je deterministický, nepoužívá AI a je zdarma.React Email a Resend udělaly z e-mailu pro vývojáře mnohem příjemnější práci: typované komponenty, kontrola v pull requestech. Cena za to se ukáže až později.
E-maily jsou rozházené. Komponenty, inline HTML v úloze na pozadí, šablony v administraci třetí strany, e-maily, které za tebe posílá jiná služba. Žádný soubor je neuvádí všechny.
Náhled není produkce. Náhledový server React Email ukáže jednu šablonu s jejími ukázkovými props, ne to, co skutečně dostal zákazník, a pro ostatní šablony neukáže nic.
Podívat se můžou jen vývojáři. Produktový tým, design i podpora by museli o spuštění projektu požádat vývojáře, takže to většinou nedělají.
Po spuštění už nikdo nic nekontroluje. Dva roky starý e-mail má pořád staré logo a tarif, který už neprodáváš. Nikdo si toho nevšimne, protože je nikdo nevidí pohromadě.
Cílem je jeden společný pohled na všechny e-maily. Nic z toho se nedotkne produkce.
Každá fáze je užitečná sama o sobě a po kterékoli z nich můžeš skončit.
MCP server Brew běží na https://brew.new/api/mcp a používá OAuth: přihlásíš se přes Brew a vybereš značku, ve které smí agent pracovat. V Claude Code:
claude mcp add --transport http brew "https://brew.new/api/mcp"Přidáním se server uloží jen do lokální konfigurace tohoto projektu. Aby byl dostupný ve všech projektech, přidej --scope user. Než začneš jeho nástroje používat, spusť claude mcp login brew, nebo otevři /mcp a ověř se u Brew.
Dokumentace k nastavení klientů má návody i pro Cursor a Codex. Klienti bez OAuth můžou použít API klíč pro konkrétní značku. Pak nech agenta zavolat get_brew_capabilities, aby si přečetl aktuální seznam nástrojů a nemusel hádat.
Požádej agenta o seznam:
Find every email this codebase sends. Search for provider calls
(resend.emails.send, postmark, sendgrid, nodemailer, SES), React Email
components and render() calls, and any email templates referenced from
config or a third-party dashboard.
For each email, record: a name, what triggers it, the file and line that
sends it, the template file, the provider, and the variables it uses.
Write the result as a table in EMAILS.md. List anything you could not
resolve under "Unknown" instead of guessing.Sekci „Unknown“ si nech. Potvrzovací e-maily z autentizace a účtenky ze Stripe nejsou volání ve tvém kódu, ale na seznam patří. Soubor EMAILS.md commitni. I když tady skončíš, máš seznam, který ještě včera neexistoval.
Nejlepším vstupem pro import je HTML, které tvůj kód už vytváří. Tenhle řetězec ti dá pomocná funkce render z React Email:
import { render } from 'react-email'
import WelcomeEmail from './emails/welcome'
const html = await render(
<WelcomeEmail firstName="Ana" planName="Pro" trialDays={14} />
)Starší projekty importují render z @react-email/render. Používej realistická testovací data, ne "test", protože e-maily bude kontrolovat tvůj tým. Nech agenta napsat skript, který každou šablonu vykreslí do souboru.
Brew umí s format: "jsx" importovat i přímo modul React Email: přečte ho staticky, aniž by ho spustil. Props se vyhodnotí na výchozí hodnoty nebo na PreviewProps, komponenty importované z jiných lokálních souborů se vynechají nebo odmítnou a await a podobné konstrukce import nepřijme. Pokud nejde o jeden soběstačný soubor, použij vykreslené HTML.
Pak každý vykreslený e-mail naimportuj přes import_email, s jedním groupName pro každou oblast produktu:
For each rendered email in ./email-renders, call import_email with
format "html", the title and subject line from EMAILS.md, and a
groupName by area: "Auth", "Onboarding", "Billing" or "Lifecycle".
Report the emailId for each one and any warnings in its assetReport.Vývojáři se oprávněně ptají, jestli import jejich e-maily přepíše. Nepřepíše:
assetReport vypíše ty, které se mu nepodařilo stáhnout.baseUrl slouží jen k doplnění relativních cest k obrázkům.Každá skupina dostane vlastní plátno. Otevři brew.new/emails/onboarding a uvidíš celou sekvenci vedle sebe, s přepínačem mezi desktopem a mobilem a s komentáři u každého návrhu. Odkazy na plátno fungují pro lidi přihlášené do tvého pracovního prostoru v Brew. Veřejný odkaz ke sdílení neexistuje, takže lidi, kteří mají e-maily zkontrolovat, pozvi.
Právě tady vyplavou problémy: dvě loga, nefunkční odkaz v tlačítku, tři patičky. Než začneš cokoli opravovat, spusť audit_email. Kontroluje odkazy, obrázky, soulad s předpisy, celkovou velikost při načtení, podporu v e-mailových klientech, přístupnost a texty. Kompletní audit stojí 5 kreditů. Nástroj přijímá uložené emailId i surové HTML, takže můžeš auditovat i e-maily, které ještě nejsou naimportované. Náš checklist kontroly před odesláním vysvětluje jednotlivé kontroly i jejich hranice.
Teď máš soupis, všechny e-maily na plátně a seznam problémů, a tvůj kód přitom pořád posílá všechno jako dřív.
Teď začne některé e-maily posílat Brew místo tvého kódu. Přesunout se nemusí každý e-mail a daný typ e-mailu vždy posílá jen jeden systém.
| Dnes v tvém kódu | V Brew |
|---|---|
resend.emails.send({ react: <WelcomeEmail /> }) |
Událost spouštěče a k ní publikovaná automatizace s jedním krokem Odeslání e-mailu |
| Props předávané komponentě | Pole payloadu spouštěče, použitá jako proměnné, např. {{ firstName | there }} nebo {{ trigger.planName }} |
Doména v from |
Ověřená odesílací doména v Brew |
| Tvoje tabulka uživatelů | Kontakty vytvořené přes REST API nebo integraci |
| Úloha v cronu, která posílá sekvenci | Automatizace s kroky Čekání, Filtr a Odeslání e-mailu |
Agent zavolá create_domain, aby získal záznamy DNS, a jakmile jsou aktivní, zavolá verify_domain. Domény vytvořené přes MCP a API jsou marketingové. Pro obnovu hesla a účtenky nastav v aplikaci Brew doménu s účelem Transakční: e-maily z ní nemají patičku s odhlášením a doručují se i odhlášeným kontaktům. Záznamy podrobně popisuje návod k ověření odesílací domény.
Přes MCP se kontakty dají aktualizovat, ale ne vytvářet. Vytvoř je z backendu přes POST /v1/contacts: endpoint vloží nebo aktualizuje (upsert) jeden kontakt či dávku až 1 000 kontaktů a vlastní pole vytvoří automaticky. Případně nahraj CSV v aplikaci. Aktivace spouštěče také vytvoří nebo aktualizuje kontakt ze svého payloadu. Importuj jen lidi, kteří souhlasili, že se jim budeš ozývat. Co Brew očekává, vysvětluje návod k přidávání kontaktů.
Snadno se to přehlédne: naimportovaný uvítací e-mail doslova říká „Hi Ana“. Každou testovací hodnotu nahraď proměnnou, třeba {{ firstName | there }}, kde text za svislou čarou je záložní hodnota. Použij editor Brew, nebo nech agenta spustit edit_email omezený jen na tyhle náhrady. Je to úprava pomocí AI, která spotřebovává kredity, takže zkontroluj náhled. Syntaxi najdeš v návodu k proměnným.
Agent vytvoří spouštěč přes save_trigger. Schéma payloadu musí obsahovat email příjemce. Dej spouštěči typované schéma (infer_payload_contract ho navrhne z ukázkového payloadu, set_trigger_contract ho uloží) a pak si ho stáhni přes get_trigger_contract ve formátu ts nebo zod, aby se tvůj backend a Brew shodly na podobě payloadu.
save_automation pak sestaví spouštěč a krok Odeslání e-mailu s daným e-mailem, doménou a předmětem. Automatizace zůstane konceptem, dokud ji nepublikuješ. dryRun ověří graf, test_automation pošle skutečnou kopii na tvou adresu a check_trigger potvrdí, že publikovaná automatizace naslouchá, ještě než produkce cokoli spustí.
Tohle je jediná změna v kódu tvé aplikace. Předtím, s Resend:
await resend.emails.send({
from: 'Acme <hello@acme.com>',
to: user.email,
subject: 'Welcome to Acme',
react: <WelcomeEmail firstName={user.firstName} planName={plan.name} />,
})Potom, s Brew:
const res = await fetch(
`https://brew.new/api/v1/automations/triggers/${process.env.BREW_WELCOME_TRIGGER_ID}/fire`,
{
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.BREW_API_KEY}`,
'Content-Type': 'application/json',
'Idempotency-Key': `welcome-${user.id}`,
},
body: JSON.stringify({
payload: { email: user.email, firstName: user.firstName, planName: plan.name },
}),
}
)
if (!res.ok) {
// 422 means the automation is still a draft; 400 means the payload failed the schema.
throw new Error(`Brew trigger failed: ${res.status} ${await res.text()}`)
}fetch se splní i tehdy, když server událost odmítne, takže kontroluj res.ok a nech systém, který zpracovává úlohy, zkusit to znovu, nebo spustit upozornění. Endpoint vrací 202, když událost přijme, a 422, pokud na spouštěč nenaslouchá žádná publikovaná automatizace.
Idempotency-Key sestav ze stabilního ID, třeba uživatele nebo objednávky. Opakovaný klíč vrátí původní běh, místo aby se e-mail poslal dvakrát, a pokud stejný klíč použiješ s jiným tělem požadavku, dostaneš 409 IDEMPOTENCY_CONFLICT. Brew uchovává klíč aktivace stejně dlouho jako záznam o přijetí události spouštěče, tedy 90 dní, ne 24 hodin jako mnoho jiných API. Ber klíče jako trvalé, jeden na každou akci. Klíč z časového razítka se při každém opakovaném pokusu změní a klíč, který o několik týdnů později použiješ pro jinou akci, může vrátit dřívější běh, místo aby se e-mail odeslal.
Produkční kód volá tento endpoint s API klíčem, ne přes MCP. Při připojení přes OAuth žádá MCP člověka o potvrzení ostrých rozesílek, aktivací spouštěčů a publikování: v chatu je to správně, v obsluze požadavku špatně. Jak práci rozdělit, popisuje průvodce MCP vs. REST.
EMAILS.md.Stejný postup používá i návod k přechodu z platformy Loops.
Potvrzovací e-maily a magic linky ze Supabase dál chodí ze Supabase. Integrace Supabase v Brew naslouchá událostem uživatelů, aby spouštěla automatizace, a e-maily Supabase Auth nenahrazuje. Položkovou fakturu, která se při odeslání sestavuje ze složitých dat, může být také jednodušší nechat v kódu, takže si nejdřív ověř, co tvoje proměnné potřebují. Naimportované kopie si nech na plátně, aby tyhle e-maily zůstaly na očích.
Proveď audit celé sady. Spusť audit_email na celou skupinu, oprav chyby a před velkými rozesílkami ho spusť znovu.
Zkontroluj skutečné klienty. test_email_rendering vrátí snímky obrazovky z konkrétních e-mailových klientů a zařízení včetně tmavého režimu, za 10 kreditů za běh. create_inbox_placement_test pošle skutečnou kopii do testovacích schránek a ohlásí, kde skončila, také za 10 kreditů.
Sjednoť celou sadu. Nesrovnalosti oprav v editoru, nebo nech agenta přes edit_email provést jednu změnu, třeba novou patičku, v celé skupině.
Čti výsledky. get_email_analytics vykazuje rozesílky a zapojení. list_insights vrací zjištění, která Brew ve tvém účtu odhalil, každé i s metrikami, o které se opírá.
Testuj varianty záměrně. Vytvoř varianty na plátně a kontakty rozděluj krokem Rozdělení podle chování, třeba podle toho, jestli klikli. Brew za tebe vítěze náhodného rozdělení nevybírá, takže porovnání variant je na tobě.
Udržuj nové e-maily na očích. Přidej do AGENTS.md nebo podobného souboru řádek: nové produktové e-maily se vytvářejí v Brew, spouštějí se přes spouštěč a ve stejném pull requestu se přidávají do EMAILS.md.
Ano. import_email přijímá vykreslené HTML, MJML, uloženou zprávu .eml nebo modul React Email. Nejspolehlivější je vykreslené HTML, protože modul se čte staticky: props dostanou své výchozí nebo ukázkové hodnoty a komponenty importované z jiných lokálních souborů se vynechají.
Ne. Integrace, import ani export pro Resend neexistují. Naimportuješ HTML, které vykreslí tvůj kód, a pokud přejdeš na Brew, tvůj kód místo volání Resend aktivuje spouštěč v Brew.
Ne. MCP používej z programovacího agenta na nastavení, importy, audity a testování. Produkční kód by měl volat REST API s API klíčem, protože u připojení přes OAuth žádá MCP člověka o potvrzení ostrých rozesílek a aktivací spouštěčů.
Import převede e-mail na upravitelný návrh v Brew a pro doručení si ponechá původní zdrojové HTML. Odstraní skripty, iframy, formuláře a obsluhy událostí, zneškodní stávající sledovací pixely a veřejné obrázky přenese na vlastní hosting. Než e-mail začneš posílat z Brew, zkontroluj každý na plátně v zobrazení pro desktop i mobil.
