Carola Schulte, App-Entwicklerin

App-Integration 2025: CRM, ERP, SSO – Schnittstellen-Strategie

“Die App muss mit unserem CRM sprechen” – Der Satz, der aus jedem MVP ein Enterprise-Projekt macht. Integration ist kein Nice-to-Have, sondern Pflicht bei Business-Apps. Aber: Falsch geplant, explodieren Kosten (+150%) und Timeline (+6 Monate).

Als Software-Architektin mit 25+ Jahren Erfahrung zeige ich Ihnen, wie Sie Apps richtig integrieren: SSO (SAML, OAuth, LDAP), CRM/ERP-Sync, API-Strategien (REST vs. GraphQL), Security (OAuth-Tokens, TLS-Pinning) – mit konkreten Zahlen aus Wächterkontrollsystemen, Inventur-Apps und NFC-Projekten.

🔔 WICHTIG: Alle Preise verstehen sich netto (zzgl. 19% USt.). DE-Sätze; Offshore/NE-EU abweichend.

TL;DR – Die Essenz

Integrations-Typ	Komplexität	Typische Kosten	Use Case
SSO (Single Sign-On)	Mittel	3.000-8.000 €	OAuth, SAML, LDAP/Active Directory
CRM-Integration (Standard)	Mittel	5.000-15.000 €	Salesforce, HubSpot, Pipedrive (REST-APIs)
CRM-Integration (Custom)	Hoch	15.000-40.000 €	Legacy-Systeme, SOAP, Custom-Protokolle
ERP-Integration (Standard)	Hoch	10.000-25.000 €	SAP, Microsoft Dynamics, DATEV (REST/SOAP)
ERP-Integration (Custom)	Sehr Hoch	25.000-60.000 €	On-Premise SAP, Custom-DBs, Mainframes
Datenbank-Direktzugriff	Niedrig-Mittel	2.000-6.000 €	MSSQL, PostgreSQL, Oracle (Read-Only empfohlen)
WebSockets (Realtime)	Mittel	4.000-10.000 €	Chat, Live-Tracking, Notifications

Goldene Regel: Integration kostet 10-30% der Entwicklungskosten. Bei Legacy-Systemen (SAP, Mainframe) kann es 50-100% sein.

Hinweis: Alle Preise netto, DACH-Bandbreiten, abhängig von Scope/Seniority.

Warum Integration Pflicht ist (keine Insellösung)

Problem: “Wir haben schon ein CRM, ERP, HR-System – warum noch eine App?”

Antwort: Weil Mobile-First für Außendienst, Field-Service, Logistik Pflicht ist. Aber: Die App muss mit bestehenden Systemen sprechen, sonst entsteht Datensilos.

Das Datensilos-Problem

Ohne Integration:

Wächterkontrolle-App → SQLite (lokal)
CRM (Salesforce) → Cloud
ERP (SAP) → On-Premise

→ 3 separate Datenquellen
→ Manuelle Daten-Migration (Excel-Export/Import)
→ Keine Echtzeit-Synchronisation
→ Fehleranfällig (Duplikate, veraltete Daten)

Mit Integration:

Wächterkontrolle-App → REST API → CRM/ERP
→ Automatische Synchronisation (Echtzeit oder Batch)
→ Single Source of Truth (CRM = Master)
→ Keine manuellen Exports
→ Weniger Fehler (API validiert Daten)

Business-Impact:

✅ Zeitersparnis: 5-10 Stunden/Monat (keine Excel-Exporte)
✅ Fehlerreduktion: -80% (API-Validierung vs. manuelle Eingabe)
✅ Echtzeit-Daten: Manager sehen Check-Ins sofort (nicht am nächsten Tag)
✅ Compliance: DSGVO-Löschpflicht automatisch (CRM löscht → App löscht)

Kosten-Nutzen-Rechnung:

Integration: 12.000 € (einmalig)
Zeitersparnis: 8 Stunden/Monat × 50 €/Stunde = 400 €/Monat
→ ROI nach 30 Monaten

Bei 5 Jahren: 24.000 € Ersparnis - 12.000 € Integration = 12.000 € Gewinn

Problem: User hat 5 Apps (CRM, ERP, HR, Inventur, Wächterkontrolle) → 5 verschiedene Logins → Passwort-Hölle.

Lösung: SSO (Single Sign-On) – User loggt sich einmal ein (z.B. in Active Directory) → alle Apps nutzen denselben Login.

SSO-Protokolle im Vergleich

