Startseite / Artikel / Webflow API gegen Headless CMS: Rate Limits und tatsächliche Kompromisse

Webflow Headless CMS API CMS Web Development

Webflow API gegen Headless CMS: Rate Limits und tatsächliche Kompromisse

Erklärt die tatsächlichen API-Geschwindigkeitsbeschränkungen, Sammelkapazitäten und Veröffentlichungsbeschränkungen von Webflow, um aufzuzeigen, wann ein headless CMS besser geeignet ist als Webflows integrierte API.

1610 Wörter

Webflow ist ein visueller Site-Builder, der zufällig auch über ein CMS und eine API verfügt. Ein headless CMS hingegen ist ein auf API basierender Inhaltsspeicher ohne jeglichen visuellen Builder. Der Unterschied zwischen den beiden wird erst dann deutlich, wenn der API-Aufkommen Grenzen erreicht – nicht während man noch Elemente auf einer Seite anordnet.

Menschen verwechseln die beiden ständig, meist weil Webflow tatsächlich eine echte API bereitstellt. Doch diese API wurde nicht dafür konzipiert, als primäres Inhaltsbackend für etwas anderes als die von Webflow selbst gerenderten Seiten zu dienen. In diesem Artikel wird erläutert, in welchen Fällen diese API gut funktioniert und wo sie versagt, sowie welche spezifischen Grenzen bestimmen, welches Szenario auf Sie zutrifft.

Was ist Webflows CMS eigentlich?

Webflows CMS basiert auf Collections, die dem Konzept der Inhaltstypen entsprechen. Sie füllen diese über denselben visuellen Editor aus, den man auch zum Gestalten von Seiten verwendet – somit finden Content-Erstellung und Seitendesign innerhalb derselben Tool statt. Das ist das gesamte Wertversprechen, und für eine Marketingseite oder ein Portfolio ist das durchaus überzeugend.

Die API baut auf dieser Struktur auf. Sie stellt Collection-Elemente über REST-Endpunkte zur Verfügung und unterstützt Lesevorgänge sowie eine eingeschränkte Anzahl an Schreibvorgängen. Ihr Zweck besteht darin, dass externe Tools Daten in Webflows eigenes Renderingsystem einbringen können – nicht jedoch, damit ein separates Frontend, eine Mobile-App und ein internes Dashboard alle aus einer einzigen gemeinsamen Quelle ziehen können. Genau für eine solche Mehrverbraucher-Struktur ist ein headless CMS wie Draftbase von Anfang an konzipiert.

Ist Webflow ein headless CMS?

Nein. Webflow ist ein eng vernetztes CMS, das zufällig eine API bereitstellt. Ein echtes headless CMS verfügt überhaupt nicht über eine eingebaute Render-Schicht; jeder Teil der Markup-Struktur stammt vom von einem selbst erstellten Frontend. Webflow hingegen rendernt zuerst immer seine eigenen Seiten – die API dient lediglich als Nebenkanal, nicht als Hauptweg, über den der Inhalt beim Leser ankommt.

Die tatsächlichen API-Beschränkungen von Webflow (und warum sie problematisch sind)

Fast jedes Vergleichsartikel erwähnt, dass „Webflow Beschränkungen hat“, doch nur sehr wenige nennen die konkreten Zahlen, und fast keiner erklärt, welche spezifische Beschränkung tatsächlich zu Problemen führt, sobald das System in der Produktion genutzt wird.

Abschlussraten und die Ausnahme, die niemand erwähnt

Laut der Entwicklerdokumentation von Webflow erlaubt die Data API 60 Anfragen pro Minute bei den Starter- und Basic-Plänen, was auf 120 Anfragen pro Minute bei den CMS-, eCommerce- und Business-Plänen ansteigt. Enterprise-Kunden vereinbaren eine individuelle Obergrenze. Überschreiten Sie diese Grenze, erhalten Sie eine 429-Antwort zurück.

Hier ist der Punkt, den die meisten Artikel überspringen: Anfragen an die Content Delivery API, die aus dem Cache stammen, zählen nicht zu dieser Quotenbegrenzung. Nur Anrufe, die tatsächlich den Origin-Server der Data API erreichen, zählen. Wenn Ihre Integration also wiederholt veröffentlichten Inhalt ohne Änderungen liest, ist Ihre tatsächliche Rate-Limit-Grenze erheblich höher, als die angegebene Zahl vermuten lässt. Wenn Sie jedoch bei jeder Anfrage Daten schreiben oder unvercacheierte Daten abrufen, wird die Obergrenze von 120 Anfragen pro Minute schnell erreicht, sobald Sie mehr als ein paar hundert Elemente synchronisieren.

