CSV, XML, API oder FTP: den richtigen Lieferantendatenfluss wählen

Wählen Sie den Datenfluss, der die benötigten Felder mit nachvollziehbarer Aktualisierung und sicherer Wiederaufnahme liefert – nicht denjenigen, dessen Name am modernsten klingt. Eine vollständige, täglich abgelegte CSV-Datei kann einer API ohne Zeitstempel oder verlässliche Paginierung vorzuziehen sein. Eine API wird interessant bei häufigen Änderungen und gezielten Abfragen; XML eignet sich für verschachtelte, dokumentierte Strukturen; FTP ist ein Übertragungskanal, oft zum Ablegen von Dateien genutzt, kein Katalogformat. Prüfen Sie vor der Entscheidung Dokumentation, Volumen, Limits, Zugangsdaten, Preis, Bestand, Sicherheit und Verhalten bei Unterbrechungen.

Format, Transport und Zugangsvertrag trennen

CSV und XML beschreiben in erster Linie eine Datenrepräsentation. HTTP und FTP beschreiben Austauschmechanismen. Eine „JSON-API" kombiniert in der Regel einen Anwendungsvertrag, JSON-Dokumente und einen HTTP-Transport. Ein „FTP-Feed" kann eine CSV-, eine XML-Datei, ein Archiv oder mehrere Dateien enthalten. Diese Ebenen zu vermischen führt zu falschen Vergleichen.

RFC 4180 dokumentiert ein gebräuchliches CSV-Format und dessen MIME-Typ. Sie beschreibt unter anderem Zeilen, Trennzeichen und die Maskierung von Feldern in Anführungszeichen, definiert aber nicht die Spalten price, stock oder ean. Die XML-Empfehlung des W3C legt die Syntax und Wohlgeformtheit von XML-Dokumenten fest; auch sie liefert nicht das fachliche Schema des Lieferanten. In beiden Fällen bleibt die Dokumentation des Herausgebers unverzichtbar.

FTP, historisch durch RFC 959 standardisiert und durch spätere Aktualisierungen ergänzt, dient der Dateiübertragung zwischen Hosts. Seine Existenz bedeutet weder, dass die Verbindung verschlüsselt ist, noch dass der Inhalt aktuell ist. Prüfen Sie das tatsächlich angebotene Protokoll, die Authentifizierungsmethode, die Transportabsicherung und die Rotationsrichtlinie für Zugangsdaten, ohne Geheimnisse in Protokollen offenzulegen.

Eine faktenbasierte Auswahlmatrix

Diese Matrix bewertet keine Technologie absolut. Sie soll die Fragen sichtbar machen, die der Lieferant dokumentieren muss. Ein Datenfluss sollte anhand konkreter Nachweise beurteilt werden: Beispielantwort, Datenverzeichnis, angekündigter Rhythmus, Nutzungsbedingungen, Wiederaufnahmeverfahren und Ansprechpartner bei Störungen.

Die wirklich entscheidenden Kriterien

Fachliche Vollständigkeit

Listen Sie die nicht verhandelbaren Felder auf, bevor Sie über Technologie diskutieren: Produkt- und Variantenkennung, SKU, Marke, Titel, Preis, Währung, netto/brutto-Angabe, Bestand mit Genauigkeitsgrad, Verkaufseinheit, MOQ, Bestellschrittweite, Bild und Zeitstempel. Nutzen Sie das Raster der Spalten eines Großhändler-Katalogs, damit eine technische Vorführung nicht das Fehlen eines wesentlichen Datenpunkts verdeckt.

Aktualität und Änderungsnachweis

Fragen Sie, ob der Datenfluss vollständig oder inkrementell ist. Suchen Sie bei einer Volldatei nach einem Erstellungsdatum und einem Mechanismus, der ein Lesen vor Abschluss der Ablage verhindert. Dokumentieren Sie bei einer API die Paginierung, die stabile Sortierung, die Cursor und die Semantik von Löschungen. Die HTTP-Felder ETag und Last-Modified, definiert in RFC 9110, sind Validatoren, deren Vorhandensein und Bedeutung jedoch vom Server abhängen. Sie ersetzen keinen fachlichen Zeitstempel für Preis oder Bestand.

Die Vertrauensfrist für Preise und Bestände sollte anhand des geschäftlichen Risikos gewählt werden. Ein Merkmalskatalog kann sich langsam ändern; eine Verfügbarkeit kann sich zwischen zwei Bestellungen ändern. Für beide Datenfamilien passt nicht zwangsläufig derselbe Zyklus.

Wiederaufnahme und Idempotenz