Protokoll	Komplexität	Use Case	Kosten (Implementierung)
OAuth 2.0	Niedrig-Mittel	Social Login (Google, Microsoft), Cloud-Apps	3.000-6.000 €
SAML 2.0	Mittel-Hoch	Enterprise (Active Directory, Okta, Azure AD)	5.000-10.000 €
LDAP	Mittel	On-Premise (Active Directory, OpenLDAP)	4.000-8.000 €
OpenID Connect	Niedrig-Mittel	Modern SSO (basiert auf OAuth 2.0)	3.000-6.000 €

OAuth 2.0: Der Standard für Cloud-Apps

Prinzip: User autorisiert App, auf Name/E-Mail zuzugreifen (z.B. “Mit Google anmelden”).

Flow:

1. User klickt "Mit Google anmelden"
2. App öffnet Google-Login (Browser/WebView)
3. User loggt sich bei Google ein
4. Google gibt **Access-Token** an App
5. App nutzt Token, um User-Daten abzurufen (Name, E-Mail, Foto)

Code-Beispiel (Flutter + OAuth 2.0):

import 'package:google_sign_in/google_sign_in.dart';

final GoogleSignIn _googleSignIn = GoogleSignIn(
  scopes: ['email', 'profile'],
);

Future<void> signInWithGoogle() async {
  try {
    final account = await _googleSignIn.signIn();
    if (account == null) return; // User hat abgebrochen

    final auth = await account.authentication;
    final accessToken = auth.accessToken;

    // Access-Token an Backend senden
    await api.post('/auth/google', {
      'token': accessToken,
    });

    // User ist eingeloggt
  } catch (e) {
    print('Login fehlgeschlagen: $e');
  }
}

Kosten: 3.000-5.000 € (OAuth-Implementierung + Backend-Integration)

Vorteile:

✅ Einfach (User kennt Google/Microsoft-Login)
✅ Keine Passwort-Verwaltung (Google/Microsoft übernimmt das)
✅ Schneller Onboarding (1-Click-Login)

Nachteile:

❌ Abhängigkeit von externem Provider (Google down = kein Login)
❌ Datenschutz-Bedenken (Google sieht, wer sich einloggt)

SAML 2.0: Enterprise-Standard

Prinzip: User loggt sich in Identity Provider (z.B. Azure AD, Okta) ein → IdP gibt SAML-Assertion an App → App vertraut IdP.

Use Case: Große Firmen mit Active Directory (500+ User).

Flow:

1. User öffnet App
2. App redirect zu Azure AD (Identity Provider)
3. User loggt sich bei Azure AD ein (Windows-Login)
4. Azure AD generiert SAML-Assertion (XML mit User-Daten)
5. App validiert SAML-Assertion (Signatur prüfen)
6. User ist eingeloggt

Kosten: 5.000-10.000 € (SAML-Implementierung + Azure AD-Setup)

Vorteile:

✅ Enterprise-Standard (Active Directory-Integration)
✅ Zentralisierte User-Verwaltung (IT-Admin verwaltet Zugriffe)
✅ Sicherheit (SAML-Assertion signiert)

Nachteile:

❌ Komplex (XML-Parsing, Signatur-Validierung)
❌ Teurer als OAuth (mehr Entwicklungsaufwand)

SAML-Praxis-Tipp: Nutze Library wie onelogin/python-saml (Python) oder saml2-js (Node.js) – niemals selbst implementieren (Security-Risiko).

LDAP: On-Premise Active Directory

Prinzip: App verbindet sich direkt mit Active Directory (LDAP-Protokoll) → prüft Username/Password.

Use Case: On-Premise-Firmen ohne Cloud (keine Azure AD, kein Okta).

Code-Beispiel (Python + LDAP):

import ldap

def authenticate_ldap(username, password):
    server = 'ldap://dc.firma.local'
    bind_dn = f'CN={username},OU=Users,DC=firma,DC=local'

    try:
        conn = ldap.initialize(server)
        conn.simple_bind_s(bind_dn, password)
        # Login erfolgreich
        return True
    except ldap.INVALID_CREDENTIALS:
        # Falsches Passwort
        return False

Kosten: 4.000-8.000 € (LDAP-Integration + VPN-Setup für App)

Vorteile:

✅ On-Premise (keine Cloud-Abhängigkeit)
✅ Direkter Active Directory-Zugriff

Nachteile:

❌ VPN nötig (App muss ins Firmennetzwerk)
❌ Passwort-Transmission (App kennt Passwort → Security-Risiko bei Compromise)
❌ Nicht für Public-Apps geeignet (nur Firmen-intern)

Security-Warnung: LDAP überträgt Passwort → TLS/SSL Pflicht. Besser: SAML/OAuth (Passwort bleibt bei IdP).