Sammlungen und Feldanzahl

Auf den CMS- und Business-Plänen ist jede Sammlung auf 60 Felder begrenzt, und jedes mehrfach verweisende Feld kann maximal auf 1.000 Elemente verweisen. Die Preisanpassung von Webflow ab Mai 2026 führte außerdem Obergrenzen für die Anzahl der Elemente pro Plan ein: Der CMS-Plan hat eine Obergrenze von 2.000 Sammlungselementen, der Business-Plan erreicht mit erworbenen Erweiterungen bis zu 20.000 Elemente, und der Enterprise-Plan erhält eine individuell vereinbarte Obergrenze. Keine dieser Grenzen stellt ein Problem für eine kleine Marketingseite mit angehängtem Blog dar. Sie werden relevant, sobald ein Produktkatalog oder eine Dokumentationssammlung die vom Plan zugelassene Größe überschreitet – genauso wie bei einer Inhaltsbibliothek, die mehrere Sprachregionen umfasst.

Eine Veröffentlichung pro Minute

Laut der eigenen Dokumentation zu den Rate-Limits von Webflow sind Aktionen zum Veröffentlichen einer Website auf eine erfolgreiche Veröffentlichung pro Minute beschränkt. Ein CI-Pipeline, der auf jede Fusion in den Hauptbranch auslöst, um eine Veröffentlichung zu initiieren, wird sobald echter Traffic anfällt hinter dieser Grenze warten müssen – und zwar nicht nur im Rahmen eines hypothetischen Randfalls.

Wo eine headless CMS-API völlig anders strukturiert ist

Eine headless CMS ist so konzipiert, dass ihre Delivery-API die primäre Möglichkeit darstellt, Inhalte an Nutzer zu liefern. Es gibt keine Notwendigkeit, zwischen „Cache“ und „Quelle“ zu unterscheiden, denn die Delivery-API ist der einzige Weg, den Inhalte auf dem Weg zu einem Leser nehmen. Die Rate-Limits sowie das Caching sind dabei Kernbestandteile des Designs und nicht einfach auf einen visuellen Editor aufgepfropft, der ursprünglich nicht für solche Traffic-Muster ausgelegt war.

Der tiefere strukturelle Unterschied besteht darin, dass ein headless CMS Content-Modellierung als seine zentrale Schnittstelle betrachtet, wobei jede visuelle Schicht optional oder völlig davon getrennt ist. Webflow kehrt diese Priorität um – der visuelle Builder ist die primäre Schnittstelle, während die API nur als Zusatz hinzugefügt wird. Dieser Unterschied in der Priorität zeigt sich deutlich darin, was jedes Produkt zuerst entwickelt, wenn neue Funktionen hinzugefügt werden.

Wo Webflow wirklich gewinnt

Es ist sinnvoll, dazu gleich klarzustellen: Für ein Marketingteam, das eine präzise visuelle Gestaltung ohne das Schreiben einer einzigen Zeile Code möchte, übertrifft Webflows Builder die Ergebnisse von Draftbase oder jeder anderen headless-Lösung bei dieser spezifischen Aufgabe. Die Layoutsteuerung auf Pixelgenauigkeit durch Drag-and-Drop ist einfach kein Bereich, in dem headless-Plattformen mithalten können – eine andere Darstellung würde alle, die diese beiden Ansätze vergleichen, in die Irre führen. Wenn alle, die am Inhalt arbeiten, keine Technikkenntnisse haben und die Website hauptsächlich aus statischen Seiten besteht, ist Webflows Workflow mit nur einem Tool ein echter Vorteil – kein Kompromiss.

Wo ein headless CMS gewinnt

Betrachten Sie einen Fall, in dem derselbe Inhalt einer Website, einer mobilen App sowie einem internen Tool zur Verfügung gestellt werden muss – und zwar alle aus einem einzigen Schema. Unter Webflow stößt man dabei sofort auf Obergrenzen pro Plan hinsichtlich der Anzahl der Elemente und Felder, wodurch Arbeit, die eigentlich Routine sein sollte, zu einer umfangreichen Migrationsaufgabe wird. Ein headless CMS bietet von Anfang an vorgefertigte Felder sowie Referenzintegrität. Seine Delivery-API ist so konzipiert, dass sie Tausende von Anfragen pro Tag problemlos bewältigen kann. Es gibt keine künstlich festgelegten Obergrenzen. Die API entstand nicht erst später als Anpassung an die Verkehrsmuster eines visuellen Bearbeiters – sie ist vielmehr ein integraler Bestandteil des Produkts selbst.

