Emre Demir

Posted on Apr 27 • Originally published at apidog.com

Zuplo API Gateway: Was ist das?

Die meisten API-Gateways wirken immer noch wie für ein Ops-Team von 2014 gebaut: Sie schreiben YAML, kämpfen mit einer Control Plane und brauchen Clusterzugriff, um Änderungen zu deployen. Zuplo geht einen anderen Weg. Es ist ein programmierbares, Edge-natives API-Gateway: Routen leben im Git-Repository, Richtlinien in TypeScript – Deployment geschieht global in Sekunden mit jedem Commit.

Teste Apidog noch heute

In diesem Leitfaden erfährst du, was Zuplo kann, wie es sich von Kong und AWS API Gateway unterscheidet, was es kostet und wie du in unter 30 Minuten dein erstes Gateway produktiv setzt. Es gibt konkrete Codebeispiele zu Routing, Authentifizierung, Ratenbegrenzung und Tipps, wie du mit Apidog jede Route testest, bevor du live gehst.

Zuplo ist in der Kategorie von Kong, Apigee und AWS API Gateway, aber mit anderem Fokus: Entwickler bekommen eine echte Programmiersprache, Betrieb einen managed Service und das Produkt eine integrierte Monetarisierung. Hier findest du die wichtigsten Unterschiede und einen Workflow zum Einstieg.

TL;DR

Zuplo ist ein vollständig verwaltetes, Edge-natives API-Gateway, das Routen in über 300 Cloudflare-Rechenzentren mit Latenzen < 50 ms ausführt – ohne Kaltstarts.
Konfiguration via GitOps: Alles lebt im Git-Repository, Deployment läuft über CI/CD, nicht per UI.
Richtlinien in TypeScript: Volle IDE-Unterstützung, kein YAML oder Lua.
Kostenloser Plan: 100.000 Anfragen/Monat, unbegrenzte Umgebungen, API-Schlüssel und Entwicklerportale.
Features: API-Key Auth, JWT, OAuth2, Rate Limiting, Request-Validierung, Dev-Portal, Stripe-Monetarisierung.
MCP Server Handler: Jede Route ist für Claude, Codex, Cursor und MCP-Clients erreichbar.
End-to-End Tests: Jede Route kann mit Apidog getestet werden, bevor du produktiv gehst.

Was ist Zuplo?

Zuplo ist eine API-Management-Plattform, die drei Prinzipien verfolgt: Code statt Konfiguration, Edge statt Region, Git statt GUI. Bereitstellung erfolgt global im Cloudflare Edge (300+ Standorte) – keine zusätzliche Ops-Arbeit.

Im Gegensatz zu klassischen Gateways (YAML in der Control Plane) wird bei Zuplo das Gateway als TypeScript-Projekt behandelt. Wichtige Bestandteile:

routes.oas.json beschreibt Endpunkte.
TypeScript-Module für individuelle Logik.
Richtlinien-Konfiguration als Code.
GitHub-Push löst Build, Validierung und Deployment aus.

Unterstützte Protokolle: REST, GraphQL, gRPC, WebSockets, SOAP. SOC 2 Typ II, Multi-Cloud-Backends (AWS, Azure, GCP), optional selbst gehostet auf Kubernetes. Preisgestaltung (ab kostenlos) findest du hier.

Warum Entwickler Zuplo Kong, Apigee und AWS API Gateway vorziehen

Jedes Gateway hat seine Stärken:

Kong ist Open Source, aber oft Lua-lastig.
Apigee ist Enterprise, aber komplex.
AWS API Gateway ist Standard in AWS, aber kein Dev-Portal und hohe Lambda-Kaltstarts.

Zuplo richtet sich an kleine Teams mit Enterprise-Anspruch, aber ohne Platform-Engineering-Ressourcen. Unterschiede:

TypeScript statt YAML: Ratenbegrenzung in 3 Zeilen TypeScript, statt 15 Zeilen YAML wie bei Kong.
Entwicklerportal inklusive: Automatisch generiert aus OpenAPI, auch im kostenlosen Plan.
GitOps-first: Jede Änderung ist ein Pull Request. Revert, Review, Audit – alles in Git.
Edge-nativ: Läuft auf Cloudflare Workers – Anfragen starten in wenigen ms, keine Kaltstarts wie bei AWS Lambda.

Fazit: Wenn du neu startest oder dein aktuelles Gateway schmerzt, bietet Zuplo den modernsten Workflow.

Kernfunktionen des Zuplo API-Gateways

TypeScript-Programmierung

Gateway-Logik wird in TypeScript-Modulen direkt neben den Routen definiert. Beispiel: Ein ausgehender Handler entfernt einen internen Header:

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

export default async function (
  response: Response,
  request: ZuploRequest,
  context: ZuploContext,
) {
  response.headers.delete("x-internal-trace-id");
  return response;
}

