WhatsApp Cloud API vs. On-Premise API:Was solltest du 2026 verwenden?
21. Mai 2026
·
12 Min. Lesezeit
In diesem Artikel: Die 60-Sekunden-Antwort · Zwei Architekturen · Vollständige Vergleichstabelle · Der Deprecation-Zeitplan · Durchsatz & Rate Limits · Echte Kostenaufschlüsselung · Das Inbound-Webhook, über das niemand spricht · Was sich bei der Migration ändert · FAQ
Die 60-Sekunden-Antwort
2026 ist das keine Wahl mehr. Die WhatsApp On-Premise API hat am 23. Oktober 2025 ihr offizielles End-of-Life erreicht. Meta hat keine Sicherheitspatches mehr ausgeliefert, akzeptiert seit dem 15. Januar 2024 keine neuen Nummer-Registrierungen mehr und hat den On-Premise-Stack als nicht unterstützte Software markiert. Wenn du noch einen selbst gehosteten Docker-Container betreibst, bist du auf toter Infrastruktur.
Die WhatsApp Cloud API — bei der Meta den Server hostet, Skalierung übernimmt, Patches ausliefert und eingehende Nachrichten an deine Webhook-URL pusht — ist seit Mitte 2022 der Standard für jede neue WhatsApp Business-Nummer. Die Cloud API ist günstiger, schneller zu provisionieren, hat höheren Durchsatz und erhält neue Features zuerst. Es gibt 2026 kein Szenario, in dem On-Premise die richtige Antwort für eine neue Integration wäre.
On-Premise EOL: 23. Okt. 2025Keine neuen Patches — niemalsCloud API: Standard seit 2022Cloud API Infra-Kosten: $0Cloud-Durchsatz: 1.000 Msg/sOn-Premise Peak: ~30–50 Msg/s
Zwei Architekturen, ein Plattformname
Sowohl die Cloud API als auch die On-Premise API sind technisch Teil der „WhatsApp Business Platform". Das Branding ist identisch. Die Architektur ist komplett unterschiedlich — und das Verständnis der Architektur ist der einzige Weg zu verstehen, warum die Cloud API gewonnen hat.
WhatsApp Cloud API (Meta-gehostet)
Deine Anwendung sendet einen HTTP POST an https://graph.facebook.com/v21.0/{phone_number_id}/messages. Meta empfängt ihn, routet die Nachricht durch sein WhatsApp-Backend, liefert sie an den Kunden aus und pusht Zustellstatus sowie eingehende Antworten zurück an deine registrierte Webhook-URL. Du fasst niemals einen Server an. Authentifizierung erfolgt über ein permanentes Access Token plus HMAC-SHA256-Payload-Signaturen. Media wird auf Metas CDN gehostet mit 90-Tage-Retention.
WhatsApp On-Premise API (selbst gehostet, eingestellt)
Du — oder dein BSP — betreibst zwei von Meta veröffentlichte Docker-Images (whatsapp/coreapp und whatsapp/web) auf deiner eigenen Infrastruktur. Das coreapp verbindet sich outbound zu Metas Relay, cached Nachrichten in einer MySQL-Datenbank und exposes eine REST API auf Port 443. Dein Team managed Certificate Rotation, MySQL-Replikation, Media-Speicher, Backups und jeden Sicherheitspatch, den Meta veröffentlicht. Die minimale Hardware-Spezifikation war 4 vCPU und 8 GB RAM pro Telefonnummer.
Wenn du noch auf On-Premise bist: Der letzte Sicherheitspatch wurde am 23. Oktober 2025 ausgeliefert. Keine zukünftigen Patches sind geplant. Du betreibst Software mit bekannten, ungepatchten Schwachstellen, null Feature-Updates und keinem Meta-Support. Migration ist nicht optional — sie ist überfällig.
Vollständige Vergleichstabelle
Dimension
Cloud API
On-Premise API
Status 2026
Aktiv — Standard
EOL 23. Okt. 2025
Wer hostet den Server
Meta
Du oder dein BSP
Hardware-Footprint
Keiner
4 vCPU + 8 GB RAM Minimum pro Nummer
Setup-Zeit (via BSP)
Unter 10 Minuten
2–6 Wochen (Container-Deploy + Cert-Install)
Authentifizierung
Access Token + HMAC-SHA256
Client-Zertifikat + Admin Bearer Token
Durchsatz (Standard)
80 Msg/s pro Nummer
30–50 Msg/s (hardware-limitiert)
Durchsatz (Maximum)
1.000 Msg/s auf Anfrage
80 Msg/s mit Multi-Node + Load Balancer
Inbound Webhooks
HTTP POST an deine URL — Graph API-Format
HTTP POST an deine URL — On-Premise REST-Format
Sicherheitspatches
Automatisch von Meta gepusht
Manuelles Pull-and-Deploy — keine seit Okt. 2025
Media-Hosting
Meta CDN, 90-Tage-Retention
Dein Speicher, deine Retention-Policy
Neue Features (Flows, etc.)
Tag eins
Spät backported — oder nie
Infrastruktur-Kosten/Monat
$0
$400–$1.200 pro Telefonnummer
Kosten pro Konversation
Identisches Meta-Preisraster
Identisches Meta-Preisraster
Graph API-Unifizierung
Ja — gemeinsame Surface mit FB + IG
Nein — separate REST-Surface
Daten-Residenz
Meta-Rechenzentren (US/EU)
Deine Wahl
Neue Nummer-Registrierung
Offen
Geschlossen seit 15. Jan. 2024
Der Deprecation-Zeitplan
Die meisten Vergleichsartikel übergehen die Daten. Diese Daten sind die ganze Geschichte. Wenn du noch auf On-Premise bist, sagt dir das genaue Wissen, wann jede Tür geschlossen wurde, wie dringend deine Situation ist.
1. August 2018
On-Premise API gestartet
WhatsApp Business API wird ausschließlich mit On-Premise ausgeliefert. Selbst gehostete Docker-Container erforderlich. Die Enterprise-WhatsApp-Story beginnt.
19. Mai 2022
Cloud API erreicht General Availability
Angekündigt auf F8 2022. Cloud API wird für alle Unternehmen verfügbar. Meta empfiehlt Cloud sofort als bevorzugten Integrationspfad für alle neuen Nummern.
27. Oktober 2023
On-Premise API offiziell deprecated Deprecated
Meta veröffentlicht die Deprecation-Notice. End-of-Life-Datum auf den 23. Oktober 2025 gesetzt. Die Uhr startet. Jeder On-Premise-Betreiber wird auf einen obligatorischen Migrationszeitplan gesetzt.
15. Januar 2024
Neue Nummer-Registrierungen auf On-Premise geschlossen
Meta akzeptiert keine neuen WhatsApp Business-Nummern mehr auf dem On-Premise-Stack. Alle neuen Nummern müssen Cloud API verwenden. Bestehende On-Premise-Nummern können weiterhin betrieben werden — vorübergehend.
23. Oktober 2025
Offizielles End-of-Life — letzter Sicherheitspatch End of Life
Der finale Sicherheitspatch wurde ausgeliefert. On-Premise-Container sind nun nicht unterstützte Software. Keine zukünftigen Patches, keine Bugfixes, keine Feature-Backports. Jeder On-Premise-Betreiber, der 2026 noch läuft, betreibt eine eingefrorene, ungepatchte Codebase.
2026 und darüber hinaus
Cloud API — der einzige unterstützte Pfad Aktiv
Cloud API ist der einzige unterstützte WhatsApp Business API-Integrationspfad. WhatsApp Flows, Calling API (gestartet Juli 2025), neue interaktive Nachrichtentypen — alle landen zuerst auf Cloud und künftig ausschließlich auf Cloud.
Durchsatz und Rate Limits: Die Zahlen, die tatsächlich zählen
Tägliche Messaging-Tiers sind zwischen Cloud und On-Premise identisch — sie werden durch Metas Phone-Number-Quality-Scoring-System festgelegt, nicht durch die API, die du verwendest. Beide APIs teilen sich dieselben vier Tiers:
Tier 1: 1.000 einzigartige business-initiierte Kunden pro 24 Stunden (Standard für alle neuen Nummern)
Tier 2: 10.000 einzigartige Kunden pro 24 Stunden
Tier 3: 100.000 einzigartige Kunden pro 24 Stunden
Tier 4: Unbegrenzt pro 24 Stunden
Session-Nachrichten (Antworten innerhalb eines vom Kunden geöffneten 24-Stunden-Fensters) haben kein tägliches Limit auf irgendeinem Tier. Wo die Cloud API On-Premise dramatisch übertrifft, ist der Durchsatz pro Sekunde:
Cloud API
1.000 Msg/s
pro Telefonnummer (auf Anfrage)
80 Msg/s out of the box. Skalierbar auf 1.000 Msg/s auf Anfrage für High-Volume-Sender. Meta absorbiert die Last — keine Infra-Änderungen auf deiner Seite erforderlich.
On-Premise API
30–50 Msg/s
praktisches Limit (Single Node)
80 Msg/s-Cap gilt theoretisch, aber Single-Node Docker auf einer 4-vCPU-VM sättigt typischerweise bei 30–50 Msg/s. Um 80 Msg/s zu erreichen, benötigt man ein MySQL-Replica, Multi-Node-Setup und einen Load Balancer.
Für eine Black-Friday-Kampagne, die 100.000 Nachrichten in einem Ein-Stunden-Fenster versendet, absorbiert die Cloud API die Last ohne Konfiguration. On-Premise erfordert Engineering-Arbeit im Voraus — Multi-Node-Deployment, MySQL-Replikation, Load Balancer vor dem coreapp — und stößt dann immer noch an eine harte Obergrenze, die die Cloud API vollständig entfernt.
Was du tatsächlich zahlst
Metas Preisgestaltung pro Konversation ist für beide APIs identisch. Der Unterschied liegt ausschließlich in den fixen Infrastrukturkosten. Die meisten Vergleichsartikel überspringen diesen Teil, weil er für BSPs, die noch On-Premise-Stacks betreiben, unvorteilhaft ist.
Cloud API — monatliche Kosten pro Nummer
Server-Hosting$0
Datenbank (MySQL)$0
Zertifikats-Management$0
Security-Patching / DevOps$0
Media-Speicher$0 (Meta CDN)
Meta-KonversationsgebührenNach Volumen
Fixer Infra-Overhead$0 / Monat
On-Premise API — monatliche Kosten pro Nummer
Server-Hosting (4 vCPU / 8 GB)$150–$400
MySQL (repliziert)$80–$200
TLS-Zertifikats-Management$20–$60
Engineering On-Call$150–$400
Media-Speicher / CDN$30–$140
Meta-KonversationsgebührenNach Volumen
Fixer Infra-Overhead$430–$1.200 / Monat
Diese Infrastrukturkosten gelten pro Telefonnummer. Eine Agentur, die 10 Kunden-WhatsApp-Nummern auf On-Premise verwaltet, hat $4.300–$12.000/Monat verbrannt, bevor sie Meta auch nur eine einzige Konversationsgebühr gezahlt hat. Die Cloud API eliminiert diesen gesamten Kostenpunkt.
Das Stück, das jeder Vergleichsartikel verpasst: Inbound-Webhooks auf der Cloud API
Jeder Artikel über Cloud API vs. On-Premise fokussiert sich auf Outbound — Kampagnen senden, Templates, Broadcasts. Fast keiner erklärt, was mit inbound Nachrichten auf der Cloud API passiert, und hier stoßen die meisten Teams nach der Migration auf Probleme.
Wenn ein Kunde eine Nachricht an deine WhatsApp Business-Nummer sendet, die über die Cloud API verbunden ist, feuert Metas Infrastruktur eine HTTP-POST-Anfrage an deine registrierte Webhook-URL. Das passiert innerhalb von Millisekunden. Der Payload ist ein strukturiertes JSON-Objekt im Graph-API-Format von Meta. Dein Server — oder eine Webhook-Plattform — muss:
Jederzeit öffentlich über HTTPS erreichbar sein
Fähig sein, innerhalb von 20 Sekunden mit HTTP 200 zu antworten (ansonsten wiederholt Meta)
Die HMAC-SHA256-Signatur im X-Hub-Signature-256-Header vor der Verarbeitung verifizieren
Das Graph-API-Payload-Format parsen — das sich vom On-Premise-REST-Format unterscheidet
So sieht ein Cloud-API-Inbound-Nachrichten-Payload aus, wenn er über SocialHooks WhatsApp-Webhook-Integration normalisiert wird — ausgeliefert an deinen Endpoint in einem konsistenten Format unabhängig vom Nachrichtentyp:
cloud-api-inbound-payload.json — ausgeliefert <50ms via SocialHook
{ "platform":"whatsapp", "event":"message.received", "timestamp":1747123456, "from":"+44 7700 900 123", "conversation_id":"conv_4m9x...", "message": { "type":"text", "body":"Ich bin gerade zur Cloud API gewechselt. Wann startet das Onboarding?", "id":"wamid.HBgL..." }, "delivery": { "status":"delivered", "latency_ms":38 } }
SocialHooks Rolle in einem Cloud-API-Stack: Metas Cloud API liefert Inbound-Events an einen einzigen Endpoint. SocialHook sitzt zwischen Meta und deinem Server — übernimmt Webhook-Verifizierung (HMAC-SHA256), normalisiert das Graph-API-Payload-Format, fügt automatisches 3x-Retry mit exponentiellem Backoff hinzu, falls dein Server einen Non-200 zurückgibt, und loggt jede Zustellung mit voller Status-Historie. Dein Server empfängt ein sauberes, konsistentes JSON-Event. Es ist egal, ob die Nachricht von WhatsApp, Facebook Messenger oder Instagram DMs kam — das Payload-Format ist über alle drei identisch. Ein Endpoint. Drei Kanäle. Flat $50/Monat.
Was sich tatsächlich ändert, wenn du von On-Premise zur Cloud API migrierst
Die Migration deiner Telefonnummer von On-Premise zur Cloud API wird unterstützt und erhält deine Nummer — Kunden bemerken keine Änderung. Aber dein serverseitiger Code benötigt Updates an drei spezifischen Stellen, die die meisten Migrations-Guides in Fußnoten vergraben.
1
Authentifizierungsmethode Breaking Change
On-Premise nutzte Client-TLS-Zertifikate und einen Admin-Bearer-Token. Cloud API nutzt ein permanentes Access Token für Outbound und HMAC-SHA256 für Inbound-Payload-Verifizierung. Du musst deine Auth-Header aktualisieren und die Signatur-Verifizierungsprüfung in deinem Webhook-Handler implementieren, bevor du live gehst.
2
Inbound-Payload-Struktur Breaking Change
Die On-Premise-REST-API und die Cloud-API-Graph-API verwenden unterschiedliche JSON-Strukturen für Inbound-Webhook-Events. Feldnamen, Verschachtelung und Metadaten unterscheiden sich. Dein Payload-Parser benötigt ein komplettes Rewrite — oder du nutzt eine Normalisierungsschicht wie SocialHook, die dies komplett von deinem Anwendungscode abstrahiert.
3
Media-Download-Logik
On-Premise speicherte eingehende Media auf deinem Server. Cloud API speichert Media auf Metas CDN mit einer 90-Tage-Retention-Policy. Wenn ein Kunde ein Bild oder Dokument sendet, enthält dein Webhook-Payload eine Media-ID. Du musst die Cloud API aufrufen, um die Download-URL abzurufen, dann die Datei fetchen. Bestehender Code, der von einem lokalen Pfad liest, wird brechen.
4
Outbound-API-Endpoint
On-Premise exposed eine REST API auf Port 443 deines Containers. Cloud API nutzt den Meta-Graph-API-Endpoint unter graph.facebook.com. Das Request-Format, der Authentication-Header und die URL-Struktur unterscheiden sich alle. Aktualisiere deine HTTP-Client-Konfiguration und Request-Bodies entsprechend.
5
Infrastruktur herunterfahren
Nach Migration und Validierung: Decommission deine Docker-Container, MySQL-Instanz und zugehöriges Monitoring. Hier reclaimst du die $400–$1.200/Monat. Verifiziere, dass kein Anwendungscode mehr auf den alten lokalen Endpoint zeigt, bevor du decommissionst.
Ist On-Premise 2026 jemals die richtige Antwort?
Wir lesen jedes Argument für das Behalten von On-Premise 2026. Hier ist die ehrliche Analyse:
Daten-Residenz-Anforderungen
Das stärkste historische Argument für On-Premise war Datenhoheit — Message-Metadaten innerhalb deiner eigenen VPC zu halten, in einer spezifischen Jurisdiktion. Cloud API sendet Daten durch Metas Infrastruktur (US- und EU-Rechenzentren). Für Unternehmen unter bestimmten Government- oder Finanzregularien war das eine genuine Constraint. 2026 werden die meisten dieser Szenarien durch Metas GDPR-konforme EU-Daten-Residenz-Einstellungen gelöst, oder durch Metas Enterprise-API-Tiers mit expliziten Data-Processing-Agreements. Das Daten-Residenz-Argument überlebt selten noch eine Legal-Review — und es überlebt nicht das Security-Argument, ungepatchte Software zu betreiben.
Legacy-BSP-Stacks
Einige BSPs haben ihre gesamte On-Premise-Flotte noch nicht zur Cloud API migriert. Wenn dein WhatsApp-Stack von einem BSP managed wird und sie dich noch nicht migriert haben: Dräng sie. Hart. Sie betreiben unsupported Software in deinem Namen. Jeder Security-Incident auf ihrem On-Premise-Stack nach Oktober 2025 ist ihre Liability — und potenziell deine.
Das Urteil
Es gibt 2026 kein New-Build-Szenario, in dem On-Premise die richtige Wahl wäre. Für bestehende On-Premise-Deployments mit Daten-Residenz-Constraints: Konsultiere dein Legal-Team zu Metas DPA-Terms und EU-Rechenzentrums-Optionen, dann migriere so schnell, wie diese Review es erlaubt. Ungepatchte Software zu betreiben ist keine valide Compliance-Posture für irgendeine regulierte Industry.
Wenn du heute eine neue WhatsApp-Integration baust: Starte mit der Cloud API. Nutze einen BSP oder eine Webhook-Plattform für das Setup. Registriere deine Telefonnummer, konfiguriere deinen Webhook-Endpoint, und lass deine erste Inbound-Nachricht zu deinem Server fließen. Der gesamte Prozess — inklusive Verbindung zu SocialHook, damit dein Webhook sauberes JSON empfängt — dauert unter 15 Minuten. Sieh dir den Quickstart-Guide an.
FAQ
Häufige Fragen
Wird die WhatsApp On-Premise API 2026 noch unterstützt?
Nein. Meta hat sie am 27. Oktober 2023 offiziell deprecated, und das finale End-of-Life-Datum war der 23. Oktober 2025. Seit diesem Datum wurden keine Security-Patches mehr ausgeliefert, keine neuen Telefonnummern können auf On-Premise registriert werden (das schloss am 15. Januar 2024), und keine neuen Features werden jemals backported. Jeder, der 2026 noch einen selbst gehosteten Container betreibt, ist auf unsupported, ungepatchter Software.
Was ist die WhatsApp Cloud API und wie unterscheidet sie sich von On-Premise?
Die WhatsApp Cloud API ist Metas gehostete Version der WhatsApp Business Platform. Du rufst graph.facebook.com auf, um Nachrichten zu senden — Meta betreibt die gesamte Infrastruktur. On-Premise erforderte, dass du Docker-Container auf deinen eigenen Servern betreibst, MySQL managst, TLS-Zertifikate rotierst und Security-Patches selbst auslieferst. Cloud API eliminiert all diesen Operational-Overhead.
Was sind die Durchsatz-Limits der WhatsApp Cloud API?
Cloud API unterstützt standardmäßig 80 Nachrichten pro Sekunde pro Telefonnummer, skalierbar auf 1.000 Nachrichten pro Sekunde auf Anfrage für High-Volume-Sender. Tägliche Messaging-Tiers (1K / 10K / 100K / unbegrenzt einzigartige Kunden pro 24h) sind zwischen Cloud und On-Premise identisch — sie werden durch Metas Quality-Scoring-System gesteuert, nicht durch die API-Version.
Brauche ich einen eigenen Server, um Inbound-WhatsApp-Nachrichten auf der Cloud API zu empfangen?
Ja — oder du brauchst eine Webhook-Plattform. Wenn ein Kunde deine Nummer anschreibt, feuert Cloud API einen HTTP POST an deine registrierte Webhook-URL. Du brauchst einen öffentlich erreichbaren Server (oder einen Service wie SocialHook), um den Payload zu empfangen, die HMAC-SHA256-Signatur zu verifizieren und zu verarbeiten. Ohne einen funktionierenden Webhook-Endpoint erreichen dich Inbound-Nachrichten einfach nicht programmatisch.
Wie vergleicht sich die Cloud-API-Preisgestaltung mit der On-Premise-Preisgestaltung?
Metas Preisgestaltung pro Konversation ist für beide identisch. Der echte Unterschied sind fixe Infrastrukturkosten. On-Premise erforderte $400–$1.200/Monat pro Telefonnummer für Hosting, MySQL, Monitoring und Engineering. Cloud API hat $0 Infrastrukturkosten — Meta absorbiert sie komplett. Total Cost of Ownership bei Cloud API ist typischerweise 30–60 % niedriger als bei On-Premise bei gleichem Nachrichtenvolumen.
Was ändert sich auf meinem Server, wenn ich von On-Premise zur Cloud API migriere?
Drei Breaking Changes: (1) Authentifizierung — On-Premise nutzte Client-Zertifikate; Cloud API nutzt ein Access Token und HMAC-SHA256-Signatur-Verifizierung. (2) Payload-Struktur — Cloud API nutzt das Graph-API-JSON-Format, das sich von On-Premises REST-Struktur unterscheidet. (3) Media-Handling — On-Premise speicherte Media auf deinem Server; Cloud API speichert sie auf Metas CDN, was einen API-Call erfordert, um Download-URLs abzurufen. Dein Webhook-Handler, Payload-Parser und Media-Logik benötigen alle Updates.
Cloud API ist live. Starte, Webhooks zu empfangen.
Verbinde deine WhatsApp Cloud API-Nummer mit SocialHook und erhalte jede Inbound-Nachricht als sauberes JSON an deinen Server ausgeliefert — verifiziert, normalisiert, bei Fehlern automatisch retried — in unter 50ms. Keine Infra. Kein Docker. Keine On-Call-Rotation.
Aufhören, Meta APIs zu verwalten. Anfangen zu bauen.
Verbinde dein erstes Facebook-, Instagram- oder WhatsApp-Konto in unter 2 Minuten. Dein Webhook erhält sein erstes Payload, bevor dein Kaffee kalt wird.
