Als Integrationsarchitektin stoße ich immer wieder auf dasselbe Problem: Teams bauen auf SaaS‑Anbieter, ohne verbindliche API‑SLAs zu verhandeln. Wenn dann Ausfälle, Rate‑Limits oder versteckte Kosten kommen, sind Projektzeitplan und Budget schnell gefährdet. In diesem Beitrag teile ich meine erprobten Strategien, Formulierungen und Fallstricke, damit Sie bei Verhandlungen mit SaaS‑Anbietern verbindliche, überprüfbare API‑SLAs durchsetzen und unerwartete Kosten vermeiden.
Warum API‑SLAs so wichtig sind
Ein SLA ist mehr als eine schöne Zusage im Vertrag. Für mich ist ein gutes SLA ein Betriebshandbuch in rechtlicher Form: Es beschreibt Verfügbarkeit, Performance, Support‑Antwortzeiten, Messmethodik und Sanktionen. Ohne diese Klarheit fehlt die Grundlage für Eskalationen, Budgetplanung und Kapazitätsentscheidungen. Ich habe Projekte erlebt, in denen ein vager Satz wie „reasonable efforts“ Ausfälle monatelang unbehelligt ließ — bis das Projektbudget explodierte.
Die Kernkomponenten eines verbindlichen API‑SLA
Folgende Punkte verhandle ich systematisch — und empfehle Ihnen das gleiche:
Verfügbarkeit (Uptime): Prozentangabe über ein definiertes Messfenster (z. B. 99,9 % pro Kalendermonat) sowie Ausschlüsse (geplante Wartung mit Vorankündigung).Antwortzeiten / Latenz: P95/P99‑Werte für typische Endpunkte, getrennt nach Lese‑ und Schreiboperationen.Fehlerraten: Erwartete Rate von 4xx/5xx‑Fehlern (z. B. < 0,1 % pro Monat).Rate limiting & Throttling: Klare Limits, Fair‑Use‑Policy, Verhalten bei Überschreitung, Benachrichtigungen und automatische Rücksetzregeln.Incident Management: Klassifizierung von Vorfällen (P0–P3), Reaktions‑ und Wiederherstellungszeiten sowie regelmäßige Post‑Mortem‑Reports.Monitoring & Reporting: Welche Metriken werden geliefert, wie oft, in welchem Format, und wer kann die Rohdaten einsehen.Sanktionen und Kompensation: Service Credits, Rückerstattungen oder Preisnachlässe, klar berechnet und automatisiert auslösend bei Nichteinhaltung.Security & Compliance: Anforderungen an Verschlüsselung, Penetrationstests, Datenschutz (DSGVO), Audit‑Rechte.Data Portability & Exit: Exportformate, Fristen und Unterstützung beim Datenabzug im Ausstiegsfall.Change Management: Vorankündigungen für Breaking Changes, Test‑/Beta‑Umgebungen und Rollback‑Garantie.Wie ich Verfügbarkeit konkret formuliere
Allgemeine Aussagen wie „hochverfügbar“ sind wertlos. Ich formuliere Verfügbarkeit präzise und messebar:
Beispiel: „Verfügbarkeit der API‑Plattform ≥ 99,95 % pro Kalendermonat, gemessen nach Anbieter‑Monitoring. Geplante Wartungsfenster von maximal 4 Stunden pro Monat sind ausgeschlossen, müssen 72 Stunden vorab angekündigt werden und dürfen 2 Wartungsfenster pro Quartal nicht überschreiten.“Wenn der Anbieter nur „gemessene Verfügbarkeit“ anbieten möchte, bestehe ich auf Zugang zu Rohmetriken oder einem gemeinsamen Dashboard (z. B. Datadog, Grafana), damit wir unabhängig prüfen können.
Praktische Formulierungen für Incident Management
Ein SLA muss beschreiben, wer was wann tut. Ich verhandle folgende konkrete SLAs:
P0 (Produktiv‑Ausfall): Erstreaktionszeit ≤ 15 Minuten, Mitigation innerhalb 2 Stunden, vollständige Wiederherstellung oder Workaround innerhalb 8 Stunden.P1 (Degradierte Performance): Erstreaktionszeit ≤ 60 Minuten, Mitigation innerhalb eines Arbeitstages.Für jeden Vorfall erwarte ich ein Post‑Mortem innerhalb 5 Werktagen mit Ursachenanalyse, Kurz‑ und Langfristmaßnahmen.Monitoring, Transparenz und Audit‑Rechte
Ohne Transparenz können SLAs zur Farce werden. Gute Verhandlungspunkte:
Regelmäßige Reports (täglich/monatlich) mit Uptime, Latenz‑Percentiles, Fehlerraten nach Endpoint.Readonly‑Zugang zu Monitoring‑Dashboards oder die Lieferung von Raw‑Metrics per API/S3.Audit‑Recht: mindestens einmal jährlich, um Konfiguration, Sicherheitsmaßnahmen und Änderungsverfahren zu prüfen.Sanktionen, Service Credits und Kostenmodelle
Viele Anbieter bieten Service Credits, aber die Formulierung entscheidet über Wirksamkeit. Ich verhandle üblicherweise:
Service Credits gestaffelt nach Schwere und Dauer des SLA‑Bruchs (z. B. 5 % Gutschrift für einen Monat Verfügbarkeit < 99,9 %, 15 % bei < 99,5 %). Diese Credits dürfen automatisch ausgezahlt oder auf die nächste Rechnung angewandt werden.Eine Obergrenze für Credits reicht nicht — ich bestehe auf einem Mindestmaß an Kompensation, das realen Schaden abdeckt, oder auf dem Recht, bei wiederholten Verstößen vom Vertrag zurückzutreten ohne Strafzahlungen.Transparenz bei kostenpflichtigen Ausweichpfaden: Wenn der Anbieter bei Lastspitzen „Premium‑Endpoints“ verkauft, müssen diese Preise und Kapazitäten im SLA klar definiert sein.Change Management: Wie Sie Breaking Changes vermeiden
APIs verändern sich — das ist normal. Entscheidend ist, wie Änderungen gesteuert werden:
Breaking Changes mindestens 90 Tage im Voraus ankündigen, mit Migrationspfad, Testenvironment und Feature‑Flags.Backwards‑Compatibility‑Garantie für Hauptversionen (SemVer verwenden) und Parallelbetrieb alter/n neuer Endpunkte für definierte Zeiträume.Release‑Notes, automatisierte Tests und Sandbox‑Instanzen für Kunden vor dem produktiven Rollout.Data Portability und Exit‑Szenario
Ich verhandle immer klare Exit‑Klauseln. Dazu gehören:
Vollständiger Export aller Kundendaten (Produktionsdaten, Auditlogs, Konfigurationen) in maschinenlesbaren Formaten (JSON/CSV), innerhalb 30 Tagen nach Kündigung.Unterstützung bei Datenmigration: mindestens 10 Stunden technischer Support ohne zusätzliche Kosten.Festlegung, wie lange Backups aufgehoben werden (z. B. 90 Tage) und wie Daten sicher gelöscht werden.Checkliste für Verhandlungen (meine Standard‑Agenda)
| Verhandlungspunkt | Meine Mindestforderung |
|---|
| Verfügbarkeit | ≥ 99,95 % / Monat, Dashboardzugang |
| Antwortzeiten | P95 ≤ definierter Schwellenwert je Endpoint |
| Incident Reaktion | P0 ≤ 15 min, P0 Mitigation ≤ 2 h |
| Sanktionen | Automatische Service Credits + Rücktrittsrecht bei Wiederholung |
| Monitoring | Readonly‑Zugang oder Raw‑Metrics Lieferung |
| Change Management | 90 Tage Vorlauf + Sandbox |
| Data Portability | Export in JSON/CSV innerhalb 30 Tage |
Tipps für die Verhandlungsführung
Aus Erfahrung empfehle ich:
Verhandeln Sie früh — nicht erst nach dem Proof‑of‑Concept.Trennen Sie Preisverhandlungen von SLA‑Verhandlungen. Anbieter kämpfen eher um Preis als um harte SLA‑Punkte.Holen Sie Referenzen ein: Fragen Sie nach Kunden mit ähnlicher Last/Branche und prüfen Sie deren Erfahrungen mit Incidents.Nutzen Sie marktübliche Benchmarks (z. B. AWS, Azure, Twilio) als Referenz für Verfügbarkeits‑ und Response‑Werte.Fügen Sie Eskalationskontakte in den Vertrag ein — inklusive Mobilnummern für P0‑Fälle.Auf https://www.projectintegration.ch finden Sie weiterführende Checklisten und Vorlagen, die ich in Projekten verwende. Wenn Sie möchten, kann ich Ihre aktuelle SLA‑Vorschrift gegenlesen und konkrete Formulierungen vorschlagen — schreiben Sie mir für ein Review oder eine Workshop‑Session.
