API:
So verbinden Sie
Systeme

Was ist eine API? Einfach erklärt

Eine API ist eine Programmierschnittstelle: Sie legt die Regeln fest, nach denen eine Softwarekomponente eine andere anspricht. Diese Regeln beschreiben die verfügbaren Aktionen, die zu übergebenden Daten und die mögliche Antwort. API steht für Application Programming Interface. Ein Mensch tippt in einer App auf einen Button; die Software kann daraufhin eine API aufrufen, um die gewünschte Aktion auszuführen.

Stellen Sie sich eine Website vor, über die Anfragen zur Lieferung von Ausrüstung eingehen. Ein Besucher füllt ein Formular aus. Der Webserver prüft die Daten und fordert das CRM auf, eine Anfrage mit diesen Feldern anzulegen. Das CRM gibt eine Datensatz-ID oder eine Fehlermeldung zurück. Der Vertrieb muss dann nicht jede Anfrage manuell übertragen. Dieser Austausch funktioniert allerdings erst nach der Einrichtung: Dass ein CRM eine API anbietet, bedeutet noch nicht, dass die Website bereits damit verbunden ist.

APIs gibt es in Bibliotheken, Betriebssystemen, Browsern und externen Diensten. Nicht jeder API-Aufruf läuft über das Internet. Ein Browser stellt beispielsweise Schnittstellen für die Arbeit mit Seitenelementen bereit. Dieser Artikel behandelt vor allem Web-APIs, die Websites, CRM-, Warenwirtschaftssysteme und andere Dienste verbinden. Den Unterschied zwischen Browser-APIs und Schnittstellen von Drittanbietern erklärt die Einführung von MDN.

So funktioniert eine API-Anfrage

An einem üblichen HTTP-Austausch sind ein Client, also das Programm, das Daten oder eine Aktion anfordert, und ein Server beteiligt, der die Anfrage empfängt. Der Client kann dabei Ihr Webserver sein und nicht der Browser des Besuchers. Ein System kann je nach Situation beide Rollen übernehmen.

Eine Anfrage umfasst üblicherweise eine Adresse, eine Methode, Header und bei Bedarf einen Body mit Daten. Die Adresse einer bestimmten Operation heißt Endpunkt oder Endpoint. Die Methode hilft, die Aktion festzulegen. Header können das Format und Angaben zum Zugriff enthalten. Im Body steht das übertragene Objekt, etwa die Felder einer Anfrage. Welche Bestandteile erforderlich sind, legt die Dokumentation der jeweiligen API fest.

Die Adresse example.com ist hier ein Platzhalter: Die Darstellung dient der Erklärung und ist kein Befehl zum Anschließen Ihres CRM. Selbst inhaltlich gleiche Operationen können in zwei Diensten unterschiedliche Felder und Regeln haben.

Eine echte API-Antwort ohne Programmierung ansehen

Zum Einstieg können Sie öffentliche Informationen zu einem Beispiel-Repository auf GitHub abrufen. Dieses Beispiel erstellt oder verändert nichts. Bei der Vorbereitung des Artikels lieferte die Anfrage eine erfolgreiche Antwort. Der Dienst begrenzt die Anzahl der Anfragen; das Ergebnis eines späteren Aufrufs hängt daher auch von den dann geltenden Zugriffsbedingungen ab.

1. Öffnen Sie die öffentliche Beispieladresse im Browser.
2. Suchen Sie das Feld full_name: Es nennt den Eigentümer und den Namen des Repositorys.
3. Prüfen Sie private: Der boolesche Wert false bedeutet, dass das Repository nicht privat ist.
4. Vergleichen Sie die API-Adresse mit html_url: Letzteres verweist auf die normale Seite für Menschen.

{
  "name": "Hello-World",
  "full_name": "octocat/Hello-World",
  "private": false,
  "html_url": "https://github.com/octocat/Hello-World"
}

Gezeigt wird ein gekürzter Ausschnitt der Antwort, nicht das vollständige Dokument. Geschweifte Klammern, Feldnamen und Werte bilden eine Darstellung im JSON-Format. Software liest bestimmte Felder; die visuelle Gestaltung der Seite braucht sie nicht. Aus der Reihenfolge der Felder sollten Sie keine Bedeutung ableiten.