CRM-Integration: Salesforce, HubSpot, Custom

Use Case: Wächterkontrolle-App → Check-Ins ins CRM syncen (Salesforce), damit Vertrieb sieht, welche Kunden besucht wurden.

Salesforce-Integration (REST API)

Salesforce bietet REST API → einfach zu integrieren.

Flow:

1. Wächter macht Check-In (App → SQLite lokal)
2. App syncet zu Backend (REST API)
3. Backend syncet zu Salesforce (REST API)
   → Erstellt "Task" in Salesforce (Visit-Log)

Code-Beispiel (Python + Salesforce REST API):

from simple_salesforce import Salesforce

sf = Salesforce(
    username='user@firma.com',
    password='password',
    security_token='token',
    domain='login'  # oder 'test' für Sandbox
)

# Check-In als Task in Salesforce erstellen
sf.Task.create({
    'Subject': 'Wächter Check-In: Objekt A',
    'Status': 'Completed',
    'ActivityDate': '2025-11-01',
    'WhoId': 'Kontakt-ID',  # Salesforce Lead/Contact ID
    'Description': 'GPS: 48.1351, 11.5820 | Foto: https://...'
})

Kosten: 8.000-12.000 € (Salesforce-Integration + OAuth-Setup)

Vorteile:

✅ Gut dokumentierte API (Salesforce Developer Docs)
✅ OAuth 2.0 (keine Passwörter in Code)
✅ Sandbox (Test-Environment vor Production)

Nachteile:

❌ Rate-Limits (max. 15.000 API-Calls/24h bei Standard-Lizenz)
❌ Kosten (Salesforce API-Zugriff ab Professional-Edition = 75 €/User/Monat)

HubSpot-Integration (REST API)

HubSpot = CRM für KMU (günstiger als Salesforce).

Code-Beispiel (Node.js + HubSpot API):

const hubspot = require('@hubspot/api-client');

const client = new hubspot.Client({ accessToken: 'YOUR_ACCESS_TOKEN' });

// Contact erstellen (Lead)
await client.crm.contacts.basicApi.create({
  properties: {
    email: 'kunde@firma.de',
    firstname: 'Max',
    lastname: 'Mustermann',
    phone: '+49 123 456789',
    company: 'Muster GmbH',
  }
});

// Deal erstellen (Opportunity)
await client.crm.deals.basicApi.create({
  properties: {
    dealname: 'App-Projekt: Inventur-Scanner',
    amount: '45000',
    dealstage: 'qualifiedtobuy',
  }
});

Kosten: 5.000-10.000 € (HubSpot-Integration)

Vorteile:

✅ Einfache API (REST, gut dokumentiert)
✅ Kostenlos (HubSpot Free hat API-Zugriff)
✅ Webhooks (HubSpot benachrichtigt App bei Änderungen)

Nachteile:

❌ Weniger Features als Salesforce (für Enterprise oft zu simpel)

Custom-CRM-Integration (Legacy-Systeme)

Problem: Firma nutzt Custom-CRM (selbst gebaut, 15 Jahre alt) → keine REST API, nur SOAP oder Datenbank-Direktzugriff.

Lösungen:

Option 1: SOAP-Wrapper bauen

from zeep import Client

client = Client('http://crm.firma.local/api?wsdl')
result = client.service.CreateContact(
    FirstName='Max',
    LastName='Mustermann',
    Email='max@firma.de'
)

Kosten: 15.000-25.000 € (SOAP-Integration + Reverse-Engineering)

Option 2: Datenbank-Direktzugriff (Read-Only empfohlen)

import pyodbc

conn = pyodbc.connect(
    'DRIVER={SQL Server};SERVER=crm-db.firma.local;'
    'DATABASE=CRM;UID=app_user;PWD=password'
)

cursor = conn.cursor()
cursor.execute("SELECT * FROM Contacts WHERE Email = ?", 'max@firma.de')
contact = cursor.fetchone()

Kosten: 8.000-15.000 € (DB-Integration + Schema-Reverse-Engineering)

⚠️ Security-Warnung: Direkter DB-Zugriff = Read-Only empfohlen (Write = Risiko von Data-Corruption). Besser: CRM baut eigene REST API.

Option 3: Middleware bauen (API-Gateway)

App → REST API (Custom-Middleware) → SOAP/DB → Legacy-CRM

Kosten: 20.000-40.000 € (Custom-Middleware + Testing)

Vorteil: App spricht nur REST → Legacy-System austauschbar (ohne App zu ändern).

