API(Was ist das, und warum reden Tools ständig miteinander?)

Willkommen beim Marketing Techie Podcast, dem Podcast über die Technik hinter dem Online-Marketing. Verständlich erklärt, auch für Non-Techies. Mit Emilian Buza von trace5.co. In der heutigen Folge: Die API. Was ist das, und warum reden Tools ständig miteinander?

Wer sich nicht daran hält, wird gefeuert. So endet eine der folgenreichsten Anweisungen der Internetgeschichte.

Sie stammt von Jeff Bezos. Irgendwann um das Jahr 2002 herum. Und sie richtet sich an alle Teams bei Amazon. Sinngemäß steht da: Kein Team darf mehr einfach auf Daten oder Programme eines anderen Teams zugreifen.

Heißt: Wer etwas von einem anderen Team braucht, zum Beispiel eine Bestellung, einen Preis oder eine Lieferadresse, der muss das Team danach fragen. Und zwar auf einem offiziell festgelegten Weg. Übers Netzwerk, mit einer Anfrage in einem fest vereinbarten Format. Das andere Team schickt dann eine Antwort zurück. Ebenfalls in einem fest vereinbarten Format.

Nur noch so. Keine Hintertüren. Keine Abkürzungen. Welche Technik dafür verwendet wird? Ist Bezos egal.

Aber jeder dieser Wege muss von Anfang an so gebaut sein, dass man ihn irgendwann auch Leuten außerhalb von Amazon öffnen könnte. Ohne Ausnahme. Und wer nicht mitzieht … na ja. Siehe oben.

Was war passiert und warum war das so wichtig? Nun, Amazon hatte zu diesem Zeitpunkt ein Problem. Ursprünglich war die Firma als eine einzige große Anwendung gestartet. Ein Webserver, dahinter eine Datenbank. Und Ende der Neunziger arbeiteten alle Entwicklerteams an genau dieser einen Anwendung.

Und diese Arbeitsweise hatte einen Haken: Ein Team konnte aus Versehen etwas kaputt machen, das ein anderes Team gebaut hatte. Darum musste jede neue Version behutsam mit allen Teams abgestimmt werden.

Am Anfang war das alles noch einigermaßen ok. Doch je größer Amazon wurde, desto langsamer wurde alles. Und Amazon wurde sehr schnell immer größer.

Mit Bezos’ Anweisung bekam jedes Team seinen eigenen abgeschotteten Bereich. Darin konnte es umbauen, was es wollte. Andere Teams konnten zwar von diesem Team Dinge anfordern und abfragen – aber sie fummelten nicht mehr in der Arbeit dieses Teams rum. So konnten die Teams also endlich unabhängig voneinander arbeiten. Und schneller.

Aber woher wissen wir heute von dieser pikanten Drohung von Bezos? Öffentlich aufgetaucht ist sie tatsächlich nie. Wir kennen sie nur durch einen Unfall.

Steve Yegge, ein ehemaliger Entwickler von Amazon, hat sie 2011 aus dem Gedächtnis aufgeschrieben. In einem Text, der eigentlich nur für ein paar Kollegen gedacht war. Und der versehentlich öffentlich wurde.

Er schrieb die Punkte so auf, wie er sie in Erinnerung hatte. Und hängte noch einen siebten dran, nach eigener Aussage nur als Witz: ‚Vielen Dank, und einen schönen Tag noch. Dementiert hat die Geschichte bei Amazon bis heute niemand.

Und was ist aus der Anweisung geworden? Etwas Großes. Denn nach und nach war jede Funktion innerhalb von Amazon über einen standardisierten, festgelegten Weg ansprechbar und erreichbar.

Und das führte zu dem Gedanken: Wenn bei Amazon sowieso jede Funktion über so einen festgelegten Weg erreichbar ist, den man auch nach außen öffnen könnte … dann kann man diese Funktionen ja auch nach außen verkaufen.

Amazons Technikchef Werner Vogels hat später selbst gesagt: Aus genau diesem Umbau ist 2006 Amazon Web Services entstanden. Die Cloud, auf der heute ein riesiger Teil des Internets läuft.

Was AWS genau ist, würde hier zu weit führen. Wichtig ist, was da bei Amazon durch Bezos’ Anweisung passiert ist.