Wann sollten Sie Webflow statt eines headless CMS verwenden?

Wählen Sie Webflow, wenn die Personen, die den Inhalt bearbeiten, keine Entwickler sind, die Website nur eine begrenzte Anzahl an Seiten hat und nichts außerhalb der eigenen Renderfunktionen von Webflow den Inhalt verändern muss. Denken Sie an die Website eines Restaurants, eine einzelne Landing Page für ein Produkt oder das Portfolio einer kleinen Agentur. In diesen Fällen ist Webflows visuelle Bearbeitung unbestreitbar vorteilhaft, was die Zeit bis zum Launch angeht.

Kann man Webflow mit einem headless CMS kombinieren?

Ja, und bis 2026 wird diese Kombination recht Standard sein. Behalten Sie die Marketing-Website bei Webflow, damit Sie von dessen Designwerkzeugen profitieren können. Extrahieren Sie anschließend alles, was als strukturierte Daten fungiert – wie beispielsweise ein Produktkatalog, eine Dokumentationsbibliothek oder von Nutzern erstellte Inhalte – und verwalten Sie dies über ein separates headless CMS, wobei die Inhalte über eigene Routen dargestellt werden. Auf diese Weise erhalten auch nicht-technische Mitarbeiter weiterhin Webflows Editor für die Inhalte, die sie tatsächlich verwalten, während jeder Teil des Systems, bei dem das Inhaltsvolumen oder die Anzahl der verwendenden Apps ein gekoppeltes CMS übersteigt, stattdessen eine geeignete Delivery-API erhält.

FAQ

Zählt Webflow zu einem headless CMS? Nicht wirklich. Es bietet zwar eine API zum Lesen von Daten und Schreiben in Sammlungen – allerdings nur eingeschränkt –, doch im Grunde handelt es sich um ein gekoppeltes CMS, das ursprünglich dafür konzipiert ist, seine eigenen Seiten darzustellen. Ein echtes headless CMS verfügt überhaupt nicht über eine eingebaute Darstellungsschicht.

Welche Rate-Limit-Grenze gilt für Webflows API? Laut der Entwicklerdokumentation von Webflow erhalten die Starter- und Basic-Pläne 60 Anfragen pro Minute, die CMS-, eCommerce- und Business-Pläne 120, während bei den Enterprise-Plänen eine individuell vereinbarte Grenze gilt. Zu beachten ist, dass gepufferte Antworten aus der Content Delivery API nicht in diese Quoten einbezogen werden.

Wie viele Elemente kann eine Webflow-Kollektion enthalten? 2.000 Elemente beim CMS-Plan, erhöht auf 20.000 bei Business mit kostenpflichtigen Zusatzleistungen, und bei Enterprise gibt es eine verhandelbare Obergrenze. Diese Zahlen stammen aus Webflows Preisaktualisierung im Mai 2026.

Ist es möglich, Webflows CMS als Backend für eine völlig separate Anwendung zu verwenden? Im Prinzip ja, über seine API. Doch bereits früh stoßen Sie auf die zuvor beschriebenen Beschränkungen wie Datensatzlimits, Feldbeschränkungen und Bandbreitenbegrenzungen – lange bevor das bei einem system speziell für die Inhaltsbereitstellung entwickelt der Fall wäre. Webflows API dient dazu, Daten in sein eigenes Renderingsystem zu synchronisieren, und nicht als allgemeines Backend für externe Anwendungen.

Die ehrliche Antwort

Webflow und ein headless CMS sind dazu konzipiert, unterschiedliche Probleme zu lösen – es handelt sich dabei nicht um konkurrenzierende Versionen desselben Systems. Die in diesem Artikel beschriebenen API-Beschränkungen sind kein Designfehler, sondern das natürliche Ergebnis der Entwicklung einer API um einen visuellen Editor herum und nicht umgekehrt. Wenn Ihr Team keine Entwickler hat und die Website problemlos in den Kapazitätsrahmen eines Plans passt, bringt Webflow Sie schneller ans Ziel. Wenn Sie mehr als eine Frontend-Anwendung mit einem einzigen Inhaltmodell versorgen müssen, ist Draftbases headless CMS von Grund auf so konzipiert, dass solche Grenzen vollständig vermieden werden. Ein begleitendes Dokument geht dieser Entscheidung ausführlicher auf die Implementierungsebene ein. Sie finden es auf HackMD: Es behandelt das Abrufen und Caching von Inhalten über eine echte Delivery-API unter Verwendung von Node.js und Express.