Schnittstelle programmieren lassen: was es wirklich kostet

Das Wort Schnittstelle deckt alles ab, vom Häkchen in einem Plugin bis zu einem Projekt über Monate. Wer fragt, was eine Schnittstelle kostet, bekommt deshalb zu Recht die Gegenfrage: zwischen welchen Systemen, in welche Richtung, wie oft, wie viele Daten?

Ein Beispiel, das auf viele kleine Firmen passt: Bestellungen aus dem Onlineshop sollen automatisch als Beleg im Buchhaltungsprogramm landen. Klingt nach einer Sache. Hinter der Frage stecken aber Steuersätze und Gutschriften, Rundungsdifferenzen und die Frage, was passiert, wenn die Buchhaltung gerade nicht erreichbar ist.

Drei Wege, zwei Systeme zu verbinden

Bevor du etwas programmieren lässt, prüf die zwei günstigeren Wege. Viele Shop- und Buchhaltungssysteme haben fertige Verbindungen, die man nur aktivieren muss. Und Automatisierungsdienste wie Zapier oder Make verbinden gängige Dienste per Klick, gegen eine monatliche Gebühr.

Kriterium	Fertige Integration	Automatisierungsdienst	Eigene Schnittstelle
Kosten am Anfang	gering	gering	hoch
Laufende Kosten	Abo oder Plugin-Lizenz	Monatsgebühr, steigt mit Menge	Betrieb und Pflege
Passt sich deinen Regeln an		teilweise
Gut bei großen Datenmengen	teilweise
Daten bleiben unter deiner Kontrolle	teilweise

Eine eigene Schnittstelle lohnt sich, wenn die fertigen Wege an deinen Sonderfällen scheitern, wenn die monatlichen Gebühren mit dem Volumen zu stark wachsen oder wenn du sensible Daten nicht über einen weiteren Dienst schicken willst.

Was den Preis einer Schnittstelle treibt

Sieben Fragen entscheiden darüber, ob eine Anbindung zwei Tage oder zwei Wochen dauert. Ein Entwickler wird sie dir alle stellen, also kannst du die Antworten gleich in die Auftragsbeschreibung schreiben.

1. Richtung: Fließen Daten nur von A nach B, oder müssen Änderungen in beide Richtungen abgeglichen werden? Beidseitig ist nicht doppelt so teuer, sondern oft mehr, weil Konflikte gelöst werden müssen.
2. Auslöser: Kann das Quellsystem per Webhook Bescheid geben, oder muss die Schnittstelle regelmäßig nachfragen?
3. Dokumentation: Gibt es eine öffentliche API-Dokumentation mit Beispielen und eine Testumgebung (Sandbox)? Ohne sie wird probiert, und Probieren kostet.
4. Anmeldung: Reicht ein API-Schlüssel, oder läuft die Anmeldung über OAuth 2.0 mit Zugriffstoken, die ablaufen und erneuert werden müssen?
5. Zuordnung: Wie werden Felder übersetzt? Artikelnummern, Steuersätze, Zahlungsarten und Länder heißen in jedem System anders.
6. Menge und Limits: Wie viele Vorgänge pro Tag? Öffentliche APIs begrenzen meist die Zahl der Anfragen pro Zeiteinheit, das steht in ihrer Dokumentation.
7. Fehlerfall: Was soll passieren, wenn eine Übertragung scheitert? Nochmal versuchen, jemanden benachrichtigen, protokollieren?

Punkt sieben wird gern unterschätzt, vom Auftraggeber wie im Angebot. Eine Schnittstelle, die bei einem Fehler still aufgibt, merkt niemand, bis beim Monatsabschluss zwanzig Belege fehlen.

Rechenbeispiel: Shop an Buchhaltung, einseitig

Die folgende Kalkulation zeigt, wie sich ein Angebot für eine überschaubare Anbindung zusammensetzen kann. Beide Systeme haben in diesem Beispiel eine gut dokumentierte API mit Testzugang. Die Stunden sind angenommen und dienen der Veranschaulichung.

API-Dokumentation lesen, Testzugänge einrichten (2 h)

180 €

Webhook für bezahlte Bestellungen empfangen (3 h)

270 €

Felder zuordnen: Steuersätze, Versand, Rabatte (4 h)

360 €

Beleg in der Buchhaltung anlegen (3 h)

270 €

Wiederholung bei Fehlern, Mail-Benachrichtigung, Protokoll (4 h)

360 €

Tests mit Sonderfällen, Übergabe, kurze Doku (4 h)

360 €

Netto, 20 Stunden

1.800 €

Angenommene Stunden für ein Beispiel mit zwei gut dokumentierten APIs, Stundensatz 90 € netto (Median laut freelancermap, Sept. 2026).

Was in diesem Beispiel fehlt: Gutschriften bei Retouren, Teilzahlungen, Bestellungen in Fremdwährung. Jeder dieser Fälle kann einige Stunden dazubringen. Klär deshalb vorher, welche Sonderfälle bei dir überhaupt vorkommen. Wer nie in Fremdwährung verkauft, muss dafür auch nichts bezahlen.

Ein beidseitiger Abgleich, etwa von Lagerbeständen zwischen Shop und Warenwirtschaft, liegt schnell beim Doppelten oder Dreifachen. Dann muss geklärt sein, welches System im Zweifel recht hat, wenn sich Bestände an beiden Stellen gleichzeitig ändern.

Was ein brauchbares Angebot enthalten sollte

