Kosten einer API-Integration in einer App richtig einschätzen

Eine Schnittstelle ist ein laufender Datenvertrag

Eine API beschreibt, welche Daten ein System annimmt oder ausgibt. Die Integration muss darüber hinaus entscheiden, was diese Daten im Produkt bedeuten. Ein CRM kennt vielleicht „Kontakt“, die App dagegen „Privatkunde“, „Firmenadministrator“ und „Gast“. Eine korrekte Feldzuordnung ist daher Geschäftslogik, nicht bloß technische Verkabelung.

Für jedes wichtige Objekt sollte eine kleine Karte entstehen:

• Wo wird es angelegt?
• Welches System darf es ändern?
• Wie schnell muss eine Änderung sichtbar sein?
• Was geschieht bei widersprüchlichen Werten?
• Wie erkennt Support einen fehlgeschlagenen Vorgang?
• Wie wird eine Änderung später nachvollzogen?

Das gilt für Kunden, Bestellungen, Termine, Preise, Bestände und Berechtigungen. Wenn sowohl App als auch Warenwirtschaft denselben Lieferstatus unabhängig setzen dürfen, ist der Konflikt unvermeidlich.

Fünf Faktoren verändern den Aufwand besonders stark

Datenrichtung. Eine lesende Produktliste ist einfacher als ein Zwei-Wege-Abgleich. Beim Schreiben muss die App validieren, Fehler verständlich zeigen und Wiederholungen sicher verarbeiten.

Anmeldung und Rechte. Ein fester Serviceschlüssel ist etwas anderes als OAuth mit Anmeldung pro Organisation, Token-Erneuerung und mehreren Rollen. Zugänge müssen sicher gespeichert und widerrufen werden können.

Ereignisse und Zeit. Manche Systeme liefern Änderungen über Webhooks, andere müssen regelmäßig abgefragt werden. Ein Zahlungseingang, der Minuten später bestätigt wird, benötigt einen Zwischenzustand in App und Admin-Panel.

Datenqualität. Unterschiedliche Datumsformate, fehlende Pflichtfelder, doppelte Kunden und uneinheitliche Artikelnummern erzeugen Mapping- und Migrationsarbeit. Eine API kann technisch gut dokumentiert sein und trotzdem schlechte Bestandsdaten liefern.

Betrieb. Ratenlimits, Ausfälle und geänderte Versionen treten nach dem Start auf. Ohne Protokolle, Warnungen und Verantwortliche bleibt das Problem zunächst beim Nutzer.

Die frei zugängliche OpenAPI-Einführung hilft Produktteams zu verstehen, welche Methoden, Felder und Fehler eine maschinenlesbare Spezifikation abbilden sollte. Sie ersetzt jedoch keine Beschreibung der Geschäftsregeln.

Was vor einer Schätzung vorliegen sollte

Bitten Sie den Anbieter oder die interne IT um Dokumentation, Testzugang, Beispielantworten und eine Liste der benötigten Methoden. Klären Sie außerdem:

1. Gibt es ein getrenntes Testsystem mit realistischen Zuständen?
2. Welche Grenzwerte und Kosten gelten pro Anfrage?
3. Wie werden Änderungen und Abschaltungen angekündigt?
4. Können Webhooks signiert und erneut gesendet werden?
5. Welche Daten dürfen gespeichert werden und wie lange?
6. Wer unterstützt bei einem Fehler auf Anbieterseite?

Ohne diese Unterlagen ist nur ein Risikorahmen möglich. Ein fester Preis würde entweder wichtige Arbeit auslassen oder einen großen Sicherheitspuffer enthalten.

Zahlungen, Buchungen und ERP brauchen eigene Fehlerbilder

Bei einer Zahlung sind Erfolg und Fehler nicht die einzigen Zustände. Es gibt ausstehende Bestätigung, abgebrochene Weiterleitung, doppelte Nachricht, Erstattung, Rückbuchung und eine erfolgreiche Zahlung bei gleichzeitig fehlender Freischaltung. Die Stripe-Erklärung zu Webhooks und zu idempotenten Anfragen zeigt, warum serverseitige Ereignisse und wiederholbare Verarbeitung nötig sind.

Bei Buchungen kommen Zeitzonen, Parallelzugriff, Umbuchung, Nicht-Erscheinen und Stornofristen hinzu. Bei CRM oder ERP sind Dubletten, manuelle Änderungen und Zuständigkeiten häufig das größere Risiko. Eine Deutschland-spezifische Unternehmensintegration kann außerdem bestehende SAP-, DATEV- oder Branchenprozesse berühren; der konkrete Anbieter und Vertrag muss geprüft werden, statt eine allgemeine „ERP-Anbindung“ zu kalkulieren.

App, Backend und Admin-Panel zusammen betrachten

Eine fehlgeschlagene Synchronisierung braucht mindestens drei Darstellungen. Die App erklärt der Person den aktuellen Zustand und eine mögliche Handlung. Das Backend entscheidet über Wiederholung und Datenkonsistenz. Das Admin-Panel zeigt Support den Verlauf und eine sichere Korrektur.

Nur die mobile Oberfläche zu schätzen, verschiebt die Arbeit in die Zeit nach dem Start. Unser Leitfaden zur Backend-Entwicklung und der Beitrag zum Admin-Panel zeigen diese beiden unsichtbaren Teile.

Padi Pay ist ein passendes Appfyl-Beispiel, weil Geldflüsse nur dann vertrauenswürdig wirken, wenn App-Zustand, Backend-Bestätigung und Supportkontext zusammenpassen. Das gilt ebenso für eine Buchung oder einen Lieferauftrag.

So wird die Integration im Angebot greifbar

Statt einer Zeile „API anbinden“ sollte ein Angebot die Datenobjekte, Richtung, Authentifizierung, Ereignisse, Fehlerzustände, Admin-Funktionen, Analytik und Testfälle nennen. Für jede externe Abhängigkeit braucht es eine Annahme, etwa „dokumentierte REST-API und Testzugang werden vom Auftraggeber bereitgestellt“.

Bei Appfyl fließt die Integration in den Gesamtumfang des Produkts ein. Ein fokussiertes MVP liegt typischerweise bei 15.000 bis 20.000 Euro, ein mittleres Projekt bei 20.000 bis 50.000 Euro und ein großes System bei 50.000 bis 100.000 Euro. Das sind Planungsrahmen für komplette Projekte, keine Preise pro Schnittstelle. Eine problematische Zwei-Wege-Integration kann den Rahmen stärker verschieben als mehrere einfache App-Ansichten.

Im interaktiven Briefing können Zahlung, Karten, CRM, ERP, Buchung und andere Verbindungen einzeln beschrieben werden.

Verwandte Appfyl-Ratgeber

• Backend für mobile Apps
• Admin-Panel entwickeln
• Zahlungen und Abonnements
• CRM- und ERP-Integration
• App-Kosten einschätzen

Sehen Sie, wie Appfyl Funktionsumfang in veröffentlichte Produkte übersetzt. Appfyl Cases ansehen.

Häufige Fragen