151 verkliga mejlsekvenser med dagen då varje mejl landade. Utforska dem, remixa en till ett automatiseringsutkast eller läs alla med kod via API:t och MCP.

De flesta mallgallerier visar ett mejl i taget. Det är den minst användbara enheten. Ett enskilt välkomstmejl visar inte tidpunkten eller sammanhanget runt det. Sekvensen ger det sammanhanget, även om du inte kan se på en sekvens om den har fungerat bra.
Därför sparade vi insamlade sekvenser. Ett flöde i Brew visar mejlen vi såg efter en registrering eller en prenumeration på ett nyhetsbrev, i ordning och med dagen då vart och ett landade. Insamlingen har sina begränsningar, så flödet kanske inte innehåller hela sekvensen. Vid lanseringen den 17 september innehöll galleriet 151 flöden. Siffrorna nedan beskriver den ögonblicksbilden från lanseringen; den aktuella katalogen kan ändras.
GET /v1/flows och MCP-verktyget list_flows returnerar samma poster, så en agent kan studera alla 151 sekvenser utan att en människa behöver klicka på något.emailId som du kan skicka direkt till create_email som referenceEmailId.Zapiers sekvens efter registrering består av åtta mejl under 10,7 dagar:
| Dag | Ämnesrad |
|---|---|
| 0 | Welcome aboard 👋 | Let's make some magic with AI |
| 1 | Why you should ditch spreadsheets for Tables |
| 2 | Build your first Zap workflow with Copilot ⚡ |
| 3 | What engineers are automating this week |
| 5 | Put AI to work for you |
| 9 | Go beyond workflows 🚀 |
| 10 | Stuck? Or need automation ideas? |
| 10,7 | Your Zapier trial ends in three days ⏲️ |
Läs dagarna, inte bara ämnesraderna. Fyra mejl landar fyra morgnar i rad, sedan växer uppehållet till två dagar och därefter till fyra. Mejlet ”Stuck?” kommer dag 10, och mejlet om att provperioden går ut följer sjutton timmar senare. Någon bestämde att det sista användbara före betalväggen är ett erbjudande om hjälp, och att de två mejlen nästan skulle nudda varandra.
Det kan du inte se på en skärmbild av ett enda mejl.
Flödesvyn öppnas på det första mejlet, som bara har en väntetid efter sig. Går du in i mitten, som i sekvensen från Ro ovan, syns uppehållet på båda sidor. Välkomstflödet från Ro har ett långsammare tempo än Zapiers, 12 mejl under 46,7 dagar, och uppehållen visar det innan du har läst en enda ämnesrad.

Varje steg har ämnesraden, förhandsvisningstexten, dagen då mejlet landade, väntetiden sedan förra utskicket, en kategori och en förhandsvisningsbild. Ber du om det får du också den renderade HTML-koden.
Samlingen har en sekvens per varumärke, så 151 flöden betyder 151 företag:

Det kompletterar galleriet med enskilda designer, som rymmer ytterligare 4 098 nyhetsbrev, 105 välkomstmejl och 68 kampanjmejl. Flödena är den del som visar ordningen.
Många tror att en remix är en kopia. Det är den inte.
Brew bygger automatiseringens graf först: din utlösare, sedan källflödets uppehåll som väntenoder och därefter en utskicksnod per steg. Den halvan är aritmetik, inte generering. Ingen ber en modell gissa att det fjärde mejlet går ut dag tre.