Speichere diese Datei unter modules/strip-internal-header.ts, referenziere sie im Routing, pushe zu Git – fertig.

Über 60 vorgefertigte Richtlinien

Standardfälle wie Auth, JWT, OAuth2, Rate Limiting, Schema-Validierung, CORS, IP-Whitelist, Request-Transformation usw. sind als Policies verfügbar. Konfiguration erfolgt per JSON in der Routen-Definition, kein Coding notwendig.

Automatisch generiertes Entwicklerportal

Einfach OpenAPI-Spec referenzieren – schon gibt’s ein gehostetes Portal mit Try-it-Out, Codebeispielen (curl, JS, Python, Go) und Self-Service API-Key-Generierung. Ideal für SaaS-APIs.

Integrierte API-Monetarisierung

Per Stripe-Integration API-Zugang verkaufen: Pläne definieren, Stripe verbinden, Checkout läuft über das Portal. Spart Wochen Eigenentwicklung.

MCP-Server-Handler für KI-Agenten

Neu: Bestehende APIs können via MCP Handler für Claude, Codex, Cursor & Co. verfügbar gemacht werden – Auth und Rate Limiting greifen wie für menschliche User. MCP-Integration Guide.

Edge-Deployment, <50ms Latenz

Jedes Gateway wird global auf 300+ Cloudflare-Edges bereitgestellt. Keine Konfiguration nötig, Latenz am Edge <50ms.

Wie funktioniert Zuplo technisch?

Eine Anfrage durchläuft folgende Pipeline:

Routenabgleich: URL/Method gegen routes.oas.json.
Eingehende Richtlinien: Auth, JWT, Rate Limit etc. werden nacheinander geprüft.
Handler: Leitet an Upstream weiter, gibt statischen Wert zurück, führt TS-Code oder MCP-Handler aus.
Ausgehende Richtlinien: Response-Transformationen, Header-Entfernung etc.
Antwort: Response an Client, Logging & Metriken an Zuplo oder eigenen Provider.

Läuft alles als Cloudflare Worker – daher niedrige Latenz und keine Überprovisionierung.

Erstes Zuplo Gateway einrichten – Schritt für Schritt

In ca. 30 Minuten ist ein Gateway produktiv. Workflow:

Account auf zuplo.com anlegen und neues Projekt mit GitHub-Repo erstellen.
OpenAPI-Spec importieren: Bestehende Spec nutzen oder Routen skizzieren und später exportieren.
API-Key-Auth hinzufügen: Im Route-Editor Policy api-key-inbound hinzufügen. Zuplo erzeugt Datenbank/UI für Key-Management.
Rate Limiting konfigurieren: Policy rate-limit-inbound (z.B. 100 Requests/Minute/API-Key) als JSON-Block in die Route einfügen.
Deployen: Branch pushen, Zuplo baut Preview mit eigener URL. Merge in Main bringt in Produktion.
End-to-End testen: Mit Apidog Anfragen mit gültigen/ungültigen Keys, Rate-Limit und fehlerhaften Payloads testen – Response-Inspektor zeigt, ob die richtigen Policies greifen.

Das Setup dauert Minuten. Die meiste Zeit investierst du ins sinnvolle Routing und Custom Logic – plattformunabhängig.

Eigene Richtlinien in TypeScript schreiben

Für spezielle Anforderungen – z.B. Enrichment aus internen Diensten – schreibst du Custom Policies:

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

interface UserContext {
  userId: string;
  plan: "free" | "pro" | "enterprise";
}

export default async function (
  request: ZuploRequest,
  context: ZuploContext,
): Promise<ZuploRequest | Response> {
  const apiKey = request.user?.sub;
  if (!apiKey) {
    return new Response("Unauthorized", { status: 401 });
  }

  const lookupUrl = `https://internal.example.com/users/${apiKey}`;
  const userResponse = await fetch(lookupUrl, {
    headers: { authorization: `Bearer ${context.environment.INTERNAL_TOKEN}` },
  });

  if (!userResponse.ok) {
    return new Response("User lookup failed", { status: 502 });
  }

  const user = (await userResponse.json()) as UserContext;
  request.headers.set("x-user-id", user.userId);
  request.headers.set("x-user-plan", user.plan);
  return request;
}

Wichtig:

Policy ist eine Async-Funktion – einfach testbar.
Umgebungsvariablen via context.environment.
Rückgabe von Response bricht die Pipeline sauber ab.

Zuplo Preisgestaltung (2026)

Drei Pläne:

Kostenlos (0 $/Monat): 100.000 Anfragen/Monat, unbegrenzte Umgebungen, API-Schlüssel & Portale, 1 GB Egress, 2 Devs, echtes Production-Level.
Builder (25 $/Monat): Bis 1 Mio Anfragen/Monat, 2 Domains, mehr Egress, Community Support.
Enterprise (ab 1.000 $/Monat, annual): Unbegrenzt, SLA-Optionen, SSO, RBAC, Add-ons, Self-Hosted, 24/7.

