// stack · schnittstelle
rapidmail ist ein Newsletter-Dienst aus Deutschland — Server und Verarbeitung im Inland, Support auf Deutsch, dokumentierte REST-API. Für siteway heißt das: Die Newsletter-Anmeldung bleibt ein eigenes Formular auf der eigenen Domain, und der Server dahinter spricht mit der Schnittstelle. Diese Seite beschreibt, wie diese Anbindung technisch aussieht — vom Anmeldeformular über das Double-Opt-in bis zur Abmeldung.
// definition
rapidmail ist ein Newsletter-Dienst aus Deutschland, entwickelt von einem Unternehmen mit Sitz in Freiburg im Breisgau. Im Browser werden Empfängerlisten gepflegt, Mailings gebaut und versendet, Ergebnisse ausgewertet. Die Zielgruppe sind kleine und mittlere Unternehmen, Vereine, Verbände und Redaktionen — also alle, die eine eigene Liste aufbauen wollen, ohne dafür ein Marketing-Team zu beschäftigen.
Was den Dienst für deutsche Auftraggeber interessant macht, steht in der eigenen Auskunft des Anbieters: alle Daten auf Servern in Deutschland, keine Weitergabe an Dritte, Übertragung mit 256-Bit-SSL, ein nach ISO 27001 zertifiziertes Rechenzentrum und der Auftragsverarbeitungs-Vertrag nach EU-DSGVO online im Kundenkonto. Wer beim Thema Datenverarbeitung kurze Wege braucht, landet damit schnell hier.
Für die Website zählt eine zweite Sache: rapidmail dokumentiert eine REST-API in Version 3.0 unter apiv3.emailsys.net, mit Ressourcen für Mailings, Empfängerlisten, Empfänger, Blacklist und API-Benutzer. Damit lässt sich eine Anmeldung von der eigenen Seite aus sauber in die richtige Liste schreiben, statt Besucher auf ein fremdes Formular zu schicken.
Ob rapidmail für ein Projekt der passende Dienst ist, klären wir vorher und nicht per Rangliste. CleverReach, Brevo und Mailchimp beschreiben wir im Stack jeweils auf einer eigenen Seite — die Mechanik der Anbindung ähnelt sich, die Unterschiede liegen in Funktionsumfang, Preismodell und dem Ort der Verarbeitung.
// praxis
eigenes formular · server dahinter
Die erste Entscheidung fällt beim Formular: Es gehört auf die eigene Domain, im Design der Website. Kein eingebettetes Fremdformular, kein Skript aus dem Rechenzentrum eines Dienstleisters im Browser der Besucher. Das Anmeldefeld ist Teil der Seite — mit derselben Typografie, denselben Fehlermeldungen, derselben Tastaturbedienung und denselben Kontrasten wie jedes andere Formular. Wie wir Formulare grundsätzlich bauen, steht bei Formularstrecken.
Dahinter liegt ein serverseitiger Endpunkt. Er nimmt die Eingaben entgegen, prüft sie und ruft erst dann die API auf. Geprüft wird das Übliche und das Unbequeme: Pflichtfelder, Format der Adresse, das Häkchen für die Einwilligung, ein Schutz gegen automatisierte Eintragungen und die Frage, ob dieselbe Adresse gerade im Sekundentakt eingetragen wird. Die Zugangsdaten für rapidmail liegen ausschließlich auf dem Server — nie im JavaScript, nie im HTML, nie in einem öffentlichen Repository.
Dann folgt der Eintrag in die Empfängerliste. Welche Liste das ist, hängt am Kontext: ein Newsletter für alle, eine Liste je Standort, eine je Interessengebiet. Neben der Adresse gehen nur die Felder mit, die der Newsletter wirklich braucht — Anrede und Vorname für die Ansprache, ein Extrafeld für die Segmentierung, mehr nicht. Und weil aus einer Anmeldung später eine Zuordnung werden soll, halten wir fest, über welches Formular und welche Seite sie kam.
Das Double-Opt-in trägt der Dienst, nicht die Website. rapidmail verschickt die Bestätigungsmail und macht die Adresse erst nach dem Klick zu einem aktiven Empfänger. Die Website legt niemanden direkt als bestätigt an. Das ist keine Bequemlichkeit, sondern der Kern der Sache: Der Nachweis der Einwilligung entsteht genau in diesem Schritt.
Und dann das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die API nicht, sieht der Absender keine kryptische Meldung, sondern einen verständlichen Hinweis; der Versuch wird protokolliert und mit Abstand wiederholt, damit keine Anmeldung still verschwindet. Erfolg und Fehler bekommen jeweils eine eigene, ehrliche Rückmeldung. Die buchbare Leistung dahinter ist die Komponente Newsletter & E-Mail, die technische Arbeit an der Schnittstelle beschreibt Schnittstellenentwicklung.
Nach deutschem Recht braucht eine Newsletter-Anmeldung eine nachweisbare Einwilligung. Technisch bildet das Double-Opt-in genau diesen Nachweis ab, und zwar als Kette mit vier Gliedern. Erstens: Jemand trägt seine Adresse in das Formular auf der Website ein und bestätigt die Einwilligung. Zweitens: Der Server der Website legt die Adresse über die API in der Empfängerliste an — noch nicht als bestätigten Empfänger.
Drittens: rapidmail verschickt die Bestätigungsmail an genau diese Adresse. Viertens: Erst der Klick auf den Link darin macht aus dem Eintrag einen aktiven Empfänger. Weil der Klick aus dem Postfach kommt, ist damit belegt, dass die Einwilligung tatsächlich von der Person hinter dieser Adresse stammt und nicht von jemandem, der eine fremde Adresse in ein Formular getippt hat.
Für die Website folgt daraus eine klare Regel, die wir nicht verhandeln: Sie legt niemanden direkt als bestätigt an. Sie sagt nach dem Absenden ehrlich, was jetzt passiert — Bitte bestätige die Anmeldung in deinem Postfach — und die Dankeseite erklärt, was zu tun ist, wenn die Mail nicht ankommt. Alles andere wäre bequemer und würde genau den Nachweis kosten, um den es geht.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von rapidmail und dem Hilfecenter des Anbieters — Basis-URL, Authentifizierung, Ressourcen und Grenzwerte im Original. Die vollständige Feldliste je Ressource steht in der Entwickler-Dokumentation und wird im Projekt gegen den konkreten Zugang geprüft, statt hier geraten zu werden.
// d-01zugang
Die Basis ist apiv3.emailsys.net, erreichbar ausschließlich über HTTPS. Authentifiziert wird per HTTP Basic Authentication mit einem API-Benutzer, den der Kunde in seinem rapidmail-Konto im Bereich API anlegt. Die Website bekommt einen eigenen Zugang — nicht den des Marketings.
zweck: authentifizierung
// d-02listen
Empfängerlisten sind eine eigene Ressource der Schnittstelle: abrufen, anlegen, aktualisieren, löschen, dazu Aktivitätsstatistiken. Auf der Website entscheidet der Kontext, in welche Liste eine Anmeldung geht — ein Newsletter für alle, eine Liste je Standort oder je Thema.
zweck: zielliste
// d-03empfänger
Ein Empfänger wird über die Ressource der Empfänger angelegt, mit der Zielliste und der E-Mail-Adresse als Kern und optionalen Angaben wie Vorname, Nachname und Anrede. Dieselbe Ressource kennt Abruf, Aktualisierung, Löschung und einen Import für ganze Listen.
zweck: anmeldung schreiben
// d-04einwilligung
Beim Anlegen eines Empfängers ist die Option send_activationmail dokumentiert — damit verschickt rapidmail die Bestätigungsmail. Der Anbieter beschreibt das Double-Opt-in als den Weg, der bei ihm automatisch angewendet wird. Der Klick im Postfach macht den Eintrag aktiv, nicht der Aufruf von der Website.
zweck: double-opt-in
// d-05segmente
Neben der Adresse kennt eine Liste laut Hilfecenter Standardfelder wie Vorname, Nachname, Geschlecht, Titel, Postleitzahl und eine eigene Referenz. Darüber hinaus stehen bis zu zehn Extrafelder bereit, dazu Stichworte für die Segmentierung. Das Formular fragt trotzdem nur ab, was gebraucht wird.
zweck: segmentierung
// d-06format & last
Gearbeitet wird mit JSON; Accept und Content-Type stehen laut Dokumentation auf application/json, Sammlungen antworten im HAL-Format mit Links für die Blätterung. Für die Last nennt die Dokumentation eine Grenze: maximal zehn Anfragen pro Sekunde, darüber kommt Statuscode 503 zurück.
zweck: json · 10 req/s
Aus der Schnittstelle wird kein Schaltplan, sondern ein Anmeldefeld, das man gern benutzt. Es steht dort, wo Menschen ohnehin lesen: unter dem Artikel, im Footer, auf einer eigenen Newsletter-Seite, gelegentlich als Feld neben einem Download. Beschriftung, Fehlermeldung und Bestätigungstext sind Teil des Entwurfs und nicht das, was ein fremdes System zufällig ausgibt.
Dazu gehören die Zustände, die ein Formular kennen muss: Absenden läuft, Anmeldung angenommen, bitte im Postfach bestätigen, Adresse bereits eingetragen, technischer Fehler. Jeder dieser Fälle bekommt einen eigenen Text und eine für Screenreader nachvollziehbare Meldung. Ein Formular, das im Fehlerfall schweigt, verliert Anmeldungen — und niemand merkt es.
Und schließlich die Anschlüsse: die Dankeseite nach dem Absenden, der Hinweis auf die Bestätigungsmail, der Verweis auf die Datenschutzerklärung direkt am Formular sowie die Möglichkeit, sich abzumelden, ohne suchen zu müssen. Wo mehrere Formulare auf dieselbe Liste zeigen, sorgt ein Extrafeld dafür, dass später nachvollziehbar bleibt, woher eine Anmeldung kam.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er ist bewusst systemunabhängig gedacht. Auf der Seite steht ein eigenes Anmeldeformular im Design der Website — dieselbe Typografie, dieselben Abstände, dieselbe Tastaturbedienung wie überall sonst. Es sendet an einen serverseitigen Endpunkt der eigenen Domain. Dieser Endpunkt hält die Zugangsdaten für rapidmail, prüft die Eingaben und trägt die Adresse dann über die API in die richtige Empfängerliste ein. Das Double-Opt-in übernimmt der Dienst: Er verschickt die Bestätigungsmail, und erst der Klick darin macht den Eintrag zu einem aktiven Empfänger. Zurück an den Absender geht eine klare Rückmeldung — angenommen, bitte im Postfach bestätigen, oder ein verständlicher Hinweis, wenn etwas schiefging.
Was sich zwischen den Systemen unterscheidet, sind die Bordmittel: wie das Formular in die Seite kommt, wo die Route liegt, in welcher Datei die Zugangsdaten stehen und womit gerendert wird. Deshalb bauen wir die Anbindung in jedem CMS selbst, mit dessen eigenen Mitteln, statt sie als Fremdkörper anzuflanschen. Das hat einen praktischen Grund: Was mit den Mitteln des Systems gebaut ist, überlebt Updates, lässt sich von der Redaktion an der gewohnten Stelle platzieren und bleibt nachvollziehbar, wenn Jahre später jemand anderes hineinschaut.
// cms-01typo3
In TYPO3 entsteht die Anbindung als eigene Extension. Das Anmeldeformular wird ein Plugin-Element, das die Redaktion auf jeder Seite platzieren kann — im Footer, unter dem Artikel, auf einer eigenen Newsletter-Seite. Der Endpunkt liegt als serverseitige Route mit passender Middleware in derselben Extension: Sie nimmt das Formular entgegen, prüft die Eingaben, ruft die API und gibt das Ergebnis zurück. Die Zugangsdaten stehen in der Extension-Konfiguration und damit außerhalb des Frontends. Gerendert wird mit Fluid, also mit denselben Templates wie der Rest der Seite; Beschriftungen und Meldungen kommen aus den Sprachdateien und lassen sich für mehrsprachige Auftritte übersetzen.
// cms-02wordpress
In WordPress bauen wir die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie erhalten, wenn das Theme wechselt oder überarbeitet wird. Eine eigene REST-Route nimmt die Anmeldung entgegen, prüft sie serverseitig und ruft die API auf; die Zugangsdaten liegen in der wp-config.php oder in einer Umgebungsvariablen des Servers und nie im Frontend. Fürs Ausspielen kommen Template-Dateien und Blocks für den Editor dazu, damit die Redaktion das Anmeldefeld dort einsetzt, wo es hingehört. Rückmeldungen und Fehlertexte sind übersetzbar und folgen dem Markup der übrigen Formulare.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Weg besonders geradlinig. Eine Route plus Controller nimmt das Formular entgegen; die Prüfung der Eingaben übernimmt die Validierung des Frameworks, der Aufruf der API läuft über den HTTP-Client. Ein Blueprint beschreibt das Formularmodell, also welche Felder es gibt und welche Pflicht sind, und hält es an einer Stelle statt verteilt im Template. Die Zugangsdaten stehen in der .env-Datei und damit außerhalb des Codes. Gerendert wird mit Antlers oder Blade, ausgeliefert über das Static Caching — der Endpunkt selbst bleibt davon ausgenommen, damit jede Anmeldung wirklich am Server ankommt.
// datenschutz
technik, nicht rechtsberatung
Eine Newsletter-Anmeldung ist der Punkt, an dem eine Website personenbezogene Daten annimmt und an einen Dienstleister weitergibt. Was daran technisch zu tun ist, lässt sich klar benennen — die rechtliche Bewertung im Einzelfall gehört zur Rechtsberatung und nicht auf diese Seite. Wo eine Website beim Thema Datenschutz gerade steht, prüfen wir im Datenschutz-Audit.
Einwilligung dokumentieren. Das Double-Opt-in ist der Nachweis, und zwar genau deshalb, weil die Bestätigung aus dem Postfach kommt. Am Formular steht in klarer Sprache, wofür die Adresse verwendet wird, dazu der Verweis auf die Datenschutzerklärung. Vorbelegte Häkchen gibt es nicht, und die Einwilligung wird nicht mit einer anderen Zustimmung zusammengelegt.
Datensparsamkeit. Ein Anmeldefeld braucht die E-Mail-Adresse. Alles Weitere muss sich rechtfertigen: Vorname für die Ansprache, ein Extrafeld für die Segmentierung — mehr nur, wenn der Newsletter es wirklich verwendet. Jedes zusätzliche Pflichtfeld kostet Anmeldungen und erzeugt Daten, die jemand später schützen und löschen muss.
Kein Fremdcode im Browser. Weil das Formular auf der eigenen Domain liegt und nur der Server mit der Schnittstelle spricht, lädt der Browser der Besucher kein Skript eines Dritten, setzt keine fremden Cookies und verrät die IP-Adresse nicht an ein weiteres System. Das ist der Unterschied zwischen einer Anbindung und einem eingebetteten Fremdformular.
Auftragsverarbeitung. Der Newsletter-Dienst verarbeitet die Adressen im Auftrag; rapidmail stellt den Auftragsverarbeitungs-Vertrag nach EU-DSGVO nach eigener Angabe online im Kundenkonto bereit und gibt an, alle Daten auf Servern in Deutschland zu speichern. Auf unserer Seite kommen die üblichen Pflichten dazu: Übertragung nur über TLS, Zugangsdaten getrennt vom Code, Protokolle ohne unnötige Inhalte, ein benennbarer Weg für Abmeldung und Löschung. Mehr dazu im Stack unter Sicherheit & Datenschutz.
// faq
rapidmail ist ein Newsletter-Dienst aus Deutschland, entwickelt von einem Unternehmen mit Sitz in Freiburg im Breisgau. Im Browser werden Empfängerlisten gepflegt, Mailings gebaut und versendet, Ergebnisse ausgewertet. Der Anbieter gibt an, alle Daten auf Servern in Deutschland zu speichern, das Rechenzentrum nach ISO 27001 zertifizieren zu lassen und den Auftragsverarbeitungs-Vertrag nach EU-DSGVO direkt im Kundenkonto bereitzustellen. Für die Website zählt vor allem eines: rapidmail dokumentiert eine REST-API in Version 3.0, über die sich Empfängerlisten und einzelne Empfänger anlegen und pflegen lassen.
Über ein eigenes Anmeldeformular im Design der Website und einen serverseitigen Endpunkt dahinter. Das Formular schickt die Eingaben an die eigene Seite, dort werden sie geprüft: Pflichtfelder, Format der Adresse, das Häkchen für die Einwilligung, Schutz gegen automatisierte Eintragungen. Erst danach ruft der Server die rapidmail-API auf und legt die Adresse in der gewählten Empfängerliste an. Die Zugangsdaten liegen dabei ausschließlich auf dem Server. Der Browser spricht nur mit der eigenen Domain und bekommt am Ende eine klare Rückmeldung: Bitte bestätige die Anmeldung in deinem Postfach.
Die dokumentierte Version 3.0 liegt unter apiv3.emailsys.net und ist ausschließlich über HTTPS erreichbar. Authentifiziert wird per HTTP Basic Authentication mit einem API-Benutzer, den man im rapidmail-Konto im Bereich API anlegt. Gearbeitet wird mit JSON; Accept und Content-Type stehen laut Dokumentation auf application/json, Sammlungen antworten im HAL-Format mit Links für die Blätterung. Die Ressourcen decken Mailings, Empfängerlisten, Empfänger, Blacklist und API-Benutzer ab. Für die Last nennt die Dokumentation eine klare Grenze: maximal zehn Anfragen pro Sekunde, darüber antwortet die Schnittstelle mit Statuscode 503.
Double-Opt-in heißt: Eine Anmeldung gilt erst dann, wenn sie aus dem Postfach heraus bestätigt wurde. Die Kette hat vier Glieder. Das Formular schickt die Adresse an den eigenen Server. Der Server legt sie über die API in der Empfängerliste an, noch nicht als bestätigten Empfänger. rapidmail verschickt daraufhin die Bestätigungsmail; beim Anlegen eines Empfängers ist dafür die Option send_activationmail dokumentiert. Erst der Klick auf den Link darin macht die Adresse zu einem aktiven Empfänger. Die Website legt niemanden direkt als bestätigt an, denn damit wäre genau der Nachweis weg, um den es geht.
rapidmail gibt an, alle Daten auf Servern in Deutschland zu speichern, keine Daten an Dritte weiterzugeben und die Übertragung mit 256-Bit-SSL zu verschlüsseln; das Rechenzentrum ist nach ISO 27001 zertifiziert. Den Auftragsverarbeitungs-Vertrag nach EU-DSGVO stellt der Anbieter online im Kundenkonto bereit. Wem Verarbeitung in Deutschland und deutschsprachiger Support wichtig sind, für den ist das der naheliegende Weg. Ob er im konkreten Projekt der richtige ist, ordnen wir im Konzept ein, statt eine Rangliste zu behaupten. CleverReach, Brevo und Mailchimp beschreiben wir im Stack jeweils auf einer eigenen Seite.
Ja. Eine Empfängerliste kennt neben der E-Mail-Adresse Standardfelder wie Vorname, Nachname, Geschlecht, Titel, Postleitzahl und eine eigene Referenz. Alles darüber hinaus läuft über Extrafelder, von denen laut Hilfecenter bis zu zehn zur Verfügung stehen, etwa eine Kundennummer oder ein Interessengebiet. Dazu kommen Stichworte, mit denen sich Empfänger segmentieren lassen. Für die Website heißt das: Wir übergeben nur die Felder, die der Newsletter wirklich braucht. Jedes zusätzliche Pflichtfeld im Formular kostet Anmeldungen und muss sich rechtfertigen.
Der Abmeldelink gehört in jede versendete Mail und wird vom Dienst selbst getragen; dafür muss die Website nichts bauen. Zusätzlich lassen sich Empfänger über die API löschen, und die Blacklist ist eine eigene Ressource der Schnittstelle: Adressen, die dort stehen, werden nicht mehr angeschrieben. Kommt eine Abmelde- oder Löschanfrage über ein Formular der Website, behandeln wir sie wie jede andere Anfrage auch, nämlich serverseitig, protokolliert und mit einer Rückmeldung an die Person. Wie lange welche Daten aufbewahrt werden dürfen, gehört in die rechtliche Prüfung. Wir bauen die Technik, die beides möglich macht.
Ja, in allen dreien, und zwar als eigene Entwicklung mit den Bordmitteln des jeweiligen Systems. In TYPO3 bauen wir eine eigene Extension: das Anmeldeformular als Plugin-Element, eine serverseitige Route mit Middleware als Endpunkt, Fluid für die Ausgabe, die Zugangsdaten in der Extension-Konfiguration. In WordPress entsteht ein eigenes Plugin statt Theme-Code, mit einer eigenen REST-Route für die Verarbeitung, den Zugangsdaten in der wp-config.php oder einer Umgebungsvariablen und Template-Dateien beziehungsweise Blocks fürs Frontend. In Statamic liegt Laravel darunter: Route plus Controller nehmen das Formular entgegen, ein Blueprint beschreibt das Formularmodell, die Zugangsdaten stehen in der .env-Datei, gerendert wird mit Antlers oder Blade. Die Mechanik ist überall dieselbe, nur die Bordmittel heißen anders.
// womit das zusammenhängt
dienste, bausteine & leistung
// stack · schnittstelle
Der zweite deutsche Dienst im Stack: eigene Schnittstelle, eigene Mechanik — dieselbe Frage nach Formular, Liste und Bestätigung.
zur technik →
// stack · schnittstelle
Newsletter, Transaktionsmails und Kontaktverwaltung in einem Werkzeug — und wie die Anmeldung von der Website dort ankommt.
zur technik →
// stack · schnittstelle
Der internationale Klassiker mit großem Funktionsumfang: was die Anbindung an eine deutsche Website dabei zu klären hat.
zur technik →
// komponente · buchen
Die Technik hier, der Baustein dort: die Newsletter-Anmeldung mit Double-Opt-in als Komponente für deine Website. Hier wird gebucht.
zur komponente →
// komponente · formulare
Wie wir Formulare grundsätzlich bauen: Validierung, Zustände, Fehlermeldungen, Barrierefreiheit — die Basis unter jedem Anmeldefeld.
zur komponente →
// stack · grundlage
Wo Adressdaten fließen, wird es ernst: Zugangsdaten serverseitig, TLS, Datensparsamkeit, Auftragsverarbeitung.
zur technik →
// Newsletter-Anmeldung mit rapidmail auf deiner Website?
Projekt anfragen