Angebote für dieselbe Schnittstelle können sich um ein Vielfaches unterscheiden. Das liegt selten an Gier oder Dumping, sondern daran, dass jeder Anbieter andere Annahmen trifft. Der eine rechnet mit sauberer Fehlerbehandlung, der andere mit einem Skript, das im Fehlerfall einfach stehen bleibt. Vergleichbar werden Angebote erst, wenn diese Annahmen drinstehen.

Achte darauf, dass folgende Punkte ausdrücklich genannt sind:

• welche Daten in welche Richtung übertragen werden, mit Beispiel
• welcher Auslöser verwendet wird und mit welcher Verzögerung du rechnen musst
• welche Sonderfälle abgedeckt sind und welche ausdrücklich nicht
• wie Fehler gemeldet werden und an wen
• wo der Code läuft und wer diesen Ort bezahlt und betreut
• ob du den Quellcode bekommst und wer die Rechte daran hat
• Stundensatz für spätere Anpassungen

Der vorletzte Punkt wird gern vergessen. Ohne Quellcode und Nutzungsrechte bist du bei jeder Änderung an den ursprünglichen Entwickler gebunden. Was du dazu vereinbaren solltest, steht im Beitrag über Nutzungsrechte an Software.

Fehlt in einem Angebot die Fehlerbehandlung ganz, frag nach. Ein deutlich günstigeres Angebot ohne diesen Punkt ist nicht günstiger, es verschiebt die Kosten nur auf den Tag, an dem etwas schiefgeht.

Laufende Kosten nach dem Start

Eine Schnittstelle ist kein Möbelstück, das man einmal aufstellt. Sie hängt an zwei Systemen, die sich unabhängig von dir weiterentwickeln. Shopify etwa veröffentlicht laut seiner Entwicklerdokumentation alle drei Monate eine neue API-Version und unterstützt jede stabile Version mindestens zwölf Monate. Wer eine solche Anbindung betreibt, muss also mindestens einmal im Jahr prüfen, ob sie auf eine neuere Version umgestellt werden muss.

Typische laufende Posten:

• Betrieb: Server, Cloud-Funktion oder Plugin, auf dem der Code läuft
• Überwachung: Wer liest die Fehlermails, und was passiert im Urlaub?
• Anpassungen an neue API-Versionen beider Systeme
• Erweiterungen, wenn neue Zahlungsarten oder Steuersätze dazukommen

Lass dir im Angebot sagen, mit wie vielen Stunden pro Jahr der Entwickler für die Pflege rechnet und zu welchem Satz er sie übernimmt. Wie du Pauschale und Aufwand sinnvoll kombinierst, steht im Beitrag Festpreis oder Stundensatz.

Datenschutz und Zugänge nicht vergessen

Sobald Namen oder Adressen von Kunden durch die Schnittstelle fließen, geht es um personenbezogene Daten. Wer diese Daten in deinem Auftrag verarbeitet, sei es ein Automatisierungsdienst oder der Entwickler beim Testen, braucht einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO. Bei Diensten mit Sitz außerhalb der EU kommt die Frage dazu, auf welcher Grundlage die Daten dorthin übermittelt werden.

Für die Entwicklung braucht der Programmierer API-Schlüssel beider Systeme. Leg dafür eigene Schlüssel an, die du später widerrufen kannst, statt deine persönlichen weiterzugeben. Wie das praktisch geht, erklärt der Beitrag Zugangsdaten sicher weitergeben.

Woran du merkst, dass es kein kleiner Auftrag mehr ist

Drei Systeme statt zwei. Abgleich in beide Richtungen. Tausende Vorgänge pro Tag. Oder ein Prozess, bei dem ein Fehler direkt Geld kostet, etwa falsche Lagerbestände im Shop. Dann reicht ein Skript, das jemand an zwei Abenden schreibt, nicht mehr. Wer Schnittstellen dieser Größe nicht nur bauen, sondern auch dauerhaft betreiben lassen will, kann sich an ein Team wie OnlineBuilders wenden.

Für kleinere Vorhaben: Schreib die sieben Fragen von oben mit deinen Antworten auf, leg die Links zu den API-Dokumentationen beider Systeme dazu und formuliere zwei prüfbare Akzeptanzkriterien. Mit diesem Paket bekommst du Angebote, die sich vergleichen lassen.

Häufige Fragen

Lohnt sich ein Automatisierungsdienst statt einer programmierten Schnittstelle?

Für geringe Mengen und einfache Abläufe oft ja. Du zahlst eine Monatsgebühr statt einer Entwicklung und kannst selbst Anpassungen vornehmen. Bei vielen Vorgängen, komplexen Regeln oder sensiblen Daten wird eine eigene Lösung meist günstiger und kontrollierbarer.

Was ist der Unterschied zwischen Webhook und Abfrage im Intervall?

Beim Webhook meldet das Quellsystem selbst, dass etwas passiert ist, etwa eine neue Bestellung. Bei der Abfrage im Intervall fragt deine Schnittstelle zum Beispiel alle zehn Minuten nach, ob es Neues gibt. Webhooks sind schneller und sparsamer, aber nicht jedes System bietet sie an.

Brauche ich für eine Schnittstelle einen Server?

Meistens ja, irgendwo muss der Code laufen. Das kann der vorhandene Webserver sein, eine kleine Cloud-Funktion oder ein Plugin im Shop-System. Kläre vorher, wer diesen Teil betreibt und überwacht.

Muss ich bei einer Schnittstelle an den Datenschutz denken?

Ja, sobald personenbezogene Daten wie Kundennamen oder Adressen übertragen werden. Wer diese Daten in deinem Auftrag verarbeitet, braucht einen Vertrag nach Art. 28 DSGVO, und bei Diensten außerhalb der EU kommt die Frage des Drittlandtransfers dazu.