Väntenoderna visar 53 och 122 timmar eftersom det var så källvarumärket skickade, avrundat till närmaste timme. Ett uppehåll på hela dagar förblir hela dagar, och allt under en timme blir en timme. Bara mejlen genereras, och de genereras parallellt, vart och ett utifrån ditt varumärke. Dina färger, dina typsnitt, ditt tonläge, din produkt. Varje steg får också en brief som beskriver dess uppgift i sekvensen och vad som ligger före och efter, eftersom underagenterna som skriver mejlen inte kan se varandras arbete och annars skulle ta fram åtta mejl utan koppling till varandra, bara med ett gemensamt schema.
Du får ett utkast till en automatisering med tempot från en sekvens som ett riktigt företag redan har kört, och text som är din egen. Du måste fortfarande läsa den. Anpassningen till ditt varumärke är bra, men inte färdig.
Alla flöden finns tillgängliga via REST-API:t och via MCP, så en agent kan läsa samlingen direkt.
# First page, newest first
curl "https://brew.new/api/v1/flows" \
-H "Authorization: Bearer $BREW_API_KEY"
# One sequence, every step
curl "https://brew.new/api/v1/flows/zapier.com" \
-H "Authorization: Bearer $BREW_API_KEY"Filtrera på brand, category eller type (signup eller newsletter). Sortera på emails för sekvenserna med flest mejl, på span för dem som pågår under flest dagar eller på remixes för det som andra har tyckt var värt att kopiera. Skicka med semantic för att söka på vad en sekvens handlar om. Så hittar du ett återvinningsmejl inför slutet av en provperiod utan att veta vilket varumärke som har skrivit ett.
Samma läsning finns som verktyg och som resurs på MCP-servern för Brew:
list_flows # the list, same filters and sorts
get_flow { slug: "zapier.com" } # one sequence with every step
brew://flows # @-mentionable in a chat
REST och MCP läser samma publika katalog. Flöden gäller hela organisationen, så de här anropen tar inget varumärke. För att bläddra i listan skickar du det returnerade pagination.cursor som cursor i nästa anrop, tills värdet är null. Ett enskilt listanrop returnerar inte hela katalogen, men dess total räknar alla flöden som matchar frågan.
En agent kan granska sekvensen innan den väljer ett referensmejl.
Vilka registreringsflöden lägger en rabatt i det första mejlet, och vilka väntar tills provperioden nästan är slut? Vad skickar utvecklarverktyg dag två? Hur länge pågår välkomstsekvenser för nyhetsbrev innan de slutar? Hur många sekvenser inleds med en fråga i stället för en fördel? Med posterna kan en agent undersöka de frågorna genom att läsa steps[]. Analys av ämnesrader och innehåll kräver fortfarande tolkning; API:t har inte ett filter för varje fråga.
Det som gör det här till användbart referensmaterial är emailId på varje steg. Det är samma referens som mallgalleriet använder, och det är precis vad create_email tar emot som referenceEmailId. En agent läser alltså hela förloppet, väljer det steg som spelar roll och lämnar över just det mejlet till designverktyget:
get_flow { slug: "zapier.com" }
→ steps[4].emailId = "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q"
create_email {
referenceEmailId: "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q",
prompt: "day-5 activation email for our API product"
}
Studera förloppet, hämta det specifika mejlet, bygg din version. Ingen kopiering och inklistring däremellan.
Insamlingen sparar högst tolv mejl per flöde och klipper av resten, så emailCount: 12 betyder att tolv eller fler skickades, inte exakt tolv. Det gäller de 59 flödena ovan.
Renderade mejl är skrymmande. Ber du om HTML via MCP får du det första eller de två första stegen innan svaret är fullt, och resten kommer utan HTML. Sammanfattningen anger hur många som behölls. REST-slutpunkten har inget sådant tak, så läs flödet där när du vill ha HTML-koden för alla mejl: GET /v1/flows/zapier.com?include=html.
Öppna galleriet och läs tre sekvenser i din egen kategori innan du skriver något. Remixa sedan den vars tempo du skulle kunna försvara inför ditt eget team, och ändra det som inte passar.
Ska en agent använda det här är list_flows utan argument rätt första anrop. Det returnerar kort med slugs, och slugen är det enda som get_flow behöver för allt annat. Hela listan över fält finns i API-referensen.
Alla mejl som ett varumärke skickade efter en enda registrering eller prenumeration på ett nyhetsbrev, i ordning och med dagen då vart och ett landade, räknat från den händelsen. Ett flöde per varumärke, och flödets slug är varumärkets domän.
Nej. Brew kopierar strukturen, alltså antalet steg, ordningen och uppehållen, återgivna till närmaste timme. Varje mejl byggs sedan om utifrån ditt varumärke med källans design som referens, så resultatet får dina färger, dina typsnitt och ditt tonläge.
Läsning via REST kräver en API-nyckel med templates.read. MCP stöder OAuth eller en API-nyckel med lämplig åtkomst. Själva galleriet är publikt och kräver inget konto.
Upp till tolv. Insamlingen sparar de tolv första och klipper av resten, så ett flöde som visar tolv mejl kan ha pågått längre. 59 av de 151 publicerade flödena ligger vid det taket.
Ja, med include=html när du läser ett enskilt flöde. Via MCP får bara det första eller de två första stegen plats i ett svar, och sammanfattningen anger hur många som behölls. REST-slutpunkten returnerar HTML-koden för alla mejl.