Den Statuscode in Postman prüfen

In der englischen Oberfläche von Postman öffnen Sie über die folgende Schaltfläche einen neuen Tab für eine HTTP-Anfrage: Add, wählen Sie GET, fügen Sie dieselbe URL ein und klicken Sie auf Send. Prüfen Sie im unteren Bereich den Status und den Antwort-Body. Geben Sie für dieses öffentliche Beispiel keine Unternehmensgeheimnisse ein. Buttons und die Anordnung der Bereiche hängen von der Anwendungsversion ab.

Für die weitere Arbeit mit GitHub lesen Sie die offizielle Anleitung zur REST-API: Dort werden Methoden, Parameter, Header und Zugriffe erklärt. Unser Beispiel liest lediglich ein öffentliches Objekt. Es bestätigt nicht, dass Ihre CRM- oder Zahlungsintegration eingerichtet ist.

REST, JSON, Webhook und SDK: Was lässt sich vergleichen?

Diese Begriffe beschreiben unterschiedliche Teile einer Lösung. JSON ist ein Datenformat, REST ein Architekturstil. Ein Webhook benachrichtigt ein anderes System über ein Ereignis. Ein SDK ist ein Werkzeugpaket für die Entwicklung, das die API-Nutzung erleichtern kann. Es handelt sich nicht um sich gegenseitig ausschließende Alternativen.

Eine Web-API kann HTTP und JSON nutzen, ohne sämtliche REST-Prinzipien zu erfüllen. Daneben gibt es SOAP, entfernte Prozeduraufrufe und weitere Ansätze. Für Auftraggeber sind die benötigten Operationen, Dokumentation und Unterstützung wichtiger als ein moderner Technologiename. Einen Überblick bietet der API-Leitfaden von AWS.

Regelmäßige Abfragen und Ereignismeldungen

Beim Polling fragt die Integration regelmäßig, was sich seit der letzten Prüfung geändert hat. Bei einem Webhook sendet die Quelle selbst eine Benachrichtigung an eine vereinbarte Adresse, etwa dass sich eine Bestellung geändert hat. Das verkürzt Wartezeiten und vermeidet leere Abfragen, ersetzt aber nicht die Fehlerbehandlung.

Webhooks können mehrfach oder in unerwarteter Reihenfolge eintreffen. Die Regeln für erneute Zustellungen unterscheiden sich je nach Anbieter. Sie müssen die Echtheit der Meldungen prüfen, bereits verarbeitete Ereignisse erkennen und fehlende Änderungen abgleichen. GitHub empfiehlt beispielsweise HTTPS, ein Webhook-Secret und die Prüfung von Zustellungskennungen. Einzelheiten stehen in der Dokumentation. Übertragen Sie die Antwortfristen eines Dienstes nicht ungeprüft auf einen anderen.

Wofür Websites und Unternehmen APIs nutzen

Beginnen Sie mit einer konkreten manuellen Tätigkeit oder einem Datenverlust. „Alle Systeme verbinden“ beschreibt kein Projektergebnis. Eine hilfreiche Anforderung lautet: Jede bestätigte Website-Anfrage erscheint in der richtigen CRM-Pipeline, hat eine Quelle und eine zuständige Person; nicht übertragene Anfragen sind im Protokoll sichtbar.

Dies sind Anwendungsbeispiele und keine Zusage, dass der gewählte Dienst jedes Feld unterstützt. Bei manchen Produkten ist die API nur in bestimmten Tarifen verfügbar oder deckt nur einen Teil der Bedienoberfläche ab. Eine Vorprüfung gehört zu der CRM-Einführung, der Website-Entwicklung und der Entwicklung von KI-Agenten.

Was Sie in Dokumentation und Auftrag prüfen sollten

Lassen Sie sich die Dokumentation der benötigten Operation und einen kleinen Prüffall zeigen. Die pauschale Formulierung „Integration per API“ lässt im Auftrag zu viel Interpretationsspielraum. Halten Sie Folgendes fest:

• Systeme und Objekte. Welches CRM und welche Website-Version beteiligt sind und was als Anfrage, Bestellung oder Kunde gilt.
• Richtung. Nur Website → CRM oder auch Statusänderungen in Gegenrichtung. Ein bidirektionaler Austausch benötigt Regeln zur Konfliktlösung.
• Verbindliche Datenquelle. Wo Preise bearbeitet werden und welches System bei Abweichungen maßgeblich ist.
• Felder und Stammdaten. Zuordnung der Namen, Pflichtfelder, Datentypen, zulässige Werte, Währung und Zeitzone.
• Zeitpunkt des Austauschs. Direkt nach einem Ereignis, nach Zeitplan oder manuell; die zulässige Verzögerung.
• Datenvolumen. Normale Last, Spitzenlast und die erste Übertragung vorhandener Datensätze.
• Fehler. Was automatisch wiederholt wird, was an die zuständige Person geht und wie die Warteschlange wiederhergestellt wird.
• Betrieb. Wer nach dem Start für Zugangsdaten, Dokumentation und Support verantwortlich ist.

Prüfen Sie bei Listen die Paginierung, also die Aufteilung der Ergebnisse auf Seiten. Ein erfolgreicher Abruf der ersten 100 Datensätze bedeutet nicht, dass alle 8.000 übertragen wurden. Der Austausch von Änderungen benötigt Kontrollmarken und einen klaren Weg, einen verpassten Zeitraum erneut abzurufen. Die genauen Parameter stehen in der Dokumentation des Anbieters.

Was API-Fehler bedeuten

Ein HTTP-Statuscode beschreibt das Ergebnis einer Anfrage auf Protokollebene. Die Nachricht im Antwortkörper und das Integrationsprotokoll helfen bei der Ursachenanalyse. Kein Code allein belegt, dass der Geschäftsprozess korrekt abgeschlossen wurde. Die wichtigsten Werte erläutert die HTTP-Referenz von MDN.

Halten Sie für den Support Uhrzeit mit Zeitzone, Vorgang, Anfragekennung, Statuscode, anonymisiertes Beispiel und erwartetes Ergebnis fest. Fügen Sie kein produktives Zugangsgeheimnis bei. Die Aussage „funktioniert manchmal nicht“ verlängert ohne diese Angaben die Fehlersuche.

Ein Sonderfall liegt vor, wenn der Browser wegen CORS das Lesen der Antwort blockiert. Das ist eine Beschränkung des Zugriffs zwischen unterschiedlichen Ursprüngen und kein Beleg dafür, dass die API für alle Clients unerreichbar ist. Den Verbindungsweg sollte ein Entwickler prüfen. Den Browserschutz der Besucher abzuschalten, behebt die Integration nicht.

Warum eine erfolgreiche Anfrage noch wenig aussagt

Ein Lehrbeispiel: Das CRM hat eine Anfrage angelegt, doch die Antwort ging unterwegs verloren. Die Website erkennt eine Zeitüberschreitung und sendet dieselbe Anfrage erneut. Erkennt die Integration die Wiederholung nicht, erhält der Vertrieb zwei Datensätze. Eine Zeitüberschreitung bedeutet, dass beim Client nicht rechtzeitig eine Antwort einging. Sie garantiert nicht, dass die Aktion auf dem Server abgebrochen wurde.

Für solche Fälle wird ein Schutz vor Duplikaten vorgesehen: durch eine stabile externe Kennung, einen vom Dienst unterstützten Idempotenzschlüssel oder einen anderen vereinbarten Mechanismus. Idempotenz bedeutet, dass die Wiederholung derselben Operation keine zusätzliche Wirkung über die erste Ausführung hinaus hat. Ein beliebig hinzugefügter Header mit diesem Namen sorgt nicht dafür, dass eine fremde API diese Eigenschaft unterstützt.

