Eigene API für Ihr ERP im KMU: wann sie sich lohnt und wie Sie kein Sicherheitsloch aufreißen

Früher oder später fragt jemand: „Können wir uns bei euch andocken?". Der Shop, den Ihr wichtigster Kunde betreibt. Ein B2B-Partner, der alle 15 Minuten Ihre Bestände sehen möchte. Ein Kurier, der einen Webhook nach jedem Versand haben will. Dieser Moment ist eine Entscheidung — entweder Sie stellen eine eigene API über Ihrem ERP bereit, oder Sie sammeln noch eine Portion Handarbeit, die jemand in Ihrer Firma bis ans Karriereende in Excel flicken wird.

Dieser Text handelt davon, wann es in einem KMU wirklich lohnt, eine API über Comarch Optima, enova365, Subiekt oder Dynamics AX zu setzen, wie man das vernünftig entwirft und — genauso wichtig — wie man daraus keine Eingangstür für das gesamte Internet macht.

Wann sich eine API lohnt — und wann nicht

Nicht jedes Problem, das nach „wir brauchen eine API" aussieht, löst sich mit einer API. Bevor Sie einen Euro ausgeben, beantworten Sie ehrlich drei Fragen.

• Wie oft pro Woche wird dieselbe Information von Hand übertragen oder als Excel per E-Mail verschickt? Weniger als fünfmal — die API rechnet sich vermutlich nicht. Automatisieren um der Automatisierung willen ist ein teures Hobby.
• Sind die Daten, nach denen jemand fragt, im ERP genauso aktuell wie beim Empfänger gebraucht? Wenn Bestände „jetzt sofort" sein sollen und Sie einmal pro Tag CSV rausschicken, verschwindet das Problem nicht mit einer API — es verschwindet mit dem Kunden.
• Kommen in den nächsten 12 Monaten weitere Integratoren mit derselben Frage? Ein Partner ist oft eine Einbahnstraße Excel-per-Mail. Drei Partner mit demselben Wunsch — das ist das Signal, dass sich die API ohne Diskussion rechnet.

In der Praxis sehen wir drei Situationen, in denen eine eigene API die klare Antwort ist: B2B-Partner, die Bestände und Preise abfragen; ein eigener Online-Shop oder Allegro-Auftritt mit beidseitiger Bestell-Synchronisation; sowie mobile Apps für Außendienstmitarbeiter, die auch dann laufen müssen, wenn im Büro niemand da ist. In jedem dieser Fälle kostet die manuelle Alternative — CSV um Mitternacht, Copy-Paste, „ich melde mich gleich per Mail" — nach zwei bis drei Quartalen mehr als das Projekt selbst.

Situationen, in denen die API mit Kanonen auf Spatzen schießt: ein monatlicher Bericht an das externe Steuerbüro (ein Export reicht), eine einmalige Datenmigration in ein neues System (ETL-Skript, keine API), oder eine „Leads aus dem Web-Formular einsammeln"-Anbindung (Webhook plus Zapier/Make genügt).

35 Personen, 3 Partner, 6 Stunden pro Woche im Vertrieb

Bei einem unserer Kunden — einem 35-Personen-Distributor für Industrieteile aus Zentralpolen — sah das Problem so aus: drei zentrale B2B-Kunden (produzierende Unternehmen mit 200–500 Mitarbeitern) meldeten sich täglich beim Vertrieb mit den Fragen „sind noch X Stück am Lager", „wann kommt die nächste Lieferung", „wie ist unser Nettopreis bei 500 Stück". Die Vertriebler antworteten, nachdem sie in Comarch Optima nachgeschaut hatten. Die Antwort ging per Mail oder Telefon raus, der Kunde tippte sie in seine eigene Tabelle, und vier Stunden später — wenn sich der Bestand längst verschoben hatte — rief er wieder an.

Kurzfassung: sechs Stunden pro Woche von zwei Vertrieblern, verloren beim Fragen und Antworten zu Daten, die ein Computer selbst herausgeben könnte, in Sekundenbruchteilen.

