// stack · schnittstelle
ActiveCampaign ist E-Mail-Marketing mit Automatisierungen — und einem CRM-Anteil daneben. Für siteway ist die spannende Frage nicht, wie eine Adresse in eine Liste kommt, sondern wie ein Ereignis auf der Website zum Auslöser einer Strecke wird. Diese Seite beschreibt die Technik dahinter: eigenes Formular, serverseitiger Endpunkt, dokumentierte REST-API.
// definition
ActiveCampaign ist eine Plattform für E-Mail-Marketing mit Automatisierungen und CRM-Funktionen, entwickelt von der ActiveCampaign, Inc. mit Sitz in Chicago, Illinois, gegründet 2003. Unternehmen verwalten darin Kontakte, Listen, Tags, benutzerdefinierte Felder, Kampagnen und Automatisierungen — dazu Deals und Pipelines auf der Vertriebsseite.
Der Unterschied zu einem reinen Versandwerkzeug liegt in der Automatisierung: Strecken, die von selbst laufen, wenn eine Bedingung eintritt. Ein Kontakt abonniert eine Liste, bekommt ein Tag oder löst ein Ereignis aus — und daraufhin startet eine Abfolge aus Wartezeiten, Bedingungen und Mails. Diese Logik wird im Tool gebaut, nicht in der Website.
Für die Website zählt vor allem, dass ActiveCampaign seine REST-API in der Version 3 öffentlich dokumentiert — unter developers.activecampaign.com, mit Ressourcen für Kontakte, Listen, Tags, benutzerdefinierte Felder, Automatisierungen und Webhooks. Damit muss niemand ein fremdes Formular in seine Seite einbetten: Die Anmeldung entsteht im Frontend der Website, die Übergabe passiert serverseitig.
// praxis
signal liefern · logik im tool
Die wichtigste Entscheidung fällt vor der ersten Zeile Code, und sie ist eine Trennlinie: Die Website liefert Signale, das Tool hält die Logik. Welche Mail nach wie vielen Tagen an wen geht, in welcher Reihenfolge und unter welcher Bedingung — das gehört in die Automatisierung, wo Marketing es selbst ändern kann. Was die Website dafür schuldet, ist ein sauberes, eindeutiges Signal: dieser Mensch, dieses Ereignis, dieser Anlass.
Gebaut wird das als eigenes Formular im Design der Website mit einem serverseitigen Endpunkt dahinter. Das Formular schickt seine Daten an die eigene Anwendung, nicht direkt an ActiveCampaign. Dort passiert die Validierung — Pflichtfelder, Format der Adresse, Schutz gegen automatisiertes Absenden — und dort liegt der API-Schlüssel. Die Dokumentation ist an dem Punkt eindeutig: Der Schlüssel gehört nicht in clientseitigen Code. Ein Formular, das den Schlüssel im Browser trägt, verschenkt ihn.
Vom Endpunkt aus läuft der Aufruf in vier Schritten: Kontakt anlegen oder aktualisieren, Liste zuordnen, Tags setzen und Felder füllen. Genau in dieser Struktur entsteht der Wert. Das Tag sagt, worum es ging — „whitepaper-preisliste“, „termin-erstgespräch“. Das benutzerdefinierte Feld sagt, woher der Kontakt kam: welche Seite, welches Formular, welche Kampagne. Ohne diese Herkunft ist ein Kontakt später nicht mehr einzuordnen, und jede Segmentierung wird zum Ratespiel.
Erst danach wird es werblich — und dazwischen steht das Double-Opt-in. Der Kontakt kommt an, wird protokolliert und bekommt eine Bestätigungsmail; in die werbliche Liste und in die Strecke wandert er erst nach dem Klick. Ob wir dafür die Bestätigung von ActiveCampaign nutzen oder sie selbst im Endpunkt bauen, hängt vom Projekt ab. Die Reihenfolge bleibt in beiden Fällen dieselbe. Mehr zum Baustein selbst steht bei Newsletter & E-Mail.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die API nicht, langsam oder mit einer Absage, darf der Mensch am Formular das nicht ausbaden. Die Anmeldung wird zuerst bei uns gesichert, dann in eine Warteschlange gelegt und mit Abstand erneut versucht — passend zur dokumentierten Grenze von fünf Anfragen pro Sekunde je Konto. Ein Lead, der im Netzwerkfehler verschwindet, ist teurer als jede Anbindung. Details zur Leistung dahinter stehen unter Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Entwicklerdokumentation von ActiveCampaign — Pfade, Feldnamen und Grenzen im Original. Alles, was dort nicht steht, steht auch hier nicht: Preise, Tarife und Funktionsumfänge ändern sich, Endpunkte sind belegbar.
// d-01zugang
Jedes Konto hat eine eigene Basis-URL nach dem Muster https://konto.api-us1.com/api/3/. Authentifiziert wird mit einem Schlüssel im Header Api-Token, den das Konto unter Settings und Developer ausweist. Die Dokumentation bittet ausdrücklich darum, ihn nicht in clientseitigem Code offenzulegen.
zweck: authentifizierung
// d-02kontakte
Ein Kontakt entsteht unter /contacts mit email, firstName, lastName und phone. /contact/sync legt ihn an oder aktualisiert ihn anhand der E-Mail-Adresse — das verhindert Dubletten. Benutzerdefinierte Werte stehen in fieldValues, wobei field die ID des Feldes trägt, nicht seinen Namen.
zweck: kontakt & herkunft
// d-03listen
Die Zuordnung läuft über /contactLists mit list, contact und status; 1 steht für abonniert, 2 für abgemeldet. Die Dokumentation warnt an der Stelle deutlich: Ein Wechsel zurück auf aktiv trägt jemanden wieder ein, der sich selbst abgemeldet hatte. Deshalb prüfen wir den Status, statt ihn blind zu setzen.
zweck: verteiler-zuordnung
// d-04tags
/contactTags weist einem vorhandenen Kontakt ein vorhandenes Tag zu — beides muss also vorher existieren, Tags entstehen über die eigene Tag-Ressource. Weil ActiveCampaign das Hinzufügen eines Tags als Startbedingung einer Automatisierung kennt, ist genau das der schmalste Weg, eine Strecke zu starten.
zweck: strecke starten
// d-05ereignisse
Ein Vorgang lässt sich auch als Ereignis melden: Der Aufruf geht an trackcmp.net/event mit actid, dem Event-Key, einem Namen von höchstens 32 Zeichen und visit als JSON mit der E-Mail-Adresse; eventdata nimmt einen zusätzlichen Wert auf. Voraussetzung ist, dass Event-Tracking im Konto unter Website und Site Tracking eingeschaltet ist.
zweck: vorgang melden
// d-06takt
In die Gegenrichtung melden Webhooks Ereignisse aus dem Konto an eine URL — etwa wenn ein Kontakt hinzukommt, sich abmeldet oder ein Tag wechselt. Für den Takt nennt die Dokumentation fünf Anfragen pro Sekunde je Konto; darüber kommt Status 429 mit Retry-After, RateLimit-Limit und RateLimit-Remaining.
zweck: rückkanal & takt
ActiveCampaign kennt für den Start einer Automatisierung mehrere Bedingungen — unter anderem das Abonnieren einer Liste, das Hinzufügen eines Tags, das Abschicken eines Formulars und ein aufgezeichnetes Ereignis. Für die Anbindung heißt das: Wir haben nicht einen Weg, sondern eine Auswahl, und jede Auswahl hat eine Folge. Ein Tag bleibt am Kontakt kleben und ist damit auch später noch Filterkriterium. Ein Ereignis beschreibt einen Moment und blockiert kein Feld.
In der Praxis mischen wir beides. Ein Whitepaper-Download setzt ein Tag, weil das Interesse dauerhaft etwas über den Kontakt aussagt — der passende Baustein dazu ist das Lead-Magnet-Formular. Ein gebuchter Termin oder ein abgeschlossener Schritt in einem Konfigurator ist eher ein Ereignis: einmal passiert, gemeldet, fertig. Welche Signale eine Seite überhaupt erzeugen kann und welche davon jemanden interessieren, klären wir vor dem Bauen — sonst entsteht eine Anbindung, die viel meldet und wenig sagt.
Der Rest ist Ordnung: eine Namenskonvention für Tags, die auch in zwei Jahren noch lesbar ist, Felder für Herkunft und Anlass, und ein Protokoll darüber, welches Formular welches Signal auslöst. Wo Strecken weiter automatisiert werden sollen — Anreicherung, Vorqualifizierung, Weiterleitung an ein anderes System —, geht es weiter bei KI & Automation.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er ist bewusst systemunabhängig gedacht: ein eigenes Formular im Design der Website — kein eingebettetes Fremdformular, das seine eigene Schrift und seine eigenen Farben mitbringt. Abgeschickt wird an einen serverseitigen Endpunkt in der Website selbst. Dieser Endpunkt hält die Zugangsdaten, prüft die Eingaben und spricht mit der API: Kontakt anlegen oder aktualisieren, Liste zuordnen, Tags setzen, Felder für Herkunft und Anlass füllen — und damit die passende Automatisierung auslösen.
Unterschiedlich ist nur, wo im jeweiligen CMS diese drei Bausteine liegen: das Formular als redaktionell platzierbares Element, die Route als Endpunkt und der Ablageort der Zugangsdaten. Deshalb bauen wir die Anbindung in jedem System als eigenen Baustein mit dessen eigenen Bordmitteln — so bleibt sie nachvollziehbar, aktualisierbar und überlebt einen Design- oder Theme-Wechsel. Die Rückmeldung ans Frontend gehört dazu: Bestätigungsseite, Fehlermeldung im Formular und ein sauberer Zustand, wenn jemand zweimal abschickt.
// cms-01typo3
In TYPO3 bauen wir die Anbindung als eigene Extension. Das Anmeldeformular wird darin ein Plugin-Element, das die Redaktion im Seitenbaum genau dort platziert, wo es hingehört — im Footer, in einer Spalte, auf einer eigenen Seite. Das Abschicken nimmt eine serverseitige Route entgegen, eingehängt über eine Middleware; dort laufen Validierung, der Aufruf der API und die Fehlerbehandlung. Ausgegeben wird über Fluid, sodass Formular, Bestätigung und Fehlermeldung im Template des Projekts liegen und nicht in fremdem Markup. Die Zugangsdaten stehen in der Extension-Konfiguration und lassen sich je Umgebung setzen, damit Redaktion und Produktion sauber getrennt bleiben.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so übersteht sie einen Theme-Wechsel und ein Redesign. Eine eigene REST-Route nimmt das abgeschickte Formular entgegen, prüft die Felder und ruft die API serverseitig auf; im Browser landet nie ein Schlüssel. Die Zugangsdaten liegen in der wp-config.php oder in einer Umgebungsvariable, also außerhalb der Datenbank und außerhalb des Backends. Fürs Frontend kommen Template-Dateien und Blöcke für den Editor dazu, damit die Redaktion das Anmeldeformular selbst setzen kann — inline im Beitrag, im Footer oder auf einer Landingpage.
// cms-03statamic
Statamic läuft auf Laravel — damit ist der Endpunkt schlicht eine Route mit einem Controller, inklusive Validierung, Warteschlange für erneute Versuche und Protokoll. Das Formularmodell beschreibt ein Blueprint: welche Felder es gibt, welche Pflicht sind und welches Tag daran hängt — änderbar, ohne den Controller anzufassen. Die Zugangsdaten stehen in der .env und damit außerhalb des Repositorys. Gerendert wird mit Antlers oder Blade, sodass das Formular dieselben Bausteine nutzt wie der Rest der Seite. Im Control Panel pflegt die Redaktion Beschriftungen und Hinweistexte, ohne an die Anbindung zu müssen.
// datenschutz
technisch beschrieben · nicht bewertet
ActiveCampaign ist ein Anbieter aus den USA — die Gesellschaft sitzt in Chicago, Illinois. Wer das Werkzeug einsetzt, gibt personenbezogene Daten an einen Dienstleister weiter und lässt sie dort verarbeiten. Zwei Punkte gehören deshalb in die Projektplanung und nicht ins Kleingedruckte: ein Vertrag zur Auftragsverarbeitung mit dem Anbieter und die Frage, auf welcher Grundlage die Daten übermittelt und verarbeitet werden. Das ist keine Bewertung — das ist die Liste dessen, was zu klären ist.
Technisch halten wir die Übergabe so schmal wie möglich. Es gehen nur die Felder raus, die die Strecke wirklich braucht — für eine Newsletter-Anmeldung ist das in der Regel die E-Mail-Adresse plus die Herkunft. Die Übertragung läuft ausschließlich serverseitig über TLS, die Zugangsdaten liegen in der Server-Konfiguration, und das Site-Tracking-Skript von ActiveCampaign lädt erst nach einer Einwilligung, weil es Verhalten auf der Website mit einer Person verknüpft.
Dazu kommt die Einwilligung selbst. Sie wird aktiv erteilt, ohne vorangekreuztes Feld, mit einem Datenschutzhinweis direkt am Formular. Der Vorgang wird mit Zeitstempel, Quelle und dem angezeigten Einwilligungstext protokolliert, und in die werbliche Liste kommt der Kontakt erst nach dem bestätigten Double-Opt-in. Abmeldungen laufen in die Gegenrichtung: Über Webhooks meldet ActiveCampaign eine Abmeldung zurück, sodass die Website nicht weiter Signale für jemanden schickt, der nicht mehr will.
Was auf dieser Seite bewusst nicht steht, ist eine rechtliche Bewertung — die gehört in eine Prüfung mit Dokumentation. Wir machen das im Datenschutz-Audit: Dort werden eingesetzte Dienste erfasst, Datenflüsse aufgeschrieben, Verträge und Hinweise abgeglichen und die Datenschutzerklärung nachgezogen. Die technischen Grundlagen dazu stehen im Stack unter Sicherheit & Datenschutz.
// faq
ActiveCampaign ist eine Plattform für E-Mail-Marketing mit Automatisierungen und CRM-Funktionen, entwickelt von der ActiveCampaign, Inc. mit Sitz in Chicago, Illinois, gegründet 2003. Unternehmen verwalten darin Kontakte, Listen, Tags, Kampagnen und Automatisierungen, dazu Deals und Pipelines auf der Vertriebsseite. Für die Website zählt vor allem eines: ActiveCampaign dokumentiert seine REST-API öffentlich unter developers.activecampaign.com, mit Ressourcen für Kontakte, Listen, Tags, benutzerdefinierte Felder, Automatisierungen und Webhooks. Damit lässt sich eine Anmeldung im eigenen Design bauen, statt ein fremdes Formular einzubetten.
Über ein eigenes Formular im Design der Website und einen serverseitigen Endpunkt dahinter. Das Formular schickt seine Daten an die eigene Anwendung, nicht direkt zu ActiveCampaign. Dort werden die Eingaben geprüft, dort liegt der API-Schlüssel, und erst von dort geht der Aufruf an die API: Kontakt anlegen oder aktualisieren, Listenzuordnung setzen, Tags vergeben, Herkunft als Feld mitgeben. Die Website übergibt damit ein sauberes Signal — was danach passiert, welche Mail wann rausgeht und in welcher Reihenfolge, bleibt als Automatisierung im Tool. Das ist die Trennlinie, an der wir bauen.
Die aktuelle Version 3 ist eine REST-API mit JSON. Jedes Konto hat eine eigene Basis-URL nach dem Muster https://konto.api-us1.com/api/3/; authentifiziert wird mit einem API-Schlüssel im Header Api-Token, den das Konto unter Settings und Developer ausweist. Die Dokumentation weist ausdrücklich darauf hin, den Schlüssel geheim zu halten und nicht in clientseitigem Code offenzulegen. Kontakte liegen unter /contacts, ein Anlegen-oder-Aktualisieren über die E-Mail-Adresse unter /contact/sync, Listenzuordnungen unter /contactLists, Tag-Zuweisungen unter /contactTags. Als Grenze nennt die Dokumentation fünf Anfragen pro Sekunde und Konto; darüber antwortet die API mit dem Status 429 und den Kopfzeilen Retry-After, RateLimit-Limit und RateLimit-Remaining.
Weil die Adresse allein nur eine Zeile in einer Liste ist. Der Wert entsteht durch das, was daneben steht: die Liste, in der der Kontakt landet, die Tags, die ihn beschreiben, die benutzerdefinierten Felder mit Herkunft und Anlass — und die Automatisierung, die daraus startet. ActiveCampaign kennt dafür Auslöser wie das Abonnieren einer Liste, das Hinzufügen eines Tags, das Abschicken eines Formulars oder ein aufgezeichnetes Ereignis. Ein Website-Vorgang wie ein abgeschicktes Formular, ein geladenes Whitepaper oder ein gebuchter Termin wird so zum Startpunkt einer Strecke. Die Website liefert das Signal, die Strecke selbst wird im Tool gebaut.
In zwei möglichen Bauweisen. Nutzt du die Formulare von ActiveCampaign, ist das Double-Opt-in für die Formularaktion Subscribe to list standardmäßig aktiv: Der Kontakt wird zunächst als unbestätigt geführt, bekommt eine Bestätigungsmail mit Link, und erst der Klick setzt ihn auf aktiv. Die Dokumentation hält dazu fest, dass ein Kontakt bei aktiviertem Double-Opt-in erst nach dieser Bestätigung in eine Automatisierung aufgenommen wird. Bauen wir das Formular selbst, läuft dieselbe Logik über unseren Endpunkt: Anmeldung entgegennehmen, Bestätigungslink verschicken, den Vorgang mit Zeitstempel, Quelle und angezeigtem Einwilligungstext protokollieren — und den Kontakt erst nach dem Klick in die werbliche Liste und die zugehörige Strecke setzen. Welcher Weg passt, entscheiden wir im Projekt.
Event-Tracking ist der Weg, ein Ereignis auf der Website an ActiveCampaign zu melden, ohne dafür ein Kontaktfeld zweckzuentfremden. Der Aufruf geht laut Dokumentation an trackcmp.net/event und trägt die Kennung des Kontos als actid, den Event-Key, einen Ereignisnamen mit höchstens 32 Zeichen und die Zuordnung zur Person als visit im JSON-Format mit der E-Mail-Adresse; ein optionales Feld eventdata nimmt einen zusätzlichen Wert auf. Voraussetzung ist, dass Event-Tracking im Konto unter Website und Site Tracking eingeschaltet ist. Sinnvoll ist das überall dort, wo ein Vorgang eine Strecke starten soll, ohne den Kontakt dauerhaft neu zu etikettieren — eine Buchung, ein Download, ein Schritt in einem Konfigurator.
ActiveCampaign ist ein Anbieter aus den USA — die Gesellschaft sitzt in Chicago, Illinois. Damit gehören zwei Punkte in das Projekt und nicht ins Kleingedruckte: ein Vertrag zur Auftragsverarbeitung mit dem Anbieter und die Frage, auf welcher Grundlage die Daten übermittelt und verarbeitet werden. Technisch halten wir die Übergabe schmal: nur die Felder, die die Strecke wirklich braucht, Übertragung ausschließlich serverseitig über TLS, Zugangsdaten in der Server-Konfiguration statt im Frontend, das Site-Tracking-Skript erst nach Einwilligung. Die Bewertung selbst gehört nicht auf diese Seite, sondern in ein Datenschutz-Audit — dort wird geprüft, dokumentiert und in der Datenschutzerklärung nachgezogen.
Ja — und in Statamic ebenso. Wir bauen die Anbindung in jedem der drei Systeme selbst, mit dessen eigenen Bordmitteln. In TYPO3 entsteht eine eigene Extension: das Formular als Plugin-Element im Seitenbaum, 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, damit die Anbindung einen Theme-Wechsel überlebt: eine eigene REST-Route nimmt die Anmeldung entgegen, die Zugangsdaten liegen in der wp-config.php oder in einer Umgebungsvariable, ausgegeben wird über Template-Dateien oder Blöcke im Editor. In Statamic liegt Laravel darunter: Route und Controller bilden den Endpunkt, ein Blueprint beschreibt das Formularmodell, die Zugangsdaten stehen in der .env, gerendert wird mit Antlers oder Blade.
// womit das zusammenhängt
systeme, bausteine & leistung
// stack · schnittstelle
Der deutsche Nachbar im selben Feld: E-Mail-Marketing mit eigener Schnittstelle — andere Mechanik, dieselbe Frage nach Signal und Strecke.
zur technik →
// stack · schnittstelle
Das verbreitetste Newsletter-Werkzeug und wie eine Anmeldung im eigenen Design sauber daran andockt.
zur technik →
// stack · schnittstelle
Wenn CRM und Marketing enger zusammenrücken: dieselbe Trennlinie zwischen Website-Signal und Tool-Logik, eine Nummer größer.
zur technik →
// komponente · buchen
Die Technik hier, der Baustein dort: Anmeldeformular, Double-Opt-in, Consent-Protokoll und Abmeldung als buchbare Komponente.
zur komponente →
// komponente · buchen
Whitepaper gegen Adresse: der häufigste Anlass, aus dem in ActiveCampaign ein Tag und daraus eine Strecke wird.
zur komponente →
// leistung · buchen
Analyse, Feld- und Tag-Konzept, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// ActiveCampaign an deine Website anbinden?
Projekt anfragen