Den e-mail-API, jeg ville have, men ikke kunne købe

I slutningen af 2024 byggede jeg et sideprojekt der havde brug for tre ting fra sit email-lag. Det skulle sende transaktional mail - kvitteringer, password resets, det sædvanlige. Det skulle sende et nu og da marketing broadcast - et nyhedsbrev, en launch annoncering. Og det skulle modtage inbound mail så kunder kunne svare på support tråde og appen kunne parse svaret tilbage til et ticket.

Jeg søgte efter den email-API der gjorde alle tre. Jeg fandt i stedet en stack.

Resend til transaktional, fordi Resend i øjeblikket er den cleanest landing i det nye crop og TypeScript clienten er virkelig en glæde. Mailchimp til broadcasts, fordi nogen på teamet havde brugt det før og subscriber management var i det mindste bekendt. Lidt duct tape der involverede Postmark's inbound parsing og en custom webhook handler, fordi det var den ene bit ingen andre virkelig ville tale om. Tre kontrakter. Tre suppression lists der ikke talte til hinanden. Tre sæt analytics der definerede "delivered" lidt forskelligt.

Det virkede. Det var også den anden-værste arkitektur-beslutning jeg havde taget det kvartal.

Jeg brugte en weekend på at kigge på hvad det ville tage at konsolidere. Svaret, på tværs af alle leverandører jeg evaluerede, var det samme: vælg den der gør dit vigtigste ekstremt godt, accept at du fastgør de to andre med webhooks, og ikke kigger på det igen. Det er et forsvarligt svar når dit vigtigste klart er det vigtigste. Det er ikke et forsvarligt svar når de tre workloads er nogenlunde lige vægt, hvilket er den situation de fleste små teams jeg kender faktisk lever i.

Så jeg byggede poststack. Det er den email-API jeg ville bruge. Et produkt, en API key, en regning, en suppression list, en contact graph.

Dette er indlægget om hvad det betyder i praksis - og, mere interessant, om de fire beslutninger jeg nægtede at give efter på.

Hvad "en email-API til alt" faktisk køber dig#

Pitchen er let at misforstå. Det lyder som en feature checklist: poststack gør sending og broadcasts og inbound og workflows, se hvor mange bokse der er markeret. Det er sandt, og det er ikke pointen.

Pointen er hvad der stopper med at ske når du kollapser seamene.

En kontakt der afmelder sig dit nyhedsbrev skal ikke hånd-synces ind i din transaktional leverandørs suppression list. Et svar på en transaktional tråd behøver ikke at blive rutet gennem en separat inbound parsing leverandør og sys tilbage til den oprindelige kontaktpost af en skrøbelig worker du skrev på en fredag. En workflow der triggers af en "order placed" event behøver ikke vide hvilken provider der sendte kvitteringen - det er en implementation detail et lag ned.

Når seamene forsvinder, mængden af glue code i din applikation der eksisterer bare for at holde tre leverandører enige med hinanden forsvinder med dem. I et af mine projekter var det glue layer omkring 600 linjer TypeScript og en Postgres tabel. Efter migration til poststack var det 0 linjer og 0 tabeller, fordi integrationen ejede alt det.

Det er hele produkttesen. Alt andet - REST, SMTP, templating, broadcasts, workflows, contacts, segments, inbound, webhooks, tracking, test mode - er hvad der falder ud af at tage tesen alvorligt.

De fire ting jeg nægtede at skibe uden#

En overraskende mængde af at bygge et produkt er at beslutte hvad ikke der skal skippes i version et. Disse fire bits var dog ikke til forhandling.

En end-to-end typed SDK

Ikke "vi genererede en TypeScript fil fra vores OpenAPI spec og håbede på det bedste". TypeScript clienten var en del af hvordan API'et kom til at blive designet. Endpoints der ville føles kejtet som SDK calls blev omformet før de skibede. Errors er typed unions, ikke stringly-typed status codes. Request og response bodies deler samme schemas som serveren, valideret af Zod på begge ender.

Grunden til at jeg holdt ved med dette er mundant: de fleste developer-facing email produkter i 2026 skiberer stadig "TypeScript support" som på nærmere eftersyn er en genereret types.d.ts fil der skiberes sammen med JavaScript. Det er det bare minimum. En rigtig SDK er API-design-driven. Det koster mere at vedligeholde og det producerer en meningsfyldt bedre integration experience.

