Antoine Laurent

Posted on Apr 27 • Originally published at apidog.com

Qu'est-ce que la passerelle API Zuplo?

La plupart des passerelles API semblent encore conçues pour une équipe d’opérations de 2014 : configuration en YAML, gestion fastidieuse d’un plan de contrôle, et nécessité d’attendre qu’un administrateur pousse les changements sur le cluster. Zuplo casse ce paradigme. Cette passerelle API programmable et native edge gère vos routes dans un dépôt Git, vos politiques en TypeScript, et déploie chaque commit sur plus de 300 points de présence mondiaux en quelques secondes.

Essayez Apidog dès aujourd’hui

Ce guide vous montre comment utiliser Zuplo : ce que fait la passerelle, ses différences avec Kong et AWS API Gateway, son coût, et les étapes pour déployer votre première passerelle en moins de 30 minutes. Vous trouverez des exemples de code pour le routage, l’authentification, la limitation de débit, et une méthode de test de chaque endpoint avec Apidog avant la mise en production.

Zuplo s’inscrit dans la même catégorie que Kong, Apigee, et AWS API Gateway, mais avec une approche différente : les développeurs utilisent du vrai code, les opérations bénéficient d’un service managé, et la monétisation est intégrée. Voici un focus sur les points clés et le workflow technique.

En bref

Passerelle API managée native edge : routes exécutées sur plus de 300 data centers Cloudflare avec une latence < 50 ms, pas de cold start.
GitOps natif : tout est versionné dans Git et déployé via CI/CD.
Politiques en TypeScript : IDE complet, pas de YAML/Lua.
Gratuit pour 100 000 requêtes/mois : environnements, clés API et portails développeur illimités.
Fonctionnalités intégrées : Auth API Key, JWT, OAuth2, rate-limiting, validation, portail dev auto-généré, monétisation Stripe.
Support MCP Server : exposez une route à Claude, Codex, Cursor, etc.
Testez chaque route avec Apidog avant la prod.

Qu’est-ce que Zuplo ?

Zuplo est une plateforme de gestion d’API basée sur trois principes : code (TypeScript) plutôt que configuration, edge plutôt que région, Git plutôt qu’interface graphique. Le service est managé et déployé sur le réseau edge Cloudflare (300+ datacenters, rien à provisionner).

Contrairement aux passerelles qui stockent leur config en YAML dans une base centrale, Zuplo traite votre passerelle comme un projet TypeScript. Structure type :

routes.oas.json : définition des endpoints
dossier modules/ : logique custom TypeScript
fichier de config pour les politiques

Un push sur GitHub déclenche la build, la validation et le déploiement.

Support natif de REST, GraphQL, gRPC, WebSockets, SOAP. Certifié SOC 2 Type II. Backends AWS, Azure, GCP, option Kubernetes auto-hébergée. Tarification basée sur les requêtes (pas de coût par siège).

Pourquoi choisir Zuplo plutôt que Kong, Apigee ou AWS API Gateway ?

Chaque passerelle a son ADN :

Kong : open source, contrôle total, nécessite Lua.
Apigee : entreprise, analytics avancé, learning curve raide.
AWS API Gateway : bon choix pour AWS, mais pas de portail dev et cold start sur Lambda.

Zuplo vise les petites équipes qui veulent des fonctions “enterprise” sans équipe plateforme dédiée.

Différences notables :

Code, pas YAML : ex, une policy de rate-limit en Zuplo = 3 lignes TypeScript, en Kong = 15 lignes YAML.
Portail développeur inclus : généré automatiquement à partir de l’OpenAPI, même sur le plan gratuit.
GitOps par défaut : tout changement = pull request. Audit, rollback, pas de clics UI à retrouver de nuit.
Native edge, pas de cold start : Cloudflare Workers, latence minimale, vs 100-800 ms de cold start pour AWS API Gateway + Lambda.

Si vous débutez, ou que votre passerelle actuelle pose problème, Zuplo propose un workflow plus moderne et productif.