Wir haben eine API-Schicht über Optima in .NET gebaut mit vier Endpunkten: Bestände (pro SKU, pro Lager), aktueller kundenspezifischer Preis, Bestellhistorie eines Kunden und Bestätigung neuer Bestellungen. API-Key-Authentifizierung pro Partner, Rate-Limit von 60 Anfragen pro Minute, alle Anfragen protokolliert. Die Optima-Datenbank selbst — nie direkt angesprochen; die Middleware bedient sich aus einem Cache, der alle 60 Sekunden erneuert wird, was das Risiko eliminiert, die Produktivinstanz zu belasten.

Ergebnis nach zwei Monaten: Partner fragen die API alle 15 Minuten selbst ab, die Vertriebler haben ihre 6 Stunden pro Woche zurück und stecken sie in Neukundenakquise. Der „pflegeaufwendige" Kunde, der früher mehrmals täglich anrief, hat 40% der Bestellungen von einmalig auf wiederkehrend umgestellt (weil er den Daten endlich vertrauen konnte). Amortisation — vier Monate. Das Projekt kostete weniger als ein halbes Jahresgehalt eines Vertrieblers.

Die ERP-Datenbank nicht direkt exponieren

Das ist der häufigste Fehler, den wir bei Firmen sehen, die es allein probiert haben. Jemand hat den SQL Server nach außen aufgemacht, ein „api_user"-Konto angelegt, überall Select-Rechte vergeben und „bitte, ihr habt Zugang". Drei Wochen später — ein Performance-Problem in der Produktion, weil der Partner mitten am Tag eine Abfrage laufen ließ, die 400.000 Belegzeilen durchgescannt hat. Sechs Wochen später — die api_user-Zugangsdaten sind in einer Mail rausgeflossen, die an einen Subunternehmer weitergeleitet wurde, und dann an dessen Freund.

Die Regel ist kurz: zwischen dem ERP und der Außenwelt muss eine Zwischenschicht sein. In einem typischen KMU reicht ein einfacher .NET-Dienst (oder Node.js — die Technologiewahl ist hier zweitrangig), der:

• Die Authentifizierung übernimmt (API-Key, OAuth oder JWT — nicht die direkten Datenbankpasswörter).
• Die häufigsten Anfragen (Bestände, Preise) für 30–120 Sekunden cached. 90% des Partner-Traffics wird aus dem Cache bedient, die Produktion merkt gar nichts.
• Eingehende Anfragen validiert (Seitengröße, erlaubte Filter), damit niemand GET /produkte?limit=99999999 schickt.
• Jede Anfrage mit Zeitstempel, IP, Key-ID und Antwortzeit protokolliert. Geht etwas schief — wissen Sie genau wann und wer.

Middleware ist kein Luxus, sondern die Vorbedingung. Ohne sie ist eine API keine Schnittstelle — sondern ein Loch in der Firma.

5 Designregeln, die man ein Jahr später nicht bereut

Wir haben genug APIs gesehen, die „schnell aus dem Ärmel" gebaut wurden und drei Jahre später zur Last werden, weil man sie nicht weiterentwickeln kann, ohne Partner zu brechen. Ein paar Regeln, an die man sich vom ersten Tag halten sollte:

1. Von Anfang an versionieren. Der Pfad heißt /api/v1/produkte, nicht /api/produkte. Eine v2 in einem Jahr hinzuzufügen kostet zwei Zeilen Code. Ohne Versionierung — kostet es die Neuverhandlung von Verträgen mit Partnern.
2. Ein Endpunkt = eine Ressource. /api/v1/produkte liefert Produkte, /api/v1/bestaende liefert Bestände. Nicht alles in einen „Master-Endpunkt" quetschen, weil „das auf ERP-Seite einfacher ist".
3. Idempotenz überall, wo geschrieben wird. Der Partner schickt eine Bestellung mit seiner eigenen externen Bestellnummer. Wenn er sie zweimal sendet — dasselbe Ergebnis, aber es entsteht keine doppelte Bestellung. Ohne das ist die erste Reklamation „ich habe einmal geschickt, ihr habt zweimal, wer zahlt das?".
4. Kompakte Antworten, keine internen IDs. Geben Sie SKU, EAN, Name, Preis zurück — nicht ProductGuid, WarehouseZoneRefId und weitere interne Felder. Ihre internen Strukturen ändern sich; der Vertrag mit dem Partner sollte es nicht.
5. Doku aus dem Code generiert. Swagger/OpenAPI zusammen mit dem Dienst ausliefern. „Wir schreiben die Doku, wenn wir Zeit haben" ist gleichbedeutend mit „wir schreiben sie nie", und ohne Doku fragen Partner Sie per Mail nach jedem Feld.