En test mode der faktisk er transparent

Pass en header på en request og senden simuleres end-to-end. Webhooks fyrer. Tracking events emitter. Adresser bliver valideret. Templates render. Intet forlader platformen, og intet bliver factureret.

Frasen "test mode" optræder i de fleste leverandørers docs. Implementationen varierer. Nogle test modes stub out delivery men bypass validering. Nogle bypass webhooks. Nogle annonceres som en feature og viser sig på eftersyn at være "brug en sandbox API key på en anden account". Jeg ville have den version hvor din CI kører mod den rigtige API surface, og det eneste der er anderledes er om mailen faktisk forlader bygningen.

Deliverability arbejde ingen vil tale om

SPF, DKIM, DMARC, return-path setup. Reverse DNS. Den kedelige authentication stack der bestemmer om din email lander i inbox eller spam.

Nogle leverandører - især Postmark - er gold-standard på denne dimension og guide dig gennem hvert skridt. Andre antager du har en deliverability engineer ansat og provide en dokumentations side. poststack's domain-verification flow tager Postmark tilgangen: hver påkrævet record vises, kopieres, verificeres inline, og forklares på klart sprog. Første gang du sætter en sending domain op på poststack skulle være den sidste gang du behøver læse en RFC om email authentication.

En workflows primitive der ikke er en Zapier klon

Jeg gik frem og tilbage på denne i en måned. Fristelsen når du bygger en "marketing automation suite" er at putte et drag-and-drop canvas i dashboard med tres forskellige node types og kalde det dagen. De fleste teams vil ikke det. De fleste teams vil "når denne event sker, send denne email, medmindre denne betingelse er sand" - sammensat nok til at udtrykke deres use case, simpel nok til at læse på tyve sekunder.

poststack's workflows er bevidst tættere på "event trigger en funktion med branches" end "drag ikonet på canvas". Du kan udtrykke de fleste almindelige patterns i tre eller fire nodes. Hvis du har brug for en 200-trin customer-journey orchestration, er det det forkerte værktøj, og det er helt fint - det er et forskelligt produkt.

Hvad poststack ikke er (og hvor Resend eller Postmark er det bedre valg)#

Et par framings jeg hellere vil have du får fra mig end arbejde ud på den hårde måde.

Ikke den billigste hvis din eneste operation er "user tilmelder sig → send welcome email" og du aldrig vil have brug for broadcasts, inbound, workflows, eller en contact graph. Hvis det er dig, vil Resend eller Postmark på et starter tier være helt fint, og jeg ville anbefale dem uden ego om sagen. poststack tesen er konsolidering; hvis der er intet at konsolidere, virker matematikken ikke i din fordel.

Ikke en enterprise marketing automation suite. Ingen 200-trin journey builder. Ingen predictive-send AI. Ingen native A/B test orchestrator med statistical-significance gating. Workflow primitiven er lille med vilje.

Ikke en CDP. Contacts har custom properties, segments har regler, men det foregiver ikke at være Segment eller RudderStack. Hvis du har et rigtigt customer-data-platform problem, skal du bruge en rigtig CDP og stream events ind i poststack derfra.

Hvor det kører, og hvor der skal ses næste#

poststack kører på hoststack - min egen European PaaS - for den obvious-in-retrospect grund at jeg ville have min email infrastruktur til at leve inden for samme jurisdiktion som mine kunders data. Den hoststack indlæg på denne blog dækker den beslutning mere dybt. Hvis du giver om EU data residency, betyder begge halve af stacken, ikke bare en.

Produktet selv, fuld API reference, SDK, og pricing lever alle på poststack.dev. Transaktional + marketing combo på en enkel contact graph er det bit jeg ville starte din evaluering med - det er integrationen som andre leverandører split på tværs af to produkter, og seam-collapse besparelserne viser sig derfra først. Inbound + webhooks er det næst bedste sted at kigge, især hvis du nogensinde ville have "svar på denne email og vi parser det tilbage til appen" og endte med at skrive dit eget.

Hvis du har brugt et år på at sy tre leverandører sammen for at få en usabel email stack, ville jeg elske at have den samtale om det seamene du vedligeholder faktisk er load-bearing - eller om, som mine var, de bare er dyre vaner.