API oder EDI? Die richtige Anbindung für jeden Partner

Zwei Kunden onboarden Sie im selben Monat. Der eine schickt einen vierzig Seiten starken EDI-Implementierungsleitfaden mit einer Directory-Version auf dem Deckblatt. Der andere fragt in einer einzigen E-Mail-Zeile, ob Sie eine API haben.

Es ist verlockend, das als eine einzige Frage mit einer einzigen Antwort zu behandeln: eine Anbindung wählen, alle darauf verpflichten. Dieser Instinkt erzeugt entweder ein EDI-Projekt, das Sie sich nicht leisten können, oder eine API, die niemand aus Ihrem Netzwerk je aufrufen wird. Es sind keine konkurrierenden Antworten auf eine Frage. Sie beantworten unterschiedliche Fragen, und welche passt, hängt weit mehr von der Größe und den Gewohnheiten des Geschäftspartners ab als von irgendetwas Technischem.

Der Unterschied liegt in der Semantik, nicht nur in der Technik

Beide übertragen einen Transportauftrag von ihrem System in Ihres, ohne dass jemand etwas erneut eintippt. Der Unterschied liegt in der Arbeitseinheit – und darin, wer wartet.

Die Arbeitseinheit von EDI ist die Interchange: eine Datei, in eine Hülle verpackt, die eine oder mehrere Nachrichten enthält und nach Zeitplan oder bei vollem Stapel verschickt wird. Niemand ist online, wenn sie ankommt. Das Format im europäischen Straßengüterverkehr ist meist UN/EDIFACT, über die UNECE als versionierte Directories veröffentlicht, und der Nachrichtensatz ist festgelegt. IFTMIN, die Instruction-Message, trägt den Auftrag. IFTSTA, die International Multimodal Status Report Message, meldet den Status zurück. INVOIC, die Invoice-Message, stellt die Zahlung in Rechnung. Weil niemand wartet, werden Probleme im Nachhinein über eigene Nachrichten gemeldet: CONTRL, die Syntax and Service Report Message, bestätigt oder weist die empfangene Interchange selbst zurück, und APERAK, die Application Error and Acknowledgement Message, meldet, dass die Anwendung des Empfängers die Nachricht erhalten und bei der Verarbeitung zurückgewiesen hat. Der EDI-Artikel geht diesen Nachrichtensatz im Detail durch.

Die Arbeitseinheit einer API ist der Request. Die Software der Gegenseite ruft Ihre auf und wartet auf die Antwort. Die Validierung erfolgt beim Absenden – eine fehlende Postleitzahl kommt als Ablehnung zum Aufrufer zurück, der sie noch korrigieren kann, statt als Bestätigungsnachricht eine Stunde später, adressiert an wer auch immer dieses Postfach liest. Die Gegenrichtung ist ein Webhook: Ihr System ruft die Gegenseite auf, wenn etwas passiert, statt dass diese eine Statusdatei nach Zeitplan abholt.

Diese Unterscheidung entscheidet fast alles Weitere.

Wofür EDI wirklich gut ist

Es ist so sehr eine Vereinbarung wie ein Format. Der Leitfaden, das Code-Mapping und die Bestätigungsregeln sind der teure Teil – und zugleich der dauerhafte. Sobald diese Vereinbarung steht, ist das Volumen darüber fast kostenlos.

Die Gegenseite hat es bereits. Ein großer Verlader hat Mitarbeitende, deren Job es ist, EDI-Partner anzubinden. Dieselben Mitarbeitenden bekommen meist kein Budget, um einen individuellen Client für die API eines einzelnen Spediteurs zu schreiben. Ihre API ist Ihr Projekt; deren EDI ist deren Prozess – und Prozesse gewinnen.

Batch-Semantik passt zu Kontraktfracht. Wiederkehrendes, vorhersehbares Volumen, das eine Latenz von Minuten toleriert, ist genau das, wofür eine Interchange gedacht ist.

Es überlebt die Person, die es eingerichtet hat. Eine Directory-Version und ein schriftlicher Leitfaden sind Dokumente. Der Entwickler, der sie verdrahtet hat, wird irgendwann wechseln; die Dokumente bleiben, und die nächste Person kann sie lesen.

Wofür eine API wirklich gut ist

Sie ist günstig aufzusetzen. Kein Leitfaden zum Verhandeln, keine Directory-Version, auf die man sich einigen muss. Keys, Endpunkte, Dokumentation – Tage statt eines Quartals.

Sie ist interaktiv. Der Fehler landet bei der Person, die ihn verursacht hat, während die Buchung noch auf ihrem Bildschirm steht. Allein diese Eigenschaft erledigt eine ganze Kategorie von Freitagnachmittagen: die abgelehnte Datei, die bis Montag niemand ansieht.

Sie bedient den Long Tail. Ein Kunde, der eine Handvoll Ladungen pro Woche schickt, kann ein Skript, ein Formular oder sein eigenes Backoffice daran anschließen, ohne ein Projekt daraus zu machen.

Sie bedient auch Ihre eigenen Ränder. Das Kundenportal, die Fahrer-App, das Excel-Makro, das jemand im Büro geschrieben hat – all das sind API-Clients, was bedeutet, dass sich die API rentiert, bevor überhaupt ein externer Partner sie aufruft.

Der ehrliche Kompromiss: Die Flexibilität einer API ist zugleich ihre Instabilität. Nichts erzwingt Versionsdisziplin so wie ein veröffentlichtes Directory, also tragen Sie die Verantwortung für Abwärtskompatibilität, solange irgendjemand sie aufruft. Und eine API anzubieten verlagert die Integrationsarbeit auf den Kunden – der womöglich niemanden hat, der sie erledigt. Wir haben eine API ist keine Antwort für einen Partner, der gehofft hatte, dass Sie die Integration übernehmen.