ERP-Integration: SAP, Microsoft Dynamics, DATEV

Use Case: Inventur-App → gescannte Artikel ins ERP exportieren (SAP) für Buchhaltung/Bestandsverwaltung.

SAP-Integration (OData/REST API)

SAP bietet OData-API (REST-ähnlich) → aber komplex (SAP-Dokumentation schwer lesbar).

Flow:

1. Inventur-App scannt 1000 Artikel (Barcode-Scanner)
2. App syncet zu Backend (REST API)
3. Backend syncet zu SAP (OData API)
   → Aktualisiert Bestand in SAP-Tabelle "MARC" (Material Master)

Code-Beispiel (Python + SAP OData):

import requests

sap_url = 'https://sap.firma.de/sap/opu/odata/sap/API_MATERIAL_STOCK_SRV'
headers = {
    'Authorization': 'Basic <base64-encoded-credentials>',
    'Content-Type': 'application/json',
}

# Bestand aktualisieren
response = requests.patch(
    f'{sap_url}/A_MaterialStock(Material=\'12345\',Plant=\'1000\')',
    json={'MatlWrhsStkQtyInMatlBaseUnit': '150'},
    headers=headers
)

Kosten: 20.000-35.000 € (SAP-Integration + Consultant-Support)

Vorteile:

✅ SAP = Standard (viele Enterprise-Kunden nutzen SAP)
✅ OData = REST-ähnlich (kein SOAP-Wahnsinn)

Nachteile:

❌ Teuer (SAP-Consultant kostet 1.200-2.000 €/Tag)
❌ Komplex (SAP-Dokumentation schwer verständlich)
❌ Langsam (SAP-API-Response-Time oft 500ms-2s)

SAP-Praxis-Tipp: Nutze SAP Business Technology Platform (BTP) → vorgefertigte APIs für häufige Use Cases (Bestandsverwaltung, Rechnungen, etc.).

Microsoft Dynamics 365 (REST API)

Dynamics = Salesforce-Alternative von Microsoft (Cloud-ERP + CRM).

