# MCP kontra REST-API för e-postmarknadsföring: vilket arbetssätt ska du välja?

Kanonisk URL: https://brew.new/sv/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use
Författare: Thomas Park
Publicerad: 2026-09-23
Uppdaterad: 2026-09-29

En utvecklare i ditt team ansluter e-postplattformen till Claude och skriver ett utkast till nästa veckas kampanj i ett chattfönster. Nästa morgon frågar någon om välkomstmejlet vid registrering kunde köras på samma sätt, via assistenten. Plattformens dokumentation listar en MCP-server och ett REST-API sida vid sida.

De flesta e-postplattformar som stöder agenter erbjuder nu de här två vägarna in. En MCP-server låter en AI-assistent anropa plattformens verktyg i en konversation. Ett REST-API exponerar åtgärder som din kod kan anropa direkt. Ofta når de samma slutpunkter under ytan, så valet handlar om vem som gör jobbet och när.

Använd MCP när en person arbetar via en assistent, och REST-API:t när din produkt behöver skicka mejl utan att någon tittar på. Till slut använder de flesta team båda.

## Det viktigaste i korthet

- MCP är till för interaktivt arbete som kräver omdöme: att skriva ett kampanjutkast, bygga en målgrupp eller fråga varför ett utskick gick sämre än väntat.
- REST-API:t är till för det som körs i produktion: att skicka en händelse till en utlösare när en användare registrerar sig, synka kontakter eller skicka kvitton.
- Ett CLI ligger mittemellan. Det går att skripta precis som API:t, och kodagenter kan läsa det.
- I MCP-servern för Brew kräver anslutningar via OAuth eller för hela organisationen bekräftelse av skarpa utskick. Klienter med en varumärkesspecifik API-nyckel behöver egna regler för godkännande. Din API-kod måste själv stå för granskning, idempotens och nya försök.

## Vad de är

MCP, Model Context Protocol, är en öppen standard för att göra verktyg tillgängliga för AI-klienter som Claude, ChatGPT och Cursor. Klienten läser en lista med verktyg, med beskrivningar och scheman, och väljer sedan vilket den ska anropa utifrån det du ber om. Servern för Brew finns på `https://brew.new/api/mcp` och stöder OAuth, så du loggar in och väljer ett varumärke i stället för att hantera nycklar.

