Schnittstelle programmieren lassen: Ablauf, Kosten, Fallstricke

Schritt 1: Gibt es schon eine App?

Bevor eine Zeile Code entsteht, lohnt der Blick in die App Stores und Erweiterungen Ihrer Programme. Zwei Beispiele (abgerufen am 17.10.2026): Im Shopify App Store gibt es mehrere Apps, die Bestellungen als DATEV-Buchungsstapel exportieren (Suche im App Store). Lexware Office importiert wiederkehrende Rechnungen über Schnittstellen zu Diensten wie GetMyInvoices oder fileee (Lexware).

Dazwischen liegen Workflow-Werkzeuge wie Zapier, Make und n8n. Sie verbinden Programme über fertige Bausteine, ohne dass jemand programmiert. Beim Datenort unterscheiden sie sich: Zapier speichert Daten nach eigener Angabe bei Amazon Web Services in den USA (Zapier), bei Make wählen Sie beim Anlegen einer Organisation ein Rechenzentrum in den USA oder in der EU, nachträglich lässt es sich nicht ändern (Make). n8n lässt sich auf eigenen Servern betreiben (n8n); der Code steht unter der Sustainable Use License, die unter anderem die Nutzung für eigene interne Geschäftszwecke erlaubt (Lizenz). Ob einer dieser Wege für Ihre Daten genügt, ist eine Datenschutzfrage, die Sie im Einzelfall prüfen lassen sollten.

Schritt 2: Den Datenfluss aufschreiben

Der wichtigste Schritt kostet nur etwas Nachdenken. Schreiben Sie für jeden Datenfluss auf, was wann von wo nach wo geht. Ein Beispiel für Bestellungen aus einem Onlineshop, die in die Buchhaltung sollen:

Warum der Datenfluss Angebote vergleichbar macht

Mit dieser Tabelle können zwei Anbieter dasselbe anbieten. Ohne sie schätzt jeder einen anderen Umfang, und der günstigste Preis ist oft der mit den wenigsten Ausnahmen. Die Frage nach dem führenden System klingt technisch, entscheidet aber, wo jemand eine Änderung macht und wo sie nur ankommt. Ist das offen, entstehen später zwei Wahrheiten.

Schritt 3: Fehlerfälle festlegen

Der Normalfall ist schnell gebaut. Aufwand und Ärger entstehen in den Fällen, in denen etwas schiefgeht. Typische Fallstricke:

• Die Gegenseite ist nicht erreichbar: Wartung, Ausfall oder abgelaufene Zugangsdaten. Vorgänge müssen zwischengespeichert und wiederholt werden.
• Anfragegrenzen: Viele Schnittstellen begrenzen die Zahl der Anfragen. Die Lexware-API erlaubt zwei Anfragen pro Sekunde und antwortet darüber mit dem Status 429 (Lexware). Wer Tausende alte Belege nachträglich überträgt, muss das einplanen.
• Versionen laufen aus: Shopify veröffentlicht alle drei Monate eine neue API-Version und unterstützt jede stabile Version mindestens zwölf Monate (Shopify). Eine Schnittstelle, die niemand pflegt, läuft irgendwann gegen eine abgeschaltete Version.
• Adressen ändern sich: Lexware hat das Gateway seiner API am 26. Mai 2025 umgestellt, die bisherige Adresse blieb bis Dezember 2025 erreichbar (Lexware).
• Doppelte Übertragung: Wird ein Vorgang wiederholt, darf keine zweite Rechnung entstehen. Dafür braucht jeder Vorgang eine eindeutige Kennung.
• Unvollständige Daten: Eine Adresse ohne Hausnummer oder ein unbekannter Steuersatz gehören in eine Prüfliste, statt den ganzen Lauf abzubrechen.
• Rundung: Rabatte über mehrere Positionen und gemischte Steuersätze führen zu Cent-Differenzen, wenn beide Seiten anders runden.

Für jeden Fehlerfall eine Entscheidung

Ins Konzept gehört für jeden Fehlerfall eine von drei Antworten: Wird automatisch wiederholt, landet der Vorgang in einer Prüfliste, oder bekommt jemand sofort Bescheid? Wer das vorher festlegt, erlebt im Betrieb weniger Überraschungen. In unserer Demo zur Bestellautomatisierung sehen Sie, wie Ausnahmen wie eine fehlende Hausnummer oder ein Bestellwert über der Freigabegrenze in einer manuellen Prüfung landen. Die Demo ist eine Simulation ohne angeschlossene Systeme.