Code-Beispiel (C# + Dynamics Web API):

using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Tooling.Connector;

var conn = new CrmServiceClient("AuthType=OAuth;...;");

// Account erstellen (Kunde)
Entity account = new Entity("account");
account["name"] = "Muster GmbH";
account["telephone1"] = "+49 123 456789";

Guid accountId = conn.Create(account);

Kosten: 12.000-20.000 € (Dynamics-Integration)

Vorteile:

✅ Microsoft-Ökosystem (Active Directory, Azure)
✅ Gute Dokumentation (Microsoft Developer Network)
✅ OAuth 2.0 (sicher)

Nachteile:

❌ Lizenzkosten (Dynamics ab 50 €/User/Monat)
❌ Vendor-Lock-in (Microsoft)

DATEV-Integration (SOAP/REST)

DATEV = Buchhaltungs-Software für Steuerberater (DE/AT/CH).

Use Case: Inventur-App → Bestandsdaten an DATEV exportieren (für Jahresabschluss).

DATEV bietet SOAP-API (keine REST) → komplex.

Kosten: 15.000-25.000 € (DATEV-Integration + Steuerberater-Konsultation)

Vorteile:

✅ Standard in DE/AT (Steuerberater nutzen DATEV)
✅ Compliance (DATEV-Export = GoBD-konform)

Nachteile:

❌ SOAP (XML-basiert, langsam)
❌ Teuer (DATEV-API-Zugang ab 50 €/Monat)
❌ Dokumentation veraltet (DATEV-Developer-Portal schwer nutzbar)

API-Strategien: REST vs. GraphQL vs. WebSockets

REST API: Der Standard

Prinzip: HTTP-basiert (GET, POST, PUT, DELETE).

Beispiel:

GET  /api/users/123         → User abrufen
POST /api/users             → User erstellen
PUT  /api/users/123         → User aktualisieren
DELETE /api/users/123       → User löschen

Vorteile:

✅ Einfach (jeder versteht HTTP)
✅ Stateless (keine Sessions nötig)
✅ Cacheable (Browser cached GET-Requests)

Nachteile:

❌ Over-Fetching (GET /api/users/123 gibt alle Felder zurück, auch wenn nur Name gebraucht wird)
❌ Under-Fetching (User + Posts → 2 Requests nötig: GET /users/123, GET /users/123/posts)

REST-Best-Practices:

1. Versionierung: /api/v1/users (nicht /api/users)
2. Pagination: /api/users?page=1&limit=20
3. Filtering: /api/users?role=admin
4. HTTP-Status-Codes: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Server Error
5. JSON (nicht XML): {"name": "Max"}

GraphQL: Flexibler, aber komplexer

Prinzip: Client fragt genau die Daten ab, die er braucht.

Beispiel:

# Client fragt nur Name + E-Mail ab (nicht alle Felder)
query {
  user(id: 123) {
    name
    email
  }
}

# Response
{
  "data": {
    "user": {
      "name": "Max Mustermann",
      "email": "max@firma.de"
    }
  }
}

Vorteil: Nested-Queries (User + Posts in 1 Request)

query {
  user(id: 123) {
    name
    posts {
      title
      createdAt
    }
  }
}

Vorteile:

✅ Kein Over-/Under-Fetching (Client holt nur was er braucht)
✅ Typisiert (GraphQL-Schema definiert Typen)
✅ Self-Documenting (GraphQL Playground zeigt alle Queries)

Nachteile:

❌ Komplex (GraphQL-Server aufwändiger als REST)
❌ Caching schwierig (HTTP-Cache funktioniert nicht)
❌ Overkill für einfache APIs (REST reicht meist)

Wann GraphQL nutzen?

✅ Mobile-Apps mit limitierter Bandbreite (nur nötige Daten fetchen)
✅ Viele verschiedene Clients (Web, Mobile, Desktop) mit unterschiedlichen Daten-Needs
❌ Nicht bei einfachen CRUD-APIs (REST ist einfacher)

WebSockets: Realtime-Kommunikation

Prinzip: Bidirektionale Verbindung (Server kann Client pushen, nicht nur umgekehrt).

Use Cases:

Chat-Apps (Nachrichten instant zeigen)
Live-Tracking (Wächter-Position in Echtzeit)
Notifications (Server pushed Notification an App)

Code-Beispiel (Flutter + WebSockets):

import 'package:web_socket_channel/web_socket_channel.dart';

final channel = WebSocketChannel.connect(
  Uri.parse('wss://api.firma.de/ws'),
);

// Nachrichten empfangen
channel.stream.listen((message) {
  print('Server sagt: $message');
});

// Nachricht senden
channel.sink.add('Hallo Server');

Kosten: 4.000-10.000 € (WebSocket-Server + Scaling)

Vorteile:

✅ Echtzeit (keine Polling nötig: GET /messages alle 5 Sekunden)
✅ Bidirektional (Server kann Client pushen)

Nachteile:

❌ Stateful (Server muss Connection halten → Skalierung schwierig)
❌ Firewall-Probleme (manche Firmen-Firewalls blocken WebSockets)

Alternative: Server-Sent Events (SSE) – einfacher als WebSockets, aber unidirektional (Server → Client).

Real Cases: Integration in der Praxis

Case 1: Wächterkontrollsystem (CRM-Sync)

Anforderung:

Check-Ins (GPS, NFC, Fotos) ins CRM syncen (Salesforce)
Vertrieb sieht, welche Objekte besucht wurden
Manager sieht Check-Ins in Echtzeit

Technische Lösung:

Wächter-App (Flutter) → Backend (Node.js) → Salesforce REST API

Flow:
1. Wächter macht Check-In (GPS + NFC-Tag)
2. App speichert lokal (SQLite) + sendet zu Backend
3. Backend erstellt "Task" in Salesforce (Visit-Log)
4. Vertrieb sieht Check-In in Salesforce (Activity-Timeline)

Code-Snippet (Backend → Salesforce):

const jsforce = require('jsforce');

const conn = new jsforce.Connection({
  oauth2: {
    clientId: process.env.SF_CLIENT_ID,
    clientSecret: process.env.SF_CLIENT_SECRET,
  }
});

await conn.login(process.env.SF_USERNAME, process.env.SF_PASSWORD);

// Check-In als Task erstellen
await conn.sobject('Task').create({
  Subject: `Check-In: ${checkin.location}`,
  Status: 'Completed',
  ActivityDate: checkin.timestamp,
  Description: `GPS: ${checkin.gps} | NFC: ${checkin.nfc_tag}`,
});

Kosten Integration: 10.000 € (Salesforce REST API + OAuth + Testing)

Learnings:

✅ Salesforce-Sandbox essentiell (Testing vor Production)
⚠️ Rate-Limits beachten (max. 15.000 API-Calls/24h)
✅ Retry-Logic wichtig (Salesforce manchmal down)

Case 2: Inventur-Scanner (ERP-Export)

Anforderung:

Gescannte Artikel (1000+) ins ERP exportieren (SAP)
Bestand in SAP aktualisieren
CSV-Export als Fallback (falls SAP down)

Technische Lösung:

Inventur-App (Flutter) → Backend (Python) → SAP OData API

Flow:
1. Scanner scannt 1000 Artikel (Barcode)
2. App speichert lokal (SQLite)
3. User klickt "Export zu SAP"
4. Backend batched Requests (50 Artikel/Request)
5. SAP aktualisiert Bestand

Batch-Request (Performance-Optimierung):

# ❌ Langsam: 1000 einzelne Requests
for article in articles:
    sap_api.update_stock(article)

# ✅ Schnell: Batch-Request (50 Artikel auf einmal)
batches = [articles[i:i+50] for i in range(0, len(articles), 50)]
for batch in batches:
    sap_api.batch_update_stock(batch)

Kosten Integration: 22.000 € (SAP OData API + Consultant + Testing)

Learnings:

✅ Batch-Requests Pflicht (1000 einzelne Requests = zu langsam)
⚠️ SAP-Consultant nötig (SAP-Dokumentation unverständlich)
✅ CSV-Fallback wichtig (SAP manchmal instabil)

Case 3: Mensa-NFC-App (LDAP-SSO + Studenten-DB)

Anforderung:

SSO mit Uni-Active-Directory (LDAP)
Studenten-Daten aus Uni-DB laden (PostgreSQL)
Check-Ins speichern (lokale DB)

Technische Lösung:

Mensa-App (Flutter) → Backend (Python) → LDAP (Active Directory) + PostgreSQL

Flow:
1. Student loggt sich ein (Uni-Login)
2. Backend prüft Credentials via LDAP
3. Backend lädt Studenten-Daten aus PostgreSQL
4. Check-In wird gespeichert (PostgreSQL)

LDAP-Integration:

import ldap

def authenticate(username, password):
    conn = ldap.initialize('ldap://ldap.uni.de')
    bind_dn = f'uid={username},ou=students,dc=uni,dc=de'
    try:
        conn.simple_bind_s(bind_dn, password)
        return True
    except ldap.INVALID_CREDENTIALS:
        return False

Kosten Integration: 6.500 € (LDAP-SSO + PostgreSQL-Read-Access)

Learnings:

✅ LDAP einfacher als SAML (Uni hatte kein SAML)
⚠️ VPN nötig (LDAP nur im Uni-Netz erreichbar)
✅ PostgreSQL Read-Only (kein Write-Zugriff auf Uni-DB)

Kosten-Übersicht: Was kostet Integration wirklich?

Integrations-Kosten nach Komplexität

Integrations-Typ	Aufwand (Tage)	Kosten (bei 1.200 €/Tag)	Timeline
SSO (OAuth 2.0)	3-5 Tage	3.600-6.000 €	1-2 Wochen
SSO (SAML 2.0)	5-8 Tage	6.000-9.600 €	2-3 Wochen
CRM (Salesforce REST)	6-10 Tage	7.200-12.000 €	2-3 Wochen
CRM (Custom SOAP)	12-20 Tage	14.400-24.000 €	3-5 Wochen
ERP (SAP OData)	15-25 Tage	18.000-30.000 €	4-6 Wochen
ERP (Custom DB)	8-15 Tage	9.600-18.000 €	2-4 Wochen
WebSockets (Realtime)	4-8 Tage	4.800-9.600 €	1-3 Wochen

Gesamt-Budget-Regel: Integration = 10-30% der Entwicklungskosten.

Beispiel:

App-Entwicklung: 60.000 €
+ SSO (OAuth): 5.000 €
+ CRM (Salesforce): 10.000 €
Gesamt: 75.000 € (Integration = 20% Aufschlag)

Bei Legacy-Systemen (SAP On-Premise, Mainframe): Integration kann 50-100% der Entwicklungskosten sein.

Security: OAuth-Tokens, API-Keys, TLS-Pinning

API-Keys: Einfach, aber unsicher

Problem: API-Key im Code hardcoded → jeder mit APK/IPA kann Key extrahieren.

// ❌ FALSCH: API-Key hardcoded
final apiKey = 'sk_live_1234567890abcdef';

Lösung: Environment-Variables + Backend-Proxy

// ✅ RICHTIG: API-Key nur im Backend
final response = await http.post(
  '/api/crm/create-contact',  // Backend-Endpoint
  body: contactData,
);

// Backend macht Request mit API-Key
app.post('/api/crm/create-contact', async (req, res) => {
  const apiKey = process.env.CRM_API_KEY;  // Aus Environment
  await crmApi.createContact(req.body, apiKey);
});

OAuth 2.0 Tokens: Best Practice

Flow:

1. App fordert Access-Token an (OAuth-Flow)
2. Backend gibt Access-Token (Lebensdauer: 1 Stunde)
3. App nutzt Token für API-Requests
4. Token läuft ab → App fordert neuen Token an (Refresh-Token)

Code-Beispiel (Token-Refresh):

String accessToken = await storage.read(key: 'access_token');
String refreshToken = await storage.read(key: 'refresh_token');

// Access-Token abgelaufen? Refresh!
if (isExpired(accessToken)) {
  final response = await http.post('/auth/refresh', body: {
    'refresh_token': refreshToken,
  });
  accessToken = response.data['access_token'];
  await storage.write(key: 'access_token', value: accessToken);
}

Security-Best-Practices:

✅ Access-Token kurzlebig (1 Stunde, nicht 1 Jahr)
✅ Refresh-Token sicher speichern (Keychain/KeyStore, nicht SharedPreferences)
✅ HTTPS Pflicht (Token nie über HTTP senden)

TLS-Pinning: Schutz vor Man-in-the-Middle

Problem: Angreifer fälscht TLS-Zertifikat → liest API-Requests mit.

Lösung: TLS-Pinning → App vertraut nur bestimmtem Zertifikat.

Code-Beispiel (Flutter + TLS-Pinning):

import 'package:http/io_client.dart';
import 'dart:io';

final client = IOClient(
  HttpClient()..badCertificateCallback = (cert, host, port) {
    // Nur Zertifikat mit bestimmtem Fingerprint erlauben
    return cert.sha1.toString() == 'SHA1_FINGERPRINT_DES_SERVERS';
  },
);

Kosten: +1-2 Tage (TLS-Pinning-Setup + Testing)

Vorteil: Schutz vor Man-in-the-Middle-Attacken.

Nachteil: Zertifikat-Rotation kompliziert (neues Zertifikat → App-Update nötig).

Häufige Integrations-Fehler

Fehler 1: Hardcoded Credentials

Problem:

// ❌ API-Key direkt im Code
final apiKey = 'sk_live_1234567890abcdef';
await crmApi.createContact(apiKey, data);

Lösung:

// ✅ Backend-Proxy (API-Key nur im Backend)
await http.post('/api/crm/create-contact', body: data);

Fehler 2: Keine Retry-Logic

Problem: CRM-API ist down (500 Server Error) → App crasht.

Lösung: Exponential Backoff

Future<Response> apiCallWithRetry() async {
  int retries = 0;
  while (retries < 3) {
    try {
      return await http.post('/api/crm/contact');
    } catch (e) {
      retries++;
      await Future.delayed(Duration(seconds: 2 ** retries));  // 2s, 4s, 8s
    }
  }
  throw Exception('API nach 3 Versuchen nicht erreichbar');
}

Fehler 3: Keine Timeout-Limits

Problem: SAP-API antwortet nicht → App hängt 5 Minuten.

Lösung: Timeout setzen

final response = await http
  .post('/api/sap/update-stock')
  .timeout(Duration(seconds: 30));  // Max. 30 Sekunden warten

Fehler 4: Keine Pagination bei großen Datensets

Problem: GET /users gibt 10.000 User zurück → App crasht (Out-of-Memory).

Lösung: Pagination

// ✅ Nur 50 User pro Request
final response = await http.get('/api/users?page=1&limit=50');

Checkliste: Integrations-Strategie definieren

Vor Projektstart

Welche Systeme integrieren? CRM, ERP, HR, Custom?
API-Typen klären: REST, SOAP, GraphQL, DB-Direktzugriff?
SSO-Anforderung? OAuth, SAML, LDAP, oder eigene User-DB?
Datenfluss definieren: App → Backend → CRM (unidirektional) oder bidirektional?
Legacy-Systeme? SAP, Mainframe, Custom-SOAP → Consultant nötig?

Tech-Entscheidungen

API-Strategie: REST (Standard), GraphQL (Mobile-optimiert), WebSockets (Realtime)?
Auth-Strategie: OAuth 2.0 (Cloud), SAML (Enterprise), LDAP (On-Premise)?
Backend-Proxy: Ja (API-Keys sicher) oder direkt aus App (nur bei OAuth)?
Retry-Logic: Exponential Backoff implementiert?
Timeout-Limits: Alle API-Calls haben Timeout (z.B. 30 Sekunden)?

Security

TLS-Pinning: Bei sensiblen Daten (Banking, Health)?
Token-Storage: Keychain/KeyStore (nicht SharedPreferences)?
API-Keys: Nie hardcoded, nur Backend oder Environment-Variables?
HTTPS Pflicht: Alle API-Calls über HTTPS (nie HTTP)?

Nach Integration

Load-Testing: API-Calls mit 100+ parallelen Requests getestet?
Error-Handling: Alle API-Fehler (400, 401, 500) behandelt?
Monitoring: API-Response-Times überwacht (z.B. mit Sentry)?
Dokumentation: API-Endpoints dokumentiert (für Wartung)?

Fazit: Integration ist Pflicht, aber planbar

Die wichtigsten Learnings:

✅ Integration kostet 10-30% der Entwicklungskosten (bei Legacy: 50-100%)
✅ SSO spart Zeit (1 Login für alle Apps → bessere UX)
✅ REST reicht meist (GraphQL nur bei Mobile-Optimierung nötig)
✅ Backend-Proxy schützt (API-Keys nie in App hardcoden)
✅ Retry-Logic Pflicht (APIs sind manchmal down)
✅ Consultant bei Legacy (SAP, Mainframe → nicht alleine probieren)
✅ Datensilos vermeiden (Integration = Single Source of Truth)

Goldene Regel: Integration in Discovery-Phase planen, nicht nach 6 Monaten Entwicklung (“Ach ja, die App muss noch mit SAP sprechen…”).

Lassen Sie uns über Ihre Integrations-Strategie sprechen

Sie wissen nicht, wie Sie Ihre App mit CRM/ERP/SSO verbinden sollen? In einem kostenlosen Erstgespräch (30 Min):

✅ Analysieren wir Ihre bestehenden Systeme (CRM, ERP, HR, Custom)
✅ Definieren wir die optimale API-Strategie (REST, GraphQL, SOAP)
✅ Klären wir SSO-Anforderungen (OAuth, SAML, LDAP)
✅ Schätzen wir Integrations-Kosten transparent (10-30% Aufschlag)

Keine Buzzwords, keine Fantasie-Zahlen – nur ehrliche Einschätzung aus 25+ Jahren Praxis.

Termin vereinbaren →

Weitere hilfreiche Artikel:

Ihr App-Projekt besprechen?

Lassen Sie uns in einem kostenlosen Erstgespräch über Ihre Anforderungen sprechen.

Jetzt Kontakt aufnehmen

App-Integration 2025: CRM, ERP, SSO – Schnittstellen-Strategie

Teilen

Inhaltsverzeichnis

Carola Schulte, App-Entwicklerin

App-Integration 2025: CRM, ERP, SSO – Schnittstellen-Strategie

TL;DR – Die Essenz

Warum Integration Pflicht ist (keine Insellösung)

Das Datensilos-Problem

SSO (Single Sign-On): Ein Login für alles

SSO-Protokolle im Vergleich

OAuth 2.0: Der Standard für Cloud-Apps

SAML 2.0: Enterprise-Standard

LDAP: On-Premise Active Directory

CRM-Integration: Salesforce, HubSpot, Custom

Salesforce-Integration (REST API)

HubSpot-Integration (REST API)

Custom-CRM-Integration (Legacy-Systeme)

ERP-Integration: SAP, Microsoft Dynamics, DATEV

SAP-Integration (OData/REST API)

Microsoft Dynamics 365 (REST API)

DATEV-Integration (SOAP/REST)

API-Strategien: REST vs. GraphQL vs. WebSockets

REST API: Der Standard

GraphQL: Flexibler, aber komplexer

WebSockets: Realtime-Kommunikation

Real Cases: Integration in der Praxis

Case 1: Wächterkontrollsystem (CRM-Sync)

Case 2: Inventur-Scanner (ERP-Export)

Case 3: Mensa-NFC-App (LDAP-SSO + Studenten-DB)

Kosten-Übersicht: Was kostet Integration wirklich?

Integrations-Kosten nach Komplexität

Security: OAuth-Tokens, API-Keys, TLS-Pinning

API-Keys: Einfach, aber unsicher

OAuth 2.0 Tokens: Best Practice

TLS-Pinning: Schutz vor Man-in-the-Middle

Häufige Integrations-Fehler

Fehler 1: Hardcoded Credentials

Fehler 2: Keine Retry-Logic

Fehler 3: Keine Timeout-Limits

Fehler 4: Keine Pagination bei großen Datensets

Checkliste: Integrations-Strategie definieren

Vor Projektstart

Tech-Entscheidungen

Security

Nach Integration

Fazit: Integration ist Pflicht, aber planbar

Lassen Sie uns über Ihre Integrations-Strategie sprechen

Verwandte Themen

Ihr App-Projekt besprechen?