Die Trennlinie verläuft danach, wer die Arbeit macht

Lässt man die Technik weg, bleibt die Frage: Welche Seite passt sich an etwas an, das die andere Seite bereits hat?

• Ein großer Verlader oder eine Handelskette. EDI, nach deren Leitfaden. Ihre Größe zahlt sich dafür aus, sie werden für einen einzelnen Spediteur nicht abweichen, und ein Nein ist eine kaufmännische Entscheidung, keine technische.
• Ein mittelständischer Kunde mit einer IT-Person, ein Broker oder eine Frachtplattform. In der Regel eine API. Sie sind in der Lage, eine aufzurufen, und haben keine EDI-Abteilung, die es zufriedenzustellen gilt.
• Ein kleiner Kunde. Sehr oft keins von beidem. Ein Kundenportal oder eine Dateiablage beantwortet, was er eigentlich will: in der Regel nichts erneut eintippen zu müssen und Sie nicht mehr wegen des Status anzurufen. Es lohnt sich, direkt nachzufragen – EDI erforderlich in einer Ausschreibung bedeutet manchmal genau das.

Keines davon ist ein Urteil darüber, welche Technik besser ist. Es sind Einschätzungen dazu, wo der Integrationsaufwand realistisch angesiedelt werden kann.

Warum beides normal ist, und was es bezahlbar macht

Zwei Anbindungen zu betreiben kostet nicht zwei Anbindungen. Es kostet zwei Versionen der Wahrheit, und das ist der teure Teil.

Eine Buchung, die als IFTMIN ankommt, und eine Buchung, die als API-Aufruf ankommt, müssen zum selben Datensatz werden – mit denselben Status, denselben Dokumenten und demselben Weg zur Rechnung. Bekommt jeder Kanal seine eigene Tabelle, sein eigenes Status-Vokabular und seine eigenen Ausnahmen, haben Sie zwei Systeme gekauft, und die Naht wird irgendwo kostspielig sichtbar – meist auf einer Rechnung, vor einem Kunden.

Die nützliche Frage an das System darunter lautet also nicht unterstützt es EDI oder hat es eine API. Sie lautet: Landen beide in derselben Buchung? Und ihr Gegenstück auf dem Weg hinaus – wenn ein Fahrer eine Zustellung als abgeschlossen markiert, wird aus diesem einen Ereignis dann eine IFTSTA für den Kunden, der EDI wollte, und ein Webhook für den Kunden, der eine API wollte, ohne dass es jemand zweimal erfasst?

Die Fragen, die für beide gelten

Welche Anbindung ein Partner auch bekommt, dieselben fünf Dinge entscheiden, ob sie dauerhaft funktioniert:

1. Wer bemerkt es, wenn sie ausfällt? Die Frage, die in jedem Integrationsgespräch übersprungen wird. Eine stille Anbindung ist schlimmer als keine, weil alle weiter davon ausgehen, dass die Aufträge fließen.
2. Was ist die Bestätigung, und sieht sie je ein Mensch? EDI hat CONTRL und APERAK; eine API hat Statuscodes und Fehler-Bodys. Beides ist nutzlos, wenn es nur ein Log erreicht, das niemand öffnet.
3. Wie lauten die Dublettenregeln? Eine erneut gesendete Datei und ein wiederholter Request sind dieselbe Gefahr: ein Auftrag, der zu zwei Ladungen wird. Beide Seiten brauchen eine vereinbarte Identität für einen Auftrag und eine Regel dafür, was passiert, wenn er zweimal ankommt.
4. Was ist die Ausweichlösung? Steht die Arbeit still, wenn die Verbindung ausfällt, oder gibt es einen E-Mail-Weg und eine Möglichkeit, im Nachhinein abzugleichen?
5. Wer zahlt, wenn die Gegenseite überarbeitet? Leitfäden werden aktualisiert, und APIs bekommen neue Pflichtfelder. Diese Arbeit macht nächstes Jahr jemand.

Beantworten Sie das pro Partner, und die Wahl der Anbindung hört auf, eine Identitätsfrage über Ihr Unternehmen zu sein, und wird zu dem, was sie ist: eine Entscheidung pro Geschäftsbeziehung, die neu getroffen wird, wenn sich die Beziehung ändert.

Wo navichain hineinpasst

Der Sinn des Systems darunter ist, dass der Kanal aufhört, eine architektonische Entscheidung zu sein, und zu einer Entscheidung pro Partner wird. navichain liefert eine REST-API für ERP- und TMS-Integration – API-Keys mit Berechtigungsbereichen für Buchungen, Organisationen, Tracking- und Dokument-Endpunkte, mit Webhooks, Ratenlimits und einem Audit-Trail zu jedem Aufruf – neben den Fracht-Partner-Integrationen, denen die meisten nordischen Unternehmen ohnehin schon begegnen: Opter, LogTrade, EDIFACT und Fraktjakt. Für Kunden, die keins von beidem brauchen, gibt es ein Kundenportal. All das fließt in einen einzigen Buchungsdatensatz, und weil jede Funktion in jedem Plan enthalten ist, bringt Sie ein zusätzlicher Partner auf einer anderen Anbindung nicht in eine höhere Preisstufe. Die Plattformseite zeigt, was enthalten ist, und die Preisseite ist eine einzige Seite ohne Zeile pro Integration.