Sicherheit — worauf es wirklich ankommt

Drei Punkte, die in der Praxis eine unfallfreie API von einer geleakten unterscheiden:

• HTTPS erzwungen, HTTP umgeleitet. Ohne Ausnahmen, auch im Testsystem. Ein API-Key, der über HTTP verschickt wird, ist ein öffentlicher Schlüssel.
• Rate-Limit pro Key. Selbst wenn Sie dem Partner vertrauen, schützt Sie ein Limit von 5–100 Anfragen/Minute vor einem Bug auf seiner Seite. Wir haben ein Partner-Skript gesehen, das durch einen Rekursionsfehler 3.000 Anfragen/Minute abgefeuert hat — ohne Limit hätte es den Dienst umgelegt.
• Key-Rotation alle 6–12 Monate. Trivial, fast nie umgesetzt. In den Partnervertrag schreiben und einen Monat vorher per Mail erinnern. Ein Schlüssel, der seit 4 Jahren nicht rotiert wurde und einmal in einer Mail an einen Ex-Mitarbeiter stand, ist kein Schlüssel — sondern eine Einladung.

Dazu das gesunde Minimum: ein Audit-Log aller Anfragen mit 90 Tagen Aufbewahrung, ein Alarm bei ungewöhnlichem Traffic (ein plötzlicher 10-facher Anstieg) und separate ERP-Konten für die API-Operationen — solche, die physisch nicht das Recht haben, Kundenstammdaten, Lohnabrechnungen oder Bankdaten zu ändern. Die API liest und (im engen Rahmen) legt Bestellungen an. Mehr nicht.

Womit anfangen

Wenn jemand in Ihrer Firma anfängt zu sagen „wir wollen eine API zum ERP", gehen Sie in dieser Reihenfolge vor:

1. Auf einer Seite aufschreiben, wer konkret was fragt. Nicht „Partner", sondern drei konkrete Kunden und konkrete Daten. Ohne das entwerfen Sie eine API für eine Zukunft, die nie eintritt.
2. Stunden zählen. Wie viele Stunden pro Woche verlieren Sie heute an diese drei Anfragen? Multiplizieren Sie mit 50 Wochen. Das ist Ihre Budget-Obergrenze.
3. Höchstens 4 Endpunkte für den ersten Release wählen. Bestand, Preise, einseitige Auftragsannahme, Status. Der Rest wartet auf v1.1.
4. Zwischenschicht entscheiden. Selbst die einfachste API braucht Middleware — versuchen Sie nicht, Optima „über SQL" freizugeben. Ein schlichter .NET-Dienst mit einem Redis-Cache reicht für die meisten KMU die ersten zwei Jahre.
5. 2–4 Wochen für das MVP einplanen, einen weiteren Monat für Doku, Monitoring und das Onboarding des ersten Partners. Nicht „auf sechs Monate" planen — eine API, die sechs Monate entworfen wird, geht nie live.

Eine eigene API über dem ERP ist kein Prestigeprojekt „weil die Konzerne so etwas haben". Sie ist die Antwort auf eine konkrete Vertriebsstunde pro Woche, die heute im Beantworten von E-Mails verschwindet. Wenn diese Stunden 5 oder 10 pro Woche ausmachen — amortisiert sich das Projekt im ersten Quartal und läuft danach jahrelang von selbst.

Wenn Sie prüfen wollen, ob das jetzt der richtige Moment für Ihre Firma ist, aber keinen Monat für die Analyse haben, helfen wir KMU, das in einem 30-Minuten-Gespräch zu zerlegen. Ohne Folien.

Eine API für das ERP ist kein Prestigeprojekt. Sie ist die Antwort auf eine Stunde pro Woche, die heute im Beantworten derselben Mail verschwindet.

← Zurück zum Blog