Ett REST-API är en uppsättning HTTP-slutpunkter som din kod anropar. Brew publicerar en OpenAPI-specifikation, ett TypeScript-SDK och en [guide för agenter](https://brew.new/api/v1/llms.txt) i ren text till sitt API. Varje anrop har med sig en API-nyckel, och din kod bestämmer vad som ska anropas och när.

Andra leverantörer följer samma mönster. MCP-servern från Customer.io kapslar in API:t i [separata verktyg för läsning, skrivning och radering](https://docs.customer.io/ai/mcp/get-started/). Brevo genererar sina MCP-verktyg från sin [OpenAPI-specifikation](https://developers.brevo.com/docs/mcp-protocol).

## En jämförelse sida vid sida

| | MCP | REST-API |
| --- | --- | --- |
| Vem styr | En person, via en assistent | Din kod |
| Typiska uppgifter | Skriva och revidera mejl, bygga målgrupper, schemalägga en kampanj, läsa statistik | Skicka händelser till utlösare, skapa eller uppdatera kontakter, skicka transaktionsmejl, hämta status för utskick |
| Autentisering | Inloggning med OAuth, eller en API-nyckel för klienter utan OAuth | API-nyckel, avgränsad till ett varumärke eller en organisation |
| Säkerhet | Brew pausar skarpa utskick för bekräftelse vid anslutningar via OAuth eller för hela organisationen | Din kod bestämmer; använd idempotensnycklar och egna granskningssteg |
| Felhantering | Assistenten läser felet och försöker igen eller frågar dig | Du förgrenar på stabila felkoder och gör nya försök med ökande väntetid |
| Svarsstorlek | Begränsas av assistentens kontextfönster | Begränsas bara av pagineringen |
| Passar bäst när | Uppgiften kräver omdöme eller iteration | Uppgiften måste köras likadant varje gång |

## När MCP är rätt val

Använd MCP när arbetet är en konversation:

- Kampanjproduktion. ”Skriv oktobers produktuppdatering utifrån den här ändringsloggen, skicka ett test till mig och schemalägg den till tisdag kl. 9.” Assistenten anropar `create_email`, `edit_email`, `send_email` med `test: true` och sedan `send_email` med `scheduledAt`, och väntar därefter på ditt godkännande.
- Frågor om målgrupper. ”Hur många Pro-kunder registrerade sig före juli och öppnade något förra månaden?” Assistenten kombinerar `search_contacts`, uppslag av fält och `create_audience`.
- Analys. ”Vilken automatisering har sämst klickfrekvens, och vad har ändrats?” Assistenten läser `get_email_analytics` och automatiseringarnas resultat.
- Engångskonfiguration. Att skapa en utlösare och en automatisering en gång, med en person som granskar varje steg.

I Brew använder mejl som genereras via MCP samma varumärkesdokument som mejl som genereras i appen. [Inlägget om MCP-servern i Brew](/sv/blog/brew-mcp) går igenom hur du konfigurerar klienten.

Svar via MCP måste få plats i assistentens kontext. [Inlägget om flöden](/sv/blog/email-flows) påpekar att om du ber om fullständig HTML via MCP får du bara det första eller de två första stegen i en lång sekvens, medan REST-vägen returnerar HTML-koden för alla mejl.

## När REST-API:t är rätt val

Använd API:t när e-post är en del av din produkt:

- Händelseutlösare. När en användare registrerar sig anropar din backend `POST /v1/automations/triggers/{triggerEventId}/fire` med användarens e-postadress och fält. Den publicerade automatiseringen sköter resten.
- Transaktionsmejl. Kvitton och lösenordsåterställningar utlöses på samma sätt, via en automatisering på en domän med transaktionellt syfte. Läs mer om [transaktionsmejl](/sv/blog/transactional-emails).
- Kontaktsynk. `POST /v1/contacts` skapar eller uppdaterar upp till 1 000 kontakter per anrop.
- Övervakning. `GET /v1/sends/{sendId}` returnerar status och statistik till en översikt eller ett larm.

På slutpunkter som stöder det återanvänder du samma `Idempotency-Key` och samma innehåll i anropet när du gör nya försök inom det dokumenterade fönstret på 24 timmar (för händelser som skickas till en utlösare känns dubbletter igen på nyckeln i 90 dagar). Använd en annan nyckel för en annan logisk åtgärd, och läs slutpunktens kontrakt innan du utgår från att en skrivning omfattas. Headers för anropsgränser talar om när du behöver sakta ned. API:ets felsvar innehåller en `code`, till exempel `CONSENT_REQUIRED`, som du kan förgrena på. Hantera nätverksfel separat. [API-guiden](https://brew.new/api/v1/llms.txt) för Brew beskriver allt detta.

## Var CLI:t passar in

Kodagenter i en terminal klarar sig ofta bättre med ett CLI än med något av de två alternativen. [CLI:t](https://docs.brew.new/api-reference/cli/agents) för Brew returnerar API-svaret som en enda JSON-rad när det inte är kopplat till en terminal, och använder avslutskoder som en agent kan agera på. Kod 4 betyder att bekräftelse krävs, och CLI:t skriver då ut exakt det kommando som ska köras om med `--yes` efter godkännandet. Det genererar också typade nyttolastkontrakt med `brew-cli types`, vilket håller din backends anrop till utlösaren i takt med utlösarens schema.

## Ett kombinerat arbetsflöde

Så här kan ett SaaS-team dela upp arbetet:

1. I Cursor eller Claude använder en utvecklare MCP för att skapa utlösaren `user_signed_up` och en välkomstautomatisering, testar den med `test_automation` och publicerar den.
2. Backenden skickar en händelse till utlösaren via REST-API:t vid varje registrering, med en idempotensnyckel som bygger på användar-ID:t.
3. Varje månad ber en marknadsförare Claude via MCP att skriva ett utkast till produktuppdateringen och schemalägga den.
4. Ett schemalagt jobb i applikationen kontrollerar aktuell aktiverings- eller faktureringsstatus innan det skickar en separat påminnelsehändelse för kontakter som uppfyller villkoren. Att bara synka kontaktfält uppdaterar inte den ursprungliga händelsens nyttolast i ett flöde som redan körs.

I steg 1 och 3 granskar en person assistentens arbete. Steg 2 och 4 körs vid varje registrering eller varje natt utan att någon tittar på.

## Vanliga frågor

### Är MCP långsammare eller mindre tillförlitligt än API:t?

MCP lägger till en assistent mellan dig och slutpunkten, så en förfrågan tar fler steg, och assistenten kan välja fel verktyg. Det fungerar bra för interaktivt arbete men är fel val för en registreringshändelse som måste utlösas varje gång.

### Vilket är säkrast?

I Brew kräver anslutningar via OAuth eller för hela organisationen bekräftelse av skarpa utskick. I klienter med en varumärkesspecifik API-nyckel konfigurerar du egna regler för godkännande. Med API:t skyddar du nycklarna i miljövariabler, använder varumärkesspecifika nycklar där du kan och lägger till idempotensnycklar i varje skrivning som görs om.

### Kan en agent i min egen produkt använda API:t som verktyg?

Ja. [Guiden för agentintegrationer](https://docs.brew.new/integrations/ai-agents/use-brew-with-ai-agents) från Brew beskriver hur du kopplar API-slutpunkter som verktyg för funktionsanrop, där SDK:t sköter autentisering och nya försök.

## Nästa steg

Vill du prova båda halvorna ansluter du [MCP-servern](/sv/mcp) i din assistent för kampanjarbetet och skapar en API-nyckel för utlösaren som din backend ska skicka händelser till.