• Wiederholungen sind begrenzt. Es gibt Wartezeiten, eine maximale Anzahl von Versuchen und einen eigenen Ablauf für nicht behebbare Fehler.
• Die Warteschlange bleibt erhalten. Nach einem Neustart des Prozesses bleiben nicht übertragene Ereignisse sichtbar und können verarbeitet werden.
• Die Reihenfolge wird berücksichtigt. Ein alter Status darf keinen neueren bestätigten Zustand überschreiben.
• Es gibt einen Datenabgleich. Ein Kontrollabgleich der Datensätze deckt Verluste auf, die im üblichen Fehlerprotokoll nicht erfasst wurden.
• Eine verantwortliche Person ist benannt. Eine Fehlermeldung erreicht eine Person, die das Wiederherstellungsverfahren kennt.

Prüfen Sie die Zuverlässigkeit mit kontrollierten Szenarien in einer Testumgebung. Für eine Demonstration müssen auf der produktiven Website keine massenhaften Fehler erzeugt werden. Prüfen Sie bei umfangreichen Exporten gesondert, ob sie nach einer Unterbrechung fortgesetzt werden können und bereits abgeschlossene Teile nicht erneut verarbeitet werden.

Schlüssel und Berechtigungen richtig verwalten

Ein geheimer Schlüssel oder Token ermöglicht den Zugriff und ist keine dekorative Einstellung. Seine Berechtigungen müssen zum Vorgang passen: Zum Lesen eines Katalogs ist keine Erlaubnis zum Löschen von Bestellungen nötig. Trennen Sie Produktiv- und Testumgebung und dokumentieren Sie den Kontoinhaber sowie das Verfahren zum Austausch der Zugangsdaten.

Serverseitige Geheimnisse gehören nicht in öffentliches JavaScript, HTML, Screenshots oder Repositories. Manche Dienste stellen ausdrücklich öffentliche Browserschlüssel bereit. Verwenden Sie diese ausschließlich nach den Regeln des Anbieters und mit den vorgesehenen Einschränkungen. Ein Schlüssel kann nicht allein deshalb sicher veröffentlicht werden, weil die Website ihn benötigt.

Ein gültiger Token ersetzt nicht die Prüfung der Berechtigung für ein konkretes Objekt. Wer die eigene Bestellung ansehen darf, darf durch Austauschen einer Kennung keine fremde Bestellung abrufen können. Fehler bei dieser Kontrolle gehören zu den Risiken in der Risikoliste von OWASP API Security. Lassen Sie bei der Abnahme sowohl erlaubte als auch verbotene Szenarien mit Testkonten prüfen.

Kennungen und Fehlerbeschreibungen sind im Protokoll hilfreich; vollständige Kundenkontaktdaten und Geheimnisse werden häufig nicht benötigt. Vereinbaren Sie den Umfang der übertragenen Daten, den Zugriff auf Protokolle und ihre Aufbewahrungsdauer. Legen Sie bei einer KI-Integration gesondert fest, welche Informationen überhaupt an den gewählten Anbieter übermittelt werden dürfen.

Eine Integration vom Entwickler abnehmen

Lassen Sie sich den vollständigen Weg eines Testobjekts zeigen. Bei einer Anfrage sind das Formular, Speicherung auf der Website, Übertragung, CRM-Datensatz und Zuweisung einer verantwortlichen Person. Vergleichen Sie die Werte im Zielsystem. Eine Browsermeldung und der Status HTTP 200 ersetzen diese Prüfung nicht.

Halten Sie im Prüfprotokoll die konkreten Kennungen der Testobjekte, Datum, Ergebnis und offene Punkte fest. Vereinbaren Sie messbare Anforderungen wie zulässige Verzögerung, Volumen und Wiederherstellungszeit vorab für das Projekt. Eine allgemeine Vorgabe wie „Die API muss innerhalb einer Sekunde antworten“ gilt nicht für sämtliche Vorgänge.

Lassen Sie sich nach der Demonstration die Beschreibung des Datenaustauschs, Anleitungen für Start und Wiederherstellung, Protokollzugriff und Supportverfahren übergeben. Den allgemeinen Ablauf der Projektübergabe erläutert der Leitfaden zur Website-Abnahme. Für die Verbindung von Website und CRM hilft außerdem der Plan zur CRM-Einführung.

Was vor dem Start festzuhalten ist

Häufige Fragen zu APIs