AI Gateway & Dev Portal haben eigene, auch Open-Source-Modelle. Aktuelle Preise vor Vertragsabschluss prüfen.

Vergleich: AWS API Gateway startet bei 3,50 $/Mio REST-Requests (plus Daten, Lambda), Kong Enterprise deutlich teurer als Zuplo.

Wann passt Zuplo – und wann nicht?

Zuplo passt, wenn:

Managed Gateway erwünscht, aber kein Kubernetes-Self-Hosting.
Team arbeitet mit TypeScript/JavaScript.
Integriertes Entwicklerportal benötigt.
Monetarisierung per Stripe integriert sein soll.
API soll von KI-Agenten via MCP angesprochen werden.
Globaler Traffic & Edge-Latenz relevant sind.

Zuplo passt nicht, wenn:

Volle Open-Source-Kontrolle über Gateway-Code nötig (Kong).
On-Premises-Stack ohne Internet-Egress (Kong/Tyk).
Spezialanforderungen auf NGINX-Ebene.
Starke Investition in Apigee/MuleSoft und Migration lohnt nicht.

Testen deines Zuplo Gateways mit Apidog

Sobald das Gateway als Preview läuft, solltest du jede Route und Policy systematisch testen. Ein dedizierter API-Client beschleunigt das:

Apidog importiert deine OpenAPI-Spec direkt – dieselbe Spec treibt Routen und Testsuite an. Praktische Möglichkeiten:

Routen mit gültigen/ungültigen API-Keys aufrufen, Auth-Policies testen.
Fehlerhafte Payloads senden, um Schema-Validierung zu prüfen.
Rate-Limiting gezielt triggern.
Umgebungsvariablen (Preview/Prod/Keys) speichern und Umgebungen per Klick wechseln.
Codebeispiele (curl, JS, Python, Go) direkt für Runbooks generieren.

Automatisierte Test-Szenarien beschleunigen Regressionstests. Nutze die VS Code-Erweiterung für Apidog oder folge dem Guide API-Tests ohne Postman für die Migration. Apidog Download für den Start.

Häufige Fragen zu Zuplo

Ist Zuplo Open Source?

Das Gateway selbst ist proprietär, aber das Entwicklerportal und einige Tools sind Open Source verfügbar. Selbst gehostetes Portal plus Kubernetes-Deploment sind möglich, aber die meisten Teams nutzen den managed Service.

Kann Zuplo auf eigener Infrastruktur laufen?

Ja, via Enterprise-Plan als selbst gehostete Kubernetes-Variante. Dafür entfallen Edge-Deployment und globale Latenzvorteile, aber volle Kontrolle über Datenresidenz.

Wie vergleicht sich Zuplo mit Cloudflare API Shield?

API Shield fokussiert sich auf Sicherheit (Schema, Missbrauch, mTLS), Zuplo ist vollwertiges API-Management (Routing, Policies, Portal, Monetarisierung, MCP). Beide lassen sich kombinieren.

Funktioniert Zuplo mit bestehender OpenAPI-Spec?

Ja, OpenAPI ist das zentrale Artefakt: Importieren, Routen und Portal werden daraus generiert, Policies nutzen die Schemata.

Kann ich mein Zuplo Gateway KI-Agenten wie Claude oder Codex zugänglich machen?

Ja, per MCP Server Handler: OpenAPI-Spec angeben, freizugebende Operationen wählen, schon ist die API für MCP-Clients nutzbar – mit allen Policies.

Wie lange dauert eine Zuplo Bereitstellung?

Push-to-Deploy dauert meist <60 Sekunden für Preview, noch schneller für Produktion (keine Wartungsfenster, atomare Deployments).

Was passiert bei Cloudflare-Ausfall?

Zuplo läuft auf Cloudflare Edge, daher sind regionale Outages möglich. Im Enterprise-Plan gibt es Multi-Cloud-Failover-Optionen (99,999 % SLA).

Fazit

Zuplo ist das API-Gateway für Teams, die Enterprise-Funktionen ohne Ops-Overhead wollen: TypeScript-native Policies, GitOps-Deployment, automatisches Entwicklerportal, integrierte Monetarisierung und MCP-Support für KI-Agenten – alles als Plattform. Der kostenlose Plan ist für Produktivsysteme ausreichend, Enterprise deckt Spezialfälle ab.

Teste es aus: Richte in 30 Minuten eine reale API ein, prüfe jede Policy mit Apidog und entscheide auf Basis echter Ergebnisse. Die Kombination aus managed Edge-Gateway und leistungsstarkem Test-Client beschleunigt den Weg vom „wir haben eine API“ zum „wir haben ein Produkt“. Apidog herunterladen und loslegen.

DEV Community