Plattformen / 01
REST-API vorhanden. Integration gesucht.
Die Dokumentation ist da, ein Testrequest funktioniert. Im Alltag fehlen trotzdem Daten oder es entstehen doppelte Datensätze. DataSource verbindet Ihre REST-API mit dem konkreten Geschäftsprozess und plant auch den Fall, dass die Antwort ausbleibt.
Die Ausgangslage
Ein erfolgreicher Request ist erst der Anfang.
Ein Portal soll Kunden aus einem ERP übernehmen. Die Systeme verwenden unterschiedliche IDs und Pflichtfelder. Das ERP liefert Ergebnisse seitenweise, das Portal begrenzt Schreibzugriffe. Ein manueller Export verdeckt diese Unterschiede, löst sie aber nicht.
Vor der Umsetzung prüfen wir die unterstützte API-Version, Datenmengen, Aktualitätsbedarf und den Zielvertrag. Ein OpenAPI-Dokument hilft; reale, anonymisierte Antworten und Fehlermeldungen sind ebenso wichtig.
Was DataSource übernimmt
Datenvertrag, Zugriff und Wiederanlauf.
Datenvertrag
Quell- und Zielfelder, Identitäten, Datentypen und Pflichtwerte vereinbaren. Fehlende Werte und Änderungen am Schema erhalten definierte Regeln.
Zugriff und Transfer
Authentifizierung, Berechtigungsumfang und Token-Erneuerung entsprechend der API umsetzen. Pagination, Zeitlimits und die Reihenfolge abhängiger Objekte berücksichtigen.
Wiederanlauf
Übertragungsstand und externe IDs so führen, dass abgebrochene Läufe fortgesetzt werden können. Eine unklare Schreibantwort zunächst abgleichen, bevor erneut geschrieben wird.
Technisches Szenario / Illustratives Beispiel
Kunden abgleichen, ohne sie doppelt anzulegen.
Das Beispiel zeigt einen vorgeschlagenen Zielvertrag. Die externe Kunden-ID ist der fachliche Schlüssel. Ein Upsert und Idempotenzmechanismen müssen von der Ziel-API unterstützt oder in der Integration umgesetzt werden.
Beispieldaten und vorgeschlagene Regeln. Die konkreten Schnittstellen und Geschäftsregeln werden für Ihr Projekt geprüft.
PUT /customers/004218
Content-Type: application/json
{
"externalId": "004218",
"name": "Beispiel GmbH",
"countryCode": "AT"
}Fehlerbehandlung, Sicherheit und Betrieb
HTTP-Fehler richtig einordnen.
Rate Limits
Bei HTTP 429 die API-Vorgaben und gegebenenfalls Retry-After beachten. Begrenzte Wiederholungen mit Backoff einplanen; dauerhafte Validierungsfehler brauchen eine Korrektur.
Änderungskonflikte
ETags oder Versionsfelder nutzen, wenn unterstützt. Ein zwischenzeitlich geänderter Datensatz darf nicht durch einen alten Stand überschrieben werden.
Betrieb
Korrelations-IDs, Zähler und Fehlerkategorien dokumentieren. Tokens und vollständige personenbezogene Payloads gehören nicht in allgemeine Betriebslogs.
Fachliche Fragen
Details, die vor der Umsetzung zählen.
HTTP · REST · OAuth · API Keys · Pagination · Retry
Kann jede API einen Upsert ausführen?
Nein. Manche bieten nur getrennte Create- und Update-Endpunkte. Dann benötigt die Integration eine belastbare Zuordnung und ein Verfahren für unklare Ergebnisse.
Brauchen wir Echtzeit?
Das hängt vom Geschäftsprozess ab. Polling kann genügen; Webhooks sind sinnvoll, wenn die Quelle Änderungen zuverlässig meldet. Ein Abgleich bleibt für übersehene Ereignisse nützlich.
Was geschieht bei einer neuen API-Version?
Wir prüfen Verträge und repräsentative Fehlerfälle in einer Testumgebung. Deprecation-Fristen, Umstellung und Rückfallweg werden vor der Produktivänderung vereinbart.
Für die technische Klärung
Mit Ihrem konkreten Ablauf beginnen.
API-Dokumentation, Version, anonymisierte Beispiele, gewünschte Richtung und Aktualität mitbringen. Hilfreich sind bekannte Limits und die Frage, welches System welche Felder führt.
Im ersten Gespräch klären wir die verfügbaren Zugänge, Datenverantwortung und einen begrenzten ersten Datenfluss. Danach stimmen wir Umfang, Zuständigkeiten und Konditionen ab.
Projektanfrage
Welche APIs sollen zusammenarbeiten?
Beschreiben Sie kurz den aktuellen Ablauf und das gewünschte Ergebnis.
Verwandte Aufgaben
Die nächste Verbindung im Kontext.
Webhooks zuverlässig verarbeiten
Ein Ereignis trifft ein und soll im nächsten System eine Aktion auslösen. Mehrfachzustellung, Verzögerung oder eine ausgefallene Ziel-API machen daraus einen Betriebsprozess. Wir entwickeln diesen Ablauf mit eindeutigen Ereignissen und überprüfbaren Effekten.
JSON / XML Datentransformation
Die Daten sind technisch lesbar und werden trotzdem abgewiesen. Feldnamen, Typen oder Strukturen passen nicht zur Zielanwendung. Wir entwickeln nachvollziehbare Mappings, die auch leere Werte, Sonderfälle und Änderungen am Quellformat behandeln.
Daten zwischen Systemen synchronisieren
Ein Kunde wird im CRM geändert, im ERP ebenfalls. Welcher Stand gilt? Wir bauen die Synchronisation um fachliche Zuständigkeiten und stabile Identitäten, damit regelmäßige Übertragungen keine stillen Datenkonflikte erzeugen.
Technische Referenzen
Offizielle Dokumentation, geprüft am 6. Oktober 2026. Die Eignung hängt von der konkreten Installation und Version ab.