Fonctionnalités principales de Zuplo

Programmabilité TypeScript-first

Vous codez vos politiques dans des fichiers TypeScript, versionnés avec vos routes. Ex :

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;
}

Placez ce fichier dans modules/strip-internal-header.ts, référencez-le dans une route, push Git, déploiement immédiat.

60+ politiques pré-construites

La plupart des besoins standards (auth, JWT, OAuth2, rate-limit, validation OpenAPI, CORS, whitelisting IP, transformations, intégrations amont) sont couverts par des policies prêtes à l’emploi. Il suffit de les déclarer dans la config de route (JSON), pas besoin de coder.

Portail développeur auto-généré

Pointez vers votre OpenAPI, et obtenez automatiquement :

Documentation hébergée
Consoles interactives (try it)
Exemples cURL, JS, Python, Go…
Génération de clés API en self-service

Idéal pour les APIs SaaS orientées développeur.

Monétisation API intégrée

Connectez Stripe, définissez les plans (free/pro/entreprise), et le portail gère paiement, souscription, facturation. Unique parmi les passerelles API.

Gestionnaire de serveur MCP (agents IA)

Exposez vos endpoints à Claude, Codex, Cursor, etc. Pointage sur votre OpenAPI, sélection des opérations exposées, policies appliquées aussi aux agents IA. Guide complet.

Déploiement edge, latence <50 ms

Déploiement automatique sur le réseau Cloudflare (300+ localisations). L’utilisateur accède toujours au PoP le plus proche. Aucun paramétrage à faire.

Comment fonctionne Zuplo sous le capot ?

Pipeline d’une requête :

Matching de route : URL/méthode vs routes.oas.json
Politiques entrantes : auth, rate-limit, validation, etc.
Handler : proxy, réponse statique, exécution TypeScript, ou gestionnaire MCP
Politiques sortantes : transformations de réponse, suppression d’en-têtes, etc.
Réponse : retour client, logs & métriques envoyés

Tout s’exécute dans un Cloudflare Worker, d’où la faible latence et l’absence de capacité inactive à payer.

Déployer rapidement votre première passerelle Zuplo

En 30 minutes, passez de zéro à une passerelle API en prod :

Inscrivez-vous sur zuplo.com et créez un projet. Intégrez GitHub pour la synchro auto.
Importez votre OpenAPI. Si vous n’en avez pas, créez les routes à la main.
Ajoutez la policy d’auth API Key dans l’éditeur de routes (api-key-inbound). Zuplo génère la base de consommateurs & UI clés.
Ajoutez la limitation de débit (rate-limit-inbound). Ex : 100 requêtes/minute/clé API (bloc JSON dans la config de route).
Déployez : push Git → build & preview URL. Merge pour passer en prod.
Testez de bout en bout : utilisez Apidog pour simuler des requêtes OK/KO, dépassements de quotas, payloads invalides, et vérifier le déclenchement de chaque policy.

Premier déploiement en quelques minutes. L’essentiel du travail : nommage des routes et placement logique des policies, comme sur toute plateforme.

Écrire des policies custom TypeScript

Pour aller au-delà des policies standard, écrivez simplement une fonction TypeScript. Exemple : enrichir les requêtes avec des infos utilisateur internes.

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;
}

À retenir :

Une policy = fonction async standard, testable en unitaire
Variables d’environnement via context.environment
Retourner une Response stoppe le pipeline (pour les erreurs/unauthorized)

Tarification Zuplo en 2026

Trois plans simples :

Gratuit : 100 000 requêtes/mois, envs/clés/portails illimités, 1 Go d’egress, 2 devs. Vrai trafic, pas un sandbox.
Builder ($25/mois) : jusqu’à 1M req/mois, 2 domaines custom, egress supplémentaire, support communautaire.
Entreprise (dès $1,000/mois) : requêtes/domaines illimités, SLA jusqu’à 99.999%, SSO, RBAC, support 24/7 optionnel, Github Enterprise, etc.