Simulieren Sie eine Unterbrechung. Können Sie an der nächsten Seite fortsetzen, ohne Produkte zu verpassen oder zu duplizieren? Trägt eine Datei einen temporären Namen, bevor sie als vollständig markiert wird? Liefert eine API eine stabile Kennung und Reihenfolge? Aktualisierungen müssen idempotent sein: Das erneute Abspielen desselben Dokuments darf Angebote nicht vervielfachen.

Archivieren Sie den Hash des akzeptierten Inhalts, das Erfassungsdatum, die URL oder den Dateinamen sowie die Parser-Version. Diese Nachvollziehbarkeit zeigt, ob eine Abweichung vom Lieferanten oder von Ihrer eigenen Transformation stammt.

Sicherheit und Rechte

Platzieren Sie niemals einen API-Schlüssel im Code, in der erzeugten CSV-Datei oder in einer Fehlermeldung. Beschränken Sie Zugriffe auf den nötigen Umfang und befolgen Sie das Rotationsverfahren des Lieferanten. Prüfen Sie auch die Lizenz oder Nutzungsbedingungen: Eine technisch zugängliche Ressource ist nicht automatisch für die kommerzielle Weiterverwendung freigegeben. RFC 9309 erinnert zudem daran, dass robots.txt keine Zugriffserlaubnis darstellt.

Neunstufiger Auswahltest

1. Offizielle Dokumentation und Nutzungsbedingungen einholen. 2. Pflichtfelder und ihre Definition auflisten. 3. Eine kleine Stichprobe mit Varianten, Ausverkäufen und leeren Werten prüfen. 4. Volumen messen und Paginierung oder Dateiaufteilung verstehen. 5. Frequenz, Zeitstempel und Änderungssignale ermitteln. 6. Einen kontrollierten Fehler auslösen und Code, Meldung und Wiederaufnahme beobachten. 7. Denselben Auszug erneut abspielen, um Duplikate auszuschließen. 8. Daten mit autorisierten offiziellen Datenblättern vergleichen. 9. Eine Kanarien-Charge des Lieferanten starten, bevor das Volumen erhöht wird.

Erstellen Sie am Ende eine Entscheidungsübersicht mit drei Spalten: „nachgewiesen", „nicht geliefert" und „zu bestätigen". Der Begriff „unterstützt" sollte nur verwendet werden, wenn ein Test oder eine offizielle Dokumentation dies belegt.

Anbindungs-Checkliste

• ☐ Format und Transport sind getrennt identifiziert.
• ☐ Das fachliche Schema und die Einheiten sind dokumentiert.
• ☐ Paginierung, Kontingente und Volumen wurden getestet.
• ☐ Der Erstellungszeitstempel ist verfügbar oder als fehlend markiert.
• ☐ Eine Wiederaufnahme nach Unterbrechung wurde geprüft.
• ☐ Löschungen und Ausverkäufe haben eine klare Semantik.
• ☐ Geheimnisse bleiben außerhalb von Dateien und Protokollen.
• ☐ Die Bedingungen erlauben die vorgesehene Nutzung.
• ☐ Rohantworten und ihre Hashes sind archiviert.
• ☐ Der Kanarien-Test besteht vor dem vollständigen Import.

Was ArbitragePro+ automatisieren kann / was der Verkäufer prüfen muss

Die vorgeschlagene Spezifikation diagnostic-flux könnte Struktur, Typen, Paginierung, Stabilität der Kennungen, Hashes und Fehler einer Kanarien-Charge prüfen. Sie könnte die gelieferten Felder mit den erklärten Anforderungen abgleichen, ohne den Vertrag des Lieferanten zu definieren.

Der Verkäufer muss die autorisierte Quelle wählen, die Zugänge beschaffen, die Steuerbasis und Einheiten bestätigen, die Kanalsicherheit bewerten und dann prüfen, ob die Frequenz zu seinem Bestellmodell passt.

Die passende Anbindung ermitteln

Die von ArbitragePro+ überwachten Sources ansehen, um die verfügbaren Informationen zu jeder Verbindung zu prüfen.

Offizielle Quellen

• IETF, RFC 4180, „Common Format and MIME Type for CSV Files", https://www.rfc-editor.org/info/rfc4180/ — abgerufen am 17.08.2026.
• W3C, „Extensible Markup Language (XML) 1.0", https://www.w3.org/TR/xml/ — abgerufen am 17.08.2026.
• IETF, RFC 9110, „HTTP Semantics", https://www.rfc-editor.org/rfc/rfc9110.html — abgerufen am 17.08.2026.
• IETF, RFC 959, „File Transfer Protocol", https://www.rfc-editor.org/info/rfc959/ — abgerufen am 17.08.2026.
• IETF, RFC 9309, „Robots Exclusion Protocol", https://www.rfc-editor.org/rfc/rfc9309.html — abgerufen am 17.08.2026.