Aufwand: drei Beispiele ohne Preisschild

Pauschale Euro-Beträge für eine Schnittstelle sagen wenig, weil zwei Schnittstellen mit gleichem Namen sehr unterschiedlich viel Arbeit machen. Die drei Beispiele zeigen, wovon der Aufwand abhängt:

Wovon die Kosten abhängen

• Zahl der Systeme und Richtungen: Ein Export in eine Richtung ist kleiner als ein Abgleich in beide Richtungen.
• Qualität der Programmierschnittstellen: Gibt es eine gute Dokumentation, einen Testzugang und Benachrichtigungen bei Änderungen (Webhooks), oder muss regelmäßig abgefragt werden?
• Ausnahmen und Freigaben: Jede Ausnahme braucht eine Regel, eine Prüfliste oder eine Benachrichtigung.
• Altdaten: Sollen bestehende Daten einmalig übernommen werden, kommt eine Datenmigration dazu.
• Datenmenge und Takt: Echtzeit ist aufwendiger als ein nächtlicher Lauf.
• Laufende Kosten: Betrieb, Überwachung, Anpassung an neue API-Versionen und gegebenenfalls Gebühren für Apps oder Werkzeug-Tarife.

Schritt 4: In Etappen bauen und testen

1. 1Testzugänge besorgen: Viele Anbieter haben Testumgebungen. Ohne Testzugang wird mit Echtdaten getestet, und das muss abgesprochen sein.
2. 2Normalfall zuerst: eine Richtung, ein Datentyp, mit Testdaten.
3. 3Ausnahmen danach: Wiederholung, Prüfliste, Benachrichtigung, so wie im Konzept festgelegt.
4. 4Parallelbetrieb: Eine Zeit lang laufen alter und neuer Weg nebeneinander, die Ergebnisse werden verglichen.
5. 5Abnahme: erst wenn der Vergleich stimmt, wird umgestellt.

Schritt 5: Betrieb und Überwachung

Eine Schnittstelle ist nie fertig. Programmierschnittstellen bekommen neue Versionen, Zugangsdaten laufen ab, Datenmengen wachsen. Zum Betrieb gehören ein Protokoll mit jedem Schritt, eine Benachrichtigung bei Fehlern, eine Statusanzeige und jemand, der zuständig ist.

Auch Workflow-Werkzeuge bringen dafür etwas mit: n8n startet bei einem Fehler einen eigenen Fehler-Workflow (n8n), Make kennt Fehlerbehandler wie Retry und Rollback (Make). Wie eine Statusseite mit echten Messwerten aussieht, zeigt unsere Statusseite, die alle 5 Minuten misst.

Fragen an jeden Anbieter

• Gibt es eine fertige App für unseren Fall, und warum reicht sie nicht?
• Welches System ist führend, und was passiert bei widersprüchlichen Daten?
• Was passiert, wenn eine Seite nicht erreichbar ist, und wie erfahren wir davon?
• Wie wird verhindert, dass ein Vorgang doppelt übertragen wird?
• Wo laufen die Daten, und gibt es einen Auftragsverarbeitungsvertrag?
• Wer passt die Schnittstelle an, wenn ein Anbieter seine API ändert, und zu welchen Bedingungen?
• Ist der Preis fest oder nach Aufwand, und was ist genau enthalten?
• Was bekommen wir am Ende: Dokumentation, Zugänge, Rechte am Quellcode?

So gehen wir vor

Im Erstgespräch sehen wir uns Ihre Programme und Handgriffe an und sagen, ob eine fertige App reicht. Wenn nicht, schreiben wir den Datenfluss mit Ihnen auf, legen die Fehlerfälle fest und nennen einen Festpreis je Etappe, bevor Code entsteht. Auf Wunsch betreiben wir die Schnittstelle danach auf Servern in Deutschland. Was wir für Shop, Buchhaltung, Lager und CRM bauen, steht auf der Seite Schnittstellen und Automatisierung entwickeln lassen.