Portail dev open source dispo gratuitement. Consultez les prix à jour.

Comparatif : AWS API Gateway facture $3.50/M req REST + egress + Lambda ; Kong Entreprise coûte souvent bien plus que $1,000. Le niveau gratuit Zuplo est imbattable pour démarrer.

Quand adopter Zuplo (ou pas)

Zuplo est idéal si :

Vous voulez une passerelle managée (pas d’admin Kubernetes)
Votre équipe maîtrise TypeScript/JavaScript
Besoin d’un portail dev sans outil tiers
Monétisation API via Stripe requise
Exposition d’API à des agents IA (support MCP intégré)
Trafic mondial/latence edge importante

À éviter si :

Besoin absolu d’open source complet (privilégiez Kong)
Stack totalement on-prem sans sortie Internet
Exigences internes NGINX très spécifiques
Forte dépendance existante à Apigee/MuleSoft (coût migration > gain)

Tester votre passerelle Zuplo avec Apidog

Après déploiement sur un environnement de prévisualisation, testez chaque route, policy et cas limite avant la prod. C’est là qu’Apidog est essentiel.

Workflow recommandé :

Importez votre OpenAPI dans Apidog (même spec que Zuplo)
Appelez chaque endpoint avec API keys valides/invalides pour vérifier l’auth
Envoyez des payloads invalides pour valider la rejection
Testez les limites de rate-limit en overloadant un endpoint
Stockez vos variables d’URL (preview/prod) et clés pour switcher d’env
Générez du code cURL/JS/Python/Go pour vos docs internes

Vous pouvez aussi automatiser vos tests avec Apidog, plus rapide que des scripts maison. Si vous débutez, l’extension VS Code et le guide de migration Postman → Apidog vous guideront. Téléchargez Apidog pour démarrer.

FAQ Zuplo

Zuplo est-il open source ?

Le runtime principal est propriétaire, mais le portail développeur et plusieurs libs sont open source sur GitHub. Le plan Enterprise inclut une option Kubernetes auto-hébergée. La plupart des équipes optent pour le service managé.

Zuplo peut-il tourner sur mon infra ?

Oui, via le plan Enterprise (Kubernetes auto-hébergé), mais sans le déploiement edge global. À privilégier en cas d’exigences fortes de résidence de données.

Zuplo vs Cloudflare API Shield ?

API Shield = sécurité (schema validation, mTLS, etc.), Zuplo = plateforme API complète (routage, policies, portail, monétisation, MCP). Les deux peuvent coexister.

Zuplo fonctionne-t-il avec mon OpenAPI ?

Oui, OpenAPI = source de vérité dans Zuplo. Importez, les routes et la doc sont générées, la validation de requête se base dessus.

Puis-je exposer Zuplo à Claude/Codex/IA ?

Oui, via le gestionnaire MCP. Les policies d’auth/rate-limit s’appliquent aussi aux agents IA.

Déploiement Zuplo : combien de temps ?

Push → preview en <60 secondes. Passage en prod quasi-instantané (artefact déjà buildé).

Que se passe-t-il si Cloudflare tombe ?

Zuplo dépend du réseau edge Cloudflare (pannes régionales = impact local). Le plan Enterprise propose des options multi-cloud pour 99.999% de dispo.

Conclusion

Zuplo offre une passerelle API moderne : policies TypeScript natives, GitOps, portail dev instantané, monétisation Stripe, support agents IA/MCP. Le plan gratuit couvre la production réelle, le plan Enterprise comble les besoins avancés.

Pour tester, faites la config 30 min sur une de vos APIs, validez chaque policy avec Apidog, et décidez sur preuves techniques réelles. Coupler une passerelle edge managée à un client de tests robuste, c’est passer plus vite de « on a une API » à « on a un produit ». Téléchargez Apidog et commencez vos tests.

DEV Community