// stack · schnittstelle
Brevo — bis 2023 unter dem Namen Sendinblue unterwegs — ist eine E-Mail-Plattform, die zwei Dinge in einem Dienst erledigt: Newsletter an eine Liste und transaktionale Mails an eine einzelne Person. Für siteway ist das der interessante Teil: Die Website sammelt nicht nur Adressen ein, sie verschickt auch ihre eigenen Bestätigungen darüber. Diese Seite beschreibt, wie wir das anbinden.
// definition
früher sendinblue
Brevo ist eine Cloud-Plattform für E-Mail-Marketing und transaktionalen Versand. Das Unternehmen wurde 2012 in Paris gegründet und hieß bis zur Umbenennung im Jahr 2023 Sendinblue — der alte Name taucht in Bestandsprojekten und älteren Anleitungen deshalb noch häufig auf. Gemeint ist derselbe Dienst.
Dass der Anbieter seinen Sitz in Frankreich hat, ist für deutsche Auftraggeber kein Nebensatz. Wer Kontaktdaten in ein Werkzeug gibt, muss im Verzeichnis der Verarbeitungstätigkeiten benennen, wer sie verarbeitet und wo. Brevo gibt in seiner eigenen Dokumentation an, die Daten innerhalb der Europäischen Union zu speichern. Das ersetzt keine eigene Prüfung, aber es verkürzt die Diskussion.
Technisch interessant wird Brevo an der Schnittstelle. Es gibt eine öffentlich dokumentierte REST-API in Version 3 unter api.brevo.com/v3, mit Endpunkten für Kontakte, Listen, eigene Kontaktfelder, Double-Opt-in, transaktionale E-Mails mit Vorlagen und Webhooks für Zustellereignisse. Damit lässt sich beides bauen: die Newsletter-Anmeldung auf der Website und der Mailversand, den die Website selbst auslöst.
// praxis
eigenes formular · schlüssel serverseitig
Am Anfang steht eine Entscheidung, die man später nicht mehr billig korrigiert: Das Anmeldeformular gehört der Website. Es steht im Layout der Seite, es benutzt dieselben Feldtypen, dieselben Fehlermeldungen und dieselbe Tastaturbedienung wie jedes andere Formular des Projekts. Damit bleibt die Anmeldung ein Teil der Seite statt eines Fremdkörpers — und sie bleibt bedienbar, wenn ein fremdes Skript einmal nicht lädt. Wie wir Formulare grundsätzlich bauen, steht bei den Formularstrecken.
Abgeschickt wird an einen eigenen Endpunkt auf dem Server der Website, nicht direkt an Brevo. Dieser Endpunkt hält den API-Schlüssel, prüft die Eingaben, wehrt Massen-Einträge ab und entscheidet, welche Felder überhaupt weitergereicht werden. Ein Schlüssel im Frontend wäre jedem Besucher zugänglich, der die Entwicklerwerkzeuge öffnet — das ist kein theoretisches Risiko, sondern der häufigste Fehler bei schnell zusammengesteckten Anbindungen.
Von dort geht der Kontakt in eine Liste. Brevo kennt dafür Listen und Ordner sowie eigene Kontaktattribute, die vorher im Konto angelegt sein müssen — Vorname, Herkunftsformular, Interessengebiet. Wir legen dieses Feldmodell fest, bevor gebaut wird, sonst entsteht eine Liste, in der später niemand mehr segmentieren kann. Für die Einwilligung nutzen wir den dokumentierten Double-Opt-in-Weg: Der Kontakt wird über den dafür vorgesehenen Endpunkt angelegt, Brevo verschickt die Bestätigungsmail aus einer Vorlage, und erst der Klick auf den Link macht ihn in der Liste aktiv.
Der zweite Strang ist der transaktionale Versand. Jede Website verschickt Mails, auch ohne Newsletter: die Bestätigung an den Absender eines Kontaktformulars, die Benachrichtigung ans Team, die Terminzusage, der Link zum Zurücksetzen eines Passworts. Diese Mails über Brevo statt über den Webserver zu schicken, ist der Punkt, an dem die Anbindung technisch wirklich etwas bringt: Der Versand läuft über eine Infrastruktur, die für Zustellung gebaut ist, und die Website erfährt über Ereignismeldungen, was aus der Mail geworden ist. Voraussetzung ist eine sauber eingerichtete Absender-Domain — was dafür im DNS stehen muss, prüfen wir im DNS- & E-Mail-Audit.
Bleibt das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die API nicht, darf der Besucher das nicht ausbaden. Die Anmeldung wird zwischengespeichert, der Versuch protokolliert und mit Abstand wiederholt; eine wichtige Benachrichtigung geht zusätzlich auf dem direkten Weg raus. Genauso planbar behandeln wir das Ende: Abmeldung über den Link in jeder Mail und Löschung auf Anfrage — beides über die Schnittstelle ausführbar und in der Anbindung von vornherein vorgesehen, statt später von Hand nachgezogen.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Brevo — Endpunkte, Parameter und Ereignisnamen im Original. Feste Zahlen zu Kontingenten nennen wir hier bewusst nicht: Brevo staffelt sie nach Konto und beschreibt sie als Anfragen pro Sekunde und pro Stunde. Für die Anbindung heißt das ohnehin dasselbe wie bei jeder fremden API — bündeln, nicht in Schleifen feuern, Antworten auswerten.
// d-01zugang
Alle Aufrufe gehen an api.brevo.com/v3, Anfragen und Antworten sind JSON. Authentifiziert wird über einen Schlüssel im Header api-key. Listenabfragen lassen sich mit limit und offset blättern; die Antworten tragen laut Dokumentation Angaben zum verbleibenden Kontingent mit.
zweck: authentifizierung
// d-02kontakte
Kontakte liegen unter /v3/contacts, Listen unter /v3/contacts/lists, Ordner unter /v3/contacts/folders. Eigene Kontaktfelder legt man unter /v3/contacts/attributes an — sie müssen im Konto existieren, bevor die Website sie mitschickt. Bestehende Kontakte kommen über /v3/contacts/lists/{listId}/contacts/add in eine Liste.
zweck: datenmodell
// d-03einwilligung
Für die bestätigte Anmeldung gibt es einen eigenen Endpunkt: /v3/contacts/doubleOptinConfirmation. Übergeben werden die E-Mail-Adresse, die Ziel-Listen als includeListIds, die Vorlage der Bestätigungsmail als templateId und die redirectionUrl für die Landung nach dem Klick. Attribute lassen sich mitgeben.
zweck: bestätigte anmeldung
// d-04transaktional
Der Versand aus der Website heraus läuft über /v3/smtp/email. Entweder mit sender, to, subject und htmlContent direkt im Aufruf — oder über eine im Konto gepflegte Vorlage per templateId, deren Platzhalter mit params gefüllt werden. Anhänge sind per URL oder als Base64 dokumentiert.
zweck: versand aus der seite
// d-05ereignisse
Unter /v3/webhooks meldet Brevo Ereignisse an eine Adresse der Website. Transaktional dokumentiert sind unter anderem delivered, hardBounce, softBounce, blocked, spam, deferred, opened, uniqueOpened, click und unsubscribed; auf der Marketing-Seite zusätzlich listAddition, contactUpdated und contactDeleted. Die Zahl der Webhooks ist begrenzt.
zweck: rückmeldung
// d-06zustellbarkeit
Bevor eine Mail rausgeht, wird die Domain authentifiziert. Brevo dokumentiert dafür einen Brevo-Code als Nachweis, einen DKIM-Eintrag für die Signatur und einen DMARC-Eintrag. Ein eigener SPF-Eintrag ist laut Brevo dafür nicht nötig, weil die technische Absenderdomain bei Brevo liegt — DMARC trägt über DKIM.
Der Marketing-Strang ist der bekannte: Adressen sammeln, in Listen führen, mit Attributen anreichern, später gezielt an ein Segment senden. Hier arbeitet die Website als Zulieferer. Sie hat einen Job — die Einwilligung sauber einzuholen und den Kontakt vollständig zu übergeben, inklusive der Information, aus welchem Formular er stammt. Alles Weitere passiert danach im Werkzeug, und das ist auch richtig so.
Der transaktionale Strang dreht die Richtung um: Hier ist die Website der Absender. Sie löst eine Mail an genau eine Person aus, weil etwas passiert ist. Der Vorteil gegenüber dem Versand vom eigenen Webserver liegt in der Zustellbarkeit — der Weg führt über eine Infrastruktur mit authentifizierter Domain, und über Webhooks kommt zurück, ob die Mail zugestellt wurde oder abgeprallt ist. Damit wird aus einem blinden Fleck ein Betriebszustand, den man sehen kann.
Beide Stränge teilen sich Konto, Schlüssel und Vorlagen — die Trennung verläuft in den Endpunkten und in den Ereignissen. Praktisch heißt das: Ein einmal gebauter serverseitiger Zugang trägt beide Aufgaben, und die Vorlagen für Bestätigungsmails pflegt die Redaktion an derselben Stelle wie die Newsletter. Was die Website daraus als buchbaren Baustein macht, beschreiben wir unter Newsletter & E-Mail.
// integration
drei systeme · ein muster
Der Weg zur Anbindung ist in jedem System derselbe, und er ist bewusst systemunabhängig gedacht: Auf der Seite steht ein eigenes Formular im Design der Website — nicht ein eingebettetes Fremdformular, das mit eigenen Schriften, eigenen Farben und eigenen Fehlermeldungen daherkommt. Abgeschickt wird an einen serverseitigen Endpunkt, der den Schlüssel hält, die Eingaben prüft und den Kontakt anschließend in die vorgesehene Liste schreibt, angereichert um die Attribute, die im Feldmodell verabredet sind. Die Einwilligung läuft über Double-Opt-in: Brevo verschickt die Bestätigungsmail aus einer Vorlage, der Klick auf den Link aktiviert den Kontakt, und die Person landet danach auf einer Seite der Website, die wir bestimmen.
Daneben steht der zweite Strang, den man leicht übersieht: der transaktionale Versand aus der Website heraus. Bestätigungen an Absender von Formularen, Benachrichtigungen an das Team, Termin- und Statusmails gehen dann nicht mehr über die Mailfunktion des Webhostings, sondern über denselben Zugang wie der Newsletter — mit Vorlagen, die die Redaktion pflegen kann, und mit Rückmeldungen darüber, ob die Mail angekommen ist. Für das CMS ändert sich dadurch wenig: Es liefert das Formular, den Endpunkt und die Konfiguration. Unterschiedlich ist nur, wo diese drei Dinge im jeweiligen System zu Hause sind.
// cms-01typo3
In TYPO3 bauen wir die Anbindung als eigene Extension. Das Anmeldeformular wird ein Plugin-Element, das die Redaktion im Seitenbaum dort platziert, wo es hingehört — im Footer, in einer Spalte, auf einer eigenen Seite. Der Absendevorgang läuft über eine eigene Route mit Middleware: Sie nimmt die Daten entgegen, validiert serverseitig und ruft Brevo auf; dieselbe Mechanik nimmt später die eingehenden Ereignismeldungen an. Die Ausgabe kommt aus Fluid-Templates, damit Formular, Fehlerfall und Dankeseite im Layout des Projekts bleiben. Der API-Schlüssel und die Listen-Kennungen liegen in der Extension-Konfiguration, nicht im Template. Transaktionale Mails der Website laufen über denselben Weg, mit Vorlagen aus dem Brevo-Konto.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin statt als Theme-Code — so überlebt sie einen Theme-Wechsel und lässt sich sauber aktualisieren. Der Absendevorgang bekommt eine eigene REST-Route, die serverseitig validiert, gegen Massen-Einträge absichert und den Kontakt an Brevo übergibt; eine zweite Route nimmt die Ereignismeldungen entgegen. Der API-Schlüssel steht in der wp-config.php oder in einer Umgebungsvariablen, nie in der Datenbank und nie im Frontend. Fürs Ausspielen kommen Template-Dateien und Blocks für den Editor dazu, damit die Redaktion das Formular selbst platziert. Bestätigungsmails der Website gehen über denselben Zugang statt über die Mailfunktion des Servers.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diese Anbindung besonders geradlinig. Eine Route plus Controller nimmt das abgeschickte Formular entgegen, validiert mit den Bordmitteln des Frameworks und spricht Brevo an; eine zweite Route nimmt die Ereignismeldungen an und legt sie zur Verarbeitung in die Queue. Das Formularmodell selbst beschreibt ein Blueprint — welche Felder es gibt, welche Pflicht sind, wie sie im Control Panel heißen. Der API-Schlüssel steht in der .env-Datei und wird über die Konfiguration gelesen, nicht direkt im Code. Gerendert wird über Antlers oder Blade, sodass Formular, Fehlermeldungen und Bestätigungsseite Teil des Templates bleiben.
// datenschutz
kein nebenschauplatz
Eine E-Mail-Adresse identifiziert eine Person. Sobald sie mit Name, Interesse oder Herkunft verknüpft wird, entsteht ein Profil — und zwar in dem Moment, in dem jemand auf „Anmelden“ klickt. Deshalb bauen wir die Anbindung so, dass die Datenschutzfragen nicht am Ende geklärt werden, sondern im Feldmodell stehen.
Die Einwilligung wird dokumentiert. Das Double-Opt-in ist dafür der etablierte Weg: Der Klick auf den Bestätigungslink belegt, dass die Person Zugriff auf das Postfach hat. Wir halten fest, wann die Anmeldung einging, aus welchem Formular sie kam und welcher Hinweistext dabei zu sehen war. Ohne diese drei Angaben ist der schönste Verteiler im Streitfall eine Behauptung.
Es wird nur erhoben, was gebraucht wird. Pflicht ist die E-Mail-Adresse, alles Weitere muss sich begründen lassen. Ein Attribut, das niemand für die Segmentierung nutzt, hat im Formular nichts verloren. Und weil Brevo die Daten im Auftrag verarbeitet, gehört ein Vertrag zur Auftragsverarbeitung nach Artikel 28 DSGVO dazu — genauso wie beim Hoster. In der Datenschutzerklärung stehen anschließend der Dienstleister, der Zweck, die Rechtsgrundlage und die Löschfrist.
Das Ende gehört zum Anfang. Jede Mail trägt den Abmeldelink, jede Abmeldung wirkt sofort, und eine Löschanfrage lässt sich über die Schnittstelle ausführen, statt sie von Hand durch Oberflächen zu klicken. Was wir hier beschreiben, ist die technische Umsetzung und keine Rechtsberatung — die rechtliche Bewertung des konkreten Falls gehört in fachkundige Hände. Wie wir Websites grundsätzlich sparsam und mit sauberen Security-Headern ausliefern, steht im Stack unter Sicherheit & Datenschutz.
// faq
Brevo ist eine Cloud-Plattform für E-Mail-Marketing und transaktionalen Versand — beides in einem Dienst und über dieselbe Schnittstelle erreichbar. Das Unternehmen wurde 2012 in Paris gegründet und trug bis zur Umbenennung im Jahr 2023 den Namen Sendinblue. Für die Website zählt vor allem die dokumentierte REST-API in Version 3 unter api.brevo.com: Kontakte, Listen, Attribute, Double-Opt-in, transaktionale E-Mails mit Vorlagen und Webhooks für Zustellereignisse sind darüber ansprechbar.
Marketing meint den Versand an eine Liste: Ein Newsletter geht an viele Empfänger, die vorher eingewilligt haben. Transaktional meint den Versand an genau eine Person als Reaktion auf eine Handlung — die Bestätigung eines abgeschickten Formulars, ein Link zum Zurücksetzen eines Passworts, eine Benachrichtigung ans Team. Brevo trennt das technisch sauber: Kontakte und Listen liegen unter den Contacts-Endpunkten, der transaktionale Versand läuft über einen eigenen Endpunkt mit eigenen Vorlagen und eigenen Webhook-Ereignissen. Eine Website nutzt in der Regel beides.
Die dokumentierte Version 3 liegt unter api.brevo.com/v3. Authentifiziert wird über einen Schlüssel, der als Header api-key mitgeschickt wird; Anfragen und Antworten sind JSON. Kontakte liegen unter /v3/contacts, Listen unter /v3/contacts/lists, eigene Kontaktfelder unter /v3/contacts/attributes. Der transaktionale Versand läuft über /v3/smtp/email, Zustellereignisse meldet Brevo über Webhooks unter /v3/webhooks. Listenabfragen lassen sich mit limit und offset blättern, und die Antworten tragen laut Dokumentation Angaben zum verbleibenden Anfragekontingent mit.
Über einen eigenen Endpunkt. Das Formular auf der Website schickt die Adresse an unseren Server, dieser ruft /v3/contacts/doubleOptinConfirmation auf und übergibt die E-Mail-Adresse, die Ziel-Listen als includeListIds, die Vorlage der Bestätigungsmail als templateId und die redirectionUrl, auf der die Person nach dem Klick landet. Brevo verschickt daraufhin die Bestätigungsmail; erst der Klick auf den Link macht den Kontakt in der Liste aktiv. Attribute wie Vorname oder Herkunft des Formulars lassen sich mitgeben, sofern sie im Konto angelegt sind.
Weil der eigene Webserver dafür oft der schlechtere Absender ist. Formularbestätigungen, die direkt vom Webhosting rausgehen, landen leicht im Spam-Ordner oder werden gar nicht erst angenommen — und niemand merkt es, weil die Website ja eine Erfolgsmeldung angezeigt hat. Über den transaktionalen Versand von Brevo geht dieselbe Mail über eine Infrastruktur raus, die für Zustellung gebaut ist, mit authentifizierter Absender-Domain und mit Ereignismeldungen, die zurück auf die Website kommen. Der Versand wird damit nachvollziehbar statt vermutet.
Die Domain, aus der die Mails kommen, muss bei Brevo authentifiziert werden. Brevo dokumentiert dafür drei DNS-Einträge: einen Brevo-Code als Nachweis für die Domain, einen DKIM-Eintrag für die Signatur und einen DMARC-Eintrag. Ein eigener SPF-Eintrag ist laut Brevo für diese Authentifizierung nicht nötig, weil die technische Absenderdomain auf Seiten von Brevo liegt; für DMARC trägt dann die DKIM-Signatur. Ob die vorhandenen Einträge zusammenpassen und ob der normale Postfach-Versand des Unternehmens dabei heil bleibt, prüfen wir vorher in einem eigenen Audit.
Über Webhooks. Brevo ruft eine Adresse auf der Website auf, sobald ein Ereignis eintritt; angelegt und verwaltet werden diese Aufrufe unter /v3/webhooks. Für den transaktionalen Versand sind unter anderem delivered, hardBounce, softBounce, blocked, spam, deferred, opened, uniqueOpened, click und unsubscribed dokumentiert, auf der Marketing-Seite kommen Ereignisse wie listAddition, contactUpdated und contactDeleted dazu. Die Zahl der Webhooks ist laut Dokumentation begrenzt, deshalb sammeln wir die Ereignisse auf einem Endpunkt, statt für jeden Fall einen eigenen anzulegen. Dieser Endpunkt nimmt die Meldung an, legt sie ab und arbeitet sie im Hintergrund ab.
Ja, in allen dreien — und zwar so, dass das Formular im Design der Website steht und der Schlüssel auf dem Server bleibt. In TYPO3 bauen wir eine eigene Extension: Das Formular ist ein Plugin-Element im Seitenbaum, eine eigene Route mit Middleware nimmt den Absendevorgang und die Webhook-Meldungen entgegen, gerendert wird über Fluid, der Schlüssel liegt in der Extension-Konfiguration. In WordPress entsteht ein eigenes Plugin statt Theme-Code, mit einer eigenen REST-Route, dem Schlüssel in der wp-config.php oder in einer Umgebungsvariablen und Template-Dateien beziehungsweise Blocks fürs Frontend. In Statamic liegt Laravel darunter: Route plus Controller, ein Blueprint für das Formularmodell, der Schlüssel in der .env-Datei, Ausgabe über Antlers oder Blade.
// womit das zusammenhängt
dienste, technik & leistung
// stack · schnittstelle
Der Newsletter-Dienst aus Deutschland und wie seine Schnittstelle an ein Anmeldeformular im Seitendesign kommt.
zur technik →
// stack · schnittstelle
Der bekannteste Dienst im Feld — andere Mechanik, dieselbe Frage: Wie kommt der Kontakt sauber und bestätigt in die Liste?
zur technik →
// stack · schnittstelle
Der schlanke Anbieter aus Freiburg, wenn es vor allem um Newsletter geht — und um kurze Wege beim Datenschutz.
zur technik →
// komponente · buchen
Die Technik hier, der Baustein dort: Anmeldeformular, Double-Opt-in, Segmentierung und Consent-Protokoll als buchbare Komponente.
zur komponente →
// audit · zustellbarkeit
Bevor die erste Mail rausgeht: Absender-Domain, DKIM, DMARC und der Rest der Einträge, an denen Zustellbarkeit hängt.
zum audit →
// leistung · buchen
Analyse, Feldmodell, Umsetzung, Monitoring und Betrieb der Anbindung — von der ersten Zeile bis zum laufenden Betrieb.
zur leistung →
// Brevo an deine Website anbinden?
Projekt anfragen