Funktionen wurden in einzelne Einheiten ‚gekapselt‘. Wenn ein Team das Ergebnis eines anderen Teams benötigte, musste es nicht mehr direkt in dessen Code oder Datenbank greifen. Es konnte jetzt einfach ein Ergebnis anfordern und bekam es, ohne Einblick in das Innenleben des anderen Teams zu haben oder darin eingreifen zu können.

Und genau so funktionieren heute auch deine Tools. Dein Shop meldet Bestellungen an Meta. Dein CRM schickt abgeschlossene Deals an Google Ads. Dein Formular übergibt neue Kontakte an dein Newsletter-Tool.

Keins dieser Tools greift dabei einfach in die Daten des anderen. Es stellt eine Anfrage auf einem festgelegten Weg. Und bekommt eine Antwort in einem festgelegten Format. Und dieser festgelegte Weg hat einen Namen: API.

Und weil das so wichtig ist, klären wir in dieser Episode, was genau dahintersteckt. Und warum deine Tools ständig miteinander reden. Lass uns mit einer Situation anfangen, die du vielleicht kennst.

Montagmorgen. Du schaust in den Meta Werbeanzeigenmanager und siehst: Am Wochenende hat deine Kampagne kaum Käufe gebracht. Im Shop dagegen sind ganz normal Bestellungen reingekommen.

Du schreibst deiner Agentur. Und die antwortet: „Ah, die API-Verbindung ist abgerissen. Wir kümmern uns.“

Und du denkst dir: Okay. Klingt, als wüssten die, was los ist. Aber was genau ist da eigentlich abgerissen? Und warum hat das niemand gemerkt?

Genau das klären wir jetzt. Und am Ende dieser Folge weißt du nicht nur, was eine API ist. Sondern auch, welche Fragen du stellen kannst, wenn mal wieder irgendwas „an der API“ liegt. Fangen wir mit dem eigentlichen Problem an.

Dein Shop weiß, dass jemand etwas gekauft hat. Die Bestellung liegt ja in seiner Datenbank. Meta weiß das aber nicht. Meta hat die Anzeige ausgespielt, vielleicht auch den Klick gesehen. Aber was danach in deinem Shop passiert, das passiert auf einem ganz anderen Server. Bei einem ganz anderen Unternehmen.

Damit Meta deine Kampagne optimieren kann, muss diese Information also irgendwie von deinem Shop zu Meta kommen.

Und jetzt könntest du sagen: Ja, dann exportiere ich halt jeden Tag eine Liste mit allen Bestellungen und lade die hoch.

Und so etwas gibt es tatsächlich. Google Ads zum Beispiel bietet genau so einen Import für Conversions an, die nicht direkt auf der Website gemessen wurden.

Aber stell dir mal vor, wie das im Alltag aussieht. Jemand muss jeden Tag daran denken. Die Liste muss im richtigen Format sein. Wenn am Freitag jemand krank ist, fehlen die Daten. Und selbst wenn alles klappt: Von deinem Kauf am Sonntagabend erfährt die Werbeplattform erst am Montag. Für eine Kampagne, die laufend Gebote abgibt, ist das ziemlich spät.

Was du eigentlich willst: Der Shop soll Meta selbst Bescheid sagen. Automatisch. In dem Moment, in dem die Bestellung eingeht.

Und jetzt hat dein Shop direkt sein erstes Problem. Wie soll ein Programm mit einem anderen Programm reden?

Die naheliegende Idee wäre: Der Shop benutzt einfach die Website von Meta. So wie du auch. Er meldet sich an, sucht die richtige Seite und trägt den Kauf ein.

Das wäre technisch tatsächlich möglich. Programme können Websites aufrufen und auslesen. Aber die Website von Meta ist für Menschen gebaut. Sobald Meta einen Knopf verschiebt oder ein Menü umbenennt, findet dein Shop den Weg nicht mehr. Und Meta erlaubt so etwas in aller Regel auch gar nicht.

Was dein Shop stattdessen braucht, sind ganz klare Antworten auf ein paar Fragen. Wohin genau schicke ich die Information? In welcher Form muss sie aussehen? Woran erkennt Meta, dass ich das überhaupt darf? Und was bekomme ich zurück?

Diese Antworten kann sich dein Shop nicht selbst ausdenken. Die muss Meta festlegen. Und aufschreiben. Und dann muss sich jeder, der mit Meta reden will, genau daran halten. Und zwar unabhängig davon, wie die Website gerade aussieht.

Erinnerst du dich an die Geschichte vom Anfang? An Bezos und seine Teams? Genau das hat er verlangt: einen offiziell festgelegten Weg, über den ein Programm bei einem anderen etwas anfragen kann. Mit fest vereinbartem Format für die Anfrage und für die Antwort. Und dieser festgelegte Weg ist die API.

Ausgeschrieben heißt das Application Programming Interface. Auf Deutsch sagt man Programmierschnittstelle. Den ausgeschriebenen Namen musst du dir nicht merken. Wichtig ist das hier, und das solltest du dir merken: Eine API ist ein festgelegter Weg, über den ein Programm einem anderen Programm Daten schicken oder Daten von ihm abfragen kann. Programm zu Programm. Nicht Mensch zu Website.

In deinen Tools taucht das Ganze übrigens oft unter einem anderen Namen auf: Integration. Gemeint ist eine eingerichtete Verbindung über eine API. Ich sage dazu ab jetzt einfach Verbindung.

So. Und wie sieht so ein Gespräch zwischen zwei Programmen jetzt konkret aus?

Das Prinzip kennst du schon. In Folge 2 haben wir besprochen, was passiert, wenn dein Browser eine Website lädt. Er schickt eine Anfrage an den Server, auf Englisch Request. Und der Server schickt eine Antwort zurück, eine Response.

Bei den allermeisten APIs, mit denen du als Marketer zu tun hast, läuft das ganz genauso. Gleiches Protokoll, also HTTP. Gleiches Prinzip. Anfrage raus, Antwort zurück. Der Unterschied liegt darin, was drinsteht.

Wenn dein Browser eine Website anfragt, bekommt er HTML zurück. Also Text mit Anweisungen, wie die Seite aussehen soll. Überschrift hier, Bild da, Knopf dort.

Bei einer API geht es nicht darum, wie etwas aussieht. Da geht es nur um die Daten selbst. Und die werden so verpackt, dass ein Programm sie direkt weiterverarbeiten kann. Schauen wir uns an, was dein Shop bei so einer Anfrage alles festlegen muss.

Als Erstes: die Adresse. Und zwar nicht einfach meta.com. Sondern eine ganz bestimmte Adresse, die Meta genau für diesen einen Zweck vorgesehen hat. Hier kommen Ereignisse aus einem Shop rein. So eine Adresse heißt Endpunkt, auf Englisch Endpoint. Eine API hat meistens viele davon. Einen, um Kampagnen abzufragen. Einen, um Ereignisse zu melden. Und so weiter.

Als Zweites: was der Shop eigentlich will. Will er etwas abholen? Oder will er etwas abliefern? Das steht in der sogenannten Methode. Die zwei wichtigsten heißen GET und POST. GET heißt sinngemäß: Gib mir etwas. POST heißt: Hier, ich schicke dir etwas. Unser Shop will einen Kauf melden. Er schickt also etwas. POST.

Als Drittes: der eigentliche Inhalt. Und da fragst du dich vielleicht: Wie sieht ein Inhalt aus, den ein Programm versteht?

Meistens in einem Format namens JSON. Das spricht man wie den Vornamen Jason. JSON ist einfach Text. Aber Text mit einer festen Ordnung: immer ein Name und dazu ein Wert.

Bei unserem Kauf steht da sinngemäß: Ereignis: Purchase. Wert: 89.90, übrigens mit Punkt statt Komma, wie im Englischen. Währung: EUR. Dazu kommen noch ein paar Angaben zum Käufer, damit Meta den Kauf einer Person zuordnen kann.

Siehst du, warum das für ein Programm so praktisch ist? Es muss nichts suchen und nichts erraten. Es liest einfach: Wert, 89.90. Fertig.

Und als Viertes, und das ist der Punkt, an dem die meisten Probleme entstehen: der Nachweis, dass dein Shop das überhaupt darf.

Denn überleg mal: Wenn jeder einfach Käufe an dein Werbekonto melden könnte, dann könnte dir auch jeder deine Daten kaputt machen. Also verlangt Meta bei jeder Anfrage einen Nachweis. Einen Schlüssel. Je nach Anbieter heißt der API-Schlüssel oder Zugriffstoken, auf Englisch Access Token. Im Kern ist das eine lange Zeichenkette, an der Meta erkennt: Diese Anfrage kommt von jemandem, der für dieses Konto freigeschaltet ist. Und wo kommt dieser Schlüssel her?

Wahrscheinlich hast du schon mal einen erzeugt, ohne es zu merken. Kennst du diese Knöpfe in Tools wie „Mit Google verbinden“ oder „Mit Facebook verbinden“? Du klickst drauf, meldest dich an, und dann kommt eine Seite, auf der steht, was das Tool alles darf. Kampagnen lesen, Berichte abrufen, vielleicht auch Anzeigen ändern. Du klickst auf Zulassen.

In genau diesem Moment bekommt das Tool so einen Schlüssel. Nicht dein Passwort. Sondern eine Erlaubnis, die an dein Konto gebunden ist und genau die Rechte hat, denen du zugestimmt hast.

Und jetzt merk dir das, denn das wird gleich wichtig: Diese Erlaubnis hängt an dem Konto, mit dem sie erteilt wurde.

So. Unser Shop hat seine Anfrage also abgeschickt. Adresse, Methode, Inhalt, Schlüssel. Und was kommt zurück? Eine Antwort. Und die beginnt immer mit einer Zahl. Dem Statuscode.

Einen davon kennst du vielleicht schon: 404. Nicht gefunden. Den bekommt man zum Beispiel, wenn man sich bei einer Adresse vertippt. Bei APIs sind vor allem vier andere wichtig. 200 heißt: Alles klar, angenommen.

400 heißt: Deine Anfrage ist fehlerhaft. Da fehlt etwas Vorgeschriebenes, oder etwas steht im falschen Format.

401 heißt: Ich weiß nicht, wer du bist. Der Schlüssel fehlt oder gilt nicht mehr.

Und 429 heißt: Zu viele Anfragen in zu kurzer Zeit. Mach mal langsamer. Denn fast jede API legt fest, wie oft man sie pro Minute oder pro Stunde fragen darf. Und jetzt kommt ein Punkt, der vielen Marketern nicht klar ist.

Eine 200 heißt, dass die Anfrage angenommen wurde. Sie heißt nicht, dass die Daten darin für dich brauchbar sind.

Nimm unseren Kauf. Wenn dein Shop alle vorgeschriebenen Angaben mitschickt, aber kaum etwas zum Käufer, dann ist die Anfrage formal in Ordnung. Meta antwortet mit 200. Nur kann Meta diesen Kauf dann kaum einer Person zuordnen, die vorher deine Anzeige gesehen hat. Und für die Optimierung deiner Kampagne ist er damit wenig wert.

Eine 400 merkt also wenigstens jemand, der in die Fehlermeldungen schaut. Ein angenommener, aber schwacher Kauf fällt dagegen niemandem auf. Angenommen ist nicht dasselbe wie richtig angekommen. Und damit können wir jetzt zurück zu deinem Montagmorgen. „Die API-Verbindung ist abgerissen. Was kann das heißen?

In sehr vielen Fällen heißt es genau das, was wir gerade besprochen haben: Der Schlüssel gilt nicht mehr. Und dafür gibt es ganz alltägliche Gründe. Manche Zugriffstokens laufen nach einer gewissen Zeit ab. Oder die Person, die die Verbindung damals mit ihrem Konto hergestellt hat, hat das Unternehmen verlassen, und ihr Konto wurde gelöscht. Oder jemand hat Berechtigungen aufgeräumt und dabei die Freigabe für das Tool entfernt.

Dann bekommt dein Shop bei jedem Kauf, den er melden will, eine 401 zurück. Und Meta erfährt: nichts.

Und warum hat das niemand gemerkt? Weil diese Antwort nicht bei dir landet. Sie landet bei einem Programm. Und wenn dieses Programm nicht so gebaut ist, dass es bei einem Fehler Alarm schlägt, dann passiert genau das: Es probiert, scheitert, probiert wieder, scheitert wieder. Und du siehst es erst am Montag in deinen Zahlen.

Daraus kannst du direkt die erste Frage für deine Agentur oder deine Entwicklung mitnehmen: Mit wessen Konto ist diese Verbindung hergestellt? Und wer bekommt Bescheid, wenn sie Fehler zurückliefert?

Das sind zwei Sätze. Aber die ersparen dir unter Umständen ein ganzes verlorenes Wochenende.

Jetzt aber zur zweiten großen Frage dieser Folge. Warum reden deine Tools eigentlich ständig miteinander?

Die Antwort steckt schon in der Bezos-Geschichte. Jedes Tool ist auf eine Sache spezialisiert. Dein Shop verkauft. Dein CRM verwaltet Kontakte und Deals. Google Ads und Meta spielen Werbung aus. Dein Newsletter-Tool verschickt Mails. Dein Reporting-Tool baut Diagramme.

Keins davon hat alle Daten. Aber jedes braucht Daten von den anderen.

Und weil keins dieser Tools einfach in die Datenbank des anderen greifen darf, laufen all diese Verbindungen über APIs. Drei Beispiele, die du wahrscheinlich aus deinem Alltag kennst.

Dein CRM meldet Google Ads, welcher Lead zu einem abgeschlossenen Deal geworden ist. Damit Google den Deal dem richtigen Klick zuordnen kann, schickt das CRM die Klick-ID mit, die Google beim Klick an deine URL hängt. Die sogenannte gclid. So weiß Google Ads nicht nur, wer ein Formular ausgefüllt hat, sondern auch, wer am Ende Geld gebracht hat.

Dein Shop meldet Käufe an Meta, und zwar direkt von deinem Server an Metas Server. Das ist die sogenannte Conversions API, genau unser Beispiel von eben. Und hier schließt sich der Kreis zu Folge 4, zum Server-Side Tracking. Denn diese Anfrage läuft nicht durch den Browser deines Besuchers. Ein Adblocker im Browser bekommt sie also gar nicht zu sehen.

Und dein Reporting-Tool holt sich die Zahlen aus Google Ads und GA4, zum Beispiel wenn du einen Bericht öffnest. Auch das: Anfragen an deren APIs. Diesmal mit GET. Gib mir die Zahlen von letzter Woche.

Und jetzt wirft das eine Frage auf, die du dir vielleicht schon gestellt hast. Woher weiß eigentlich ein Tool, wann es fragen soll?

Nimm dein Newsletter-Tool. Es soll neue Kontakte aus deinem Formular bekommen. Eine Möglichkeit: Es fragt einfach regelmäßig nach. Alle fünf Minuten eine Anfrage an das Formular-Tool: Gibt’s was Neues? Nein. Gibt’s was Neues? Nein. Gibt’s was Neues? Ja, hier, zwei neue Kontakte.

Das funktioniert. Aber du siehst schon das Problem. Die meisten dieser Anfragen sind umsonst. Und wenn sich jemand gerade eingetragen hat, kommt die Willkommensmail im ungünstigsten Fall erst fünf Minuten später.

Deshalb gibt es auch den umgekehrten Weg. Das Formular-Tool sagt von sich aus Bescheid. In dem Moment, in dem jemand auf Absenden klickt, schickt es selbst eine Anfrage an eine Adresse, die du ihm vorher hinterlegt hast. Hier, neuer Kontakt. Das nennt man Webhook.

Bei einer normalen API-Anfrage fragt also das Tool, das etwas wissen will. Beim Webhook meldet sich das Tool, bei dem etwas passiert ist. Wenn du in einem Tool das Feld „Webhook-URL“ siehst, dann weißt du ab jetzt, was da reingehört: die Adresse, an die es Bescheid sagen soll.

So. Jetzt weißt du, was eine API ist, wie so eine Anfrage aufgebaut ist und warum deine Tools ständig miteinander reden. Bleibt die Frage: Was fängst du konkret damit an? Ich würde dir drei Dinge mitgeben.

Erstens: Wenn deine Zahlen plötzlich einbrechen, obwohl im Shop oder im CRM alles normal läuft, dann denk an die Verbindungen dazwischen. Schau in deinen Tools nach, wo die Integrationen eingestellt sind. Viele zeigen dort an, ob eine Verbindung aktiv ist oder getrennt wurde. Im Meta Events Manager gibt es zum Beispiel einen Bereich mit Diagnosen, in dem Meta Probleme mit eingehenden Ereignissen meldet. Steht da eine Warnung, hast du einen konkreten Ansatzpunkt. Steht da nichts, heißt das aber noch nicht, dass alles in Ordnung ist. Denk an die 200: angenommen ist nicht dasselbe wie richtig.

Zweitens: APIs verändern sich. Google, Meta und die meisten anderen großen Anbieter bringen regelmäßig neue Versionen ihrer APIs heraus und schalten alte nach einer gewissen Zeit ab. Wenn ein Tool, das du benutzt, nicht rechtzeitig umstellt, funktioniert die Verbindung irgendwann nicht mehr. Und zwar von einem Tag auf den anderen. Bei selbst gebauten Verbindungen solltest du deshalb wissen, wer dafür zuständig ist, sie aktuell zu halten.

Drittens: Lass dir bei jeder neuen Verbindung zwei Dinge sagen. Welche Daten genau fließen da? Und in welche Richtung? Denn eine Verbindung, die Zahlen aus Google Ads in dein Reporting holt, ist etwas völlig anderes als eine, die Daten aus deinem CRM an Google schickt. Das eine liest. Das andere schreibt. Und beim Schreiben geht es oft um personenbezogene Daten. Da sitzt dann auch dein Datenschutz mit am Tisch. Und wenn du nach dieser Folge eine Sache konkret machen willst, dann diese.

Geh in deinen wichtigsten Tools die Einstellungen durch. In deinem Shop, deinem CRM, deinem Newsletter-Tool. Such nach dem Bereich, der meistens Integrationen, Verbindungen oder Apps heißt. Und schreib dir auf, was du dort findest.

Welche Verbindungen gibt es überhaupt? Mit wessen Konto wurden sie hergestellt? Und ist diese Person noch im Unternehmen?

Das dauert vielleicht eine halbe Stunde. Aber danach weißt du, an welchen Stellen deine Daten von einem Tool zum nächsten fließen. Und du weißt, welche Verbindung als Nächstes abreißen könnte, bevor es dein Wochenende kostet.

Wenn du dann noch einen Schritt weitergehen willst: Viele der Verbindungen, über die wir heute gesprochen haben, betreffen dein Tracking. Und ob eine Messung im Browser deines Besuchers überhaupt losgeschickt wird, was darin steht und ob sie ankommt, das kannst du selbst überprüfen. Genau dafür habe ich meinen Kurs „Was passiert im Browser?“ gemacht. Darin lernst du, Anfragen in den Entwicklertools deines Browsers zu lesen, Statuscodes einzuordnen und Fehler selbst einzugrenzen. Damit du beim nächsten „Die API ist kaputt“ nicht nur nickst, sondern weißt, wo du hinschauen musst. Den Link findest du in den Shownotes. Und damit fassen wir einmal zusammen, was du jetzt weißt.

Ein Programm will etwas von einem anderen Programm. Es stellt eine Anfrage an einen festgelegten Endpunkt. Mit einer Methode, GET zum Abholen, POST zum Abliefern. Mit Inhalt, meistens in JSON. Und mit einem Schlüssel, der beweist, dass es das darf. Zurück kommt eine Antwort mit einem Statuscode. Und all diese Regeln zusammen, die der Anbieter festgelegt und aufgeschrieben hat, das ist die API.

Und wenn das nächste Mal jemand sagt: „Das liegt an der API“, dann kannst du ganz konkret nachfragen. Welche Verbindung? Mit wessen Konto? Welcher Statuscode kommt zurück? Und wer bekommt Bescheid, wenn es nicht klappt?

Das war’s für heute. Wenn du bei deiner Bestandsaufnahme auf eine Verbindung gestoßen bist, von der niemand mehr weiß, wer sie eingerichtet hat, schreib mir. Mich interessiert, was du gefunden hast. Mach’s gut, und bis zur nächsten Folge.