Qu'est-ce que la passerelle API Zuplo?

La plupart des passerelles API donnent encore l'impression d'avoir été conçues pour une équipe d'opérations de 2014. Vous écrivez du YAML, vous vous battez avec un plan de contrôle, et vous attendez que quelqu'un ayant accès au cluster pousse vos modifications. Zuplo bouleverse ce modèle. C'est une passerelle API programmable, native de l'edge, où vos routes vivent dans un dépôt Git, vos politiques sont en TypeScript, et chaque commit se déploie sur plus de 300 emplacements mondiaux en quelques secondes.

Ce guide explique ce que fait la passerelle API Zuplo, en quoi elle diffère de Kong et AWS API Gateway, ce qu'elle coûte, et comment déployer votre première passerelle en moins de trente minutes. Vous verrez des exemples de code pour le routage, l'authentification et la limitation de débit, ainsi qu'une section sur le test de chaque point d'accès avec Apidog avant sa mise en production.

bouton

Zuplo se situe dans une catégorie qui était autrefois dominée par Kong, Apigee et AWS API Gateway. Le principe est simple : les développeurs obtiennent un véritable langage de programmation, les opérations obtiennent un service géré, et le produit obtient une couche de monétisation intégrée. Cet article décortique les compromis et le flux de travail réel.

En bref

Zuplo est une passerelle API entièrement gérée, native de l'edge, qui exécute vos routes sur plus de 300 centres de données Cloudflare avec une latence inférieure à 50 ms et sans aucun démarrage à froid.
La configuration est native GitOps ; votre passerelle réside dans un dépôt Git et est déployée via CI/CD, et non via une interface utilisateur.
Les politiques sont écrites en TypeScript avec un support IDE complet, et non en YAML ou Lua.
Le niveau gratuit couvre 100 000 requêtes par mois avec des environnements illimités, des clés API et des portails développeurs.
Les fonctionnalités intégrées incluent l'authentification par clé API, JWT, OAuth2, la limitation de débit, la validation des requêtes, un portail développeur auto-généré et la monétisation alimentée par Stripe.
Zuplo propose désormais un gestionnaire de serveur MCP, de sorte que toute route de passerelle peut être exposée à Claude, Codex, Cursor ou tout autre client MCP.
Testez chaque route Zuplo de bout en bout avec Apidog avant de la mettre en production.

Qu'est-ce que Zuplo ?

Zuplo est une plateforme de gestion d'API construite autour de trois idées : le code plutôt que la configuration, l'edge plutôt que la région, et Git plutôt que l'interface graphique. Il fonctionne comme un service entièrement géré sur le réseau edge de Cloudflare, de sorte qu'un seul déploiement est effectué dans plus de 300 centres de données sans que vous ayez à provisionner quoi que ce soit.

Là où la plupart des passerelles traitent votre configuration comme un artefact YAML stocké dans une base de données de plan de contrôle, Zuplo traite votre passerelle comme un projet TypeScript. Vous obtenez un fichier routes.oas.json décrivant les points d'accès, un dossier de modules TypeScript pour la logique personnalisée et un fichier de configuration pour les politiques que vous connectez. Poussez sur GitHub et la plateforme construit, valide et déploie.

La plateforme prend en charge REST, GraphQL, gRPC, WebSockets et SOAP. Elle est conforme SOC 2 Type II, fonctionne sur les backends AWS, Azure et GCP, et offre une option Kubernetes auto-hébergée pour les équipes ayant des règles strictes de résidence des données. La tarification commence gratuitement et évolue avec le volume de requêtes au lieu des frais par siège. Le détail complet se trouve sur la page de tarification Zuplo.

Pourquoi les développeurs choisissent Zuplo plutôt que Kong, Apigee et AWS API Gateway

Chaque passerelle a sa personnalité. Kong est le poids lourd open-source qui vous offre un contrôle maximal et exige en retour une expertise Lua. Apigee est la plateforme d'entreprise avec des analyses approfondies et une courbe d'apprentissage abrupte. AWS API Gateway est le choix par défaut si votre stack réside déjà dans AWS, mais le portail développeur est absent et le coût du démarrage à froid sur les intégrations Lambda est réel.

Zuplo vise un acheteur différent : la petite équipe qui souhaite des fonctionnalités de niveau entreprise sans avoir les effectifs d'ingénierie de plateforme pour les gérer.

Quelques différences spécifiques :

Code, pas YAML. Une politique de limitation de débit dans Zuplo est de trois lignes de TypeScript. La même politique dans Kong représente environ quinze lignes de YAML câblées dans un plugin. La comparaison Kong vs Zuplo publiée par Zuplo rend cela concret ; si vous passez la majeure partie de votre journée en TypeScript ou JavaScript, la configuration Zuplo vous semblera native.
Portail développeur inclus. Le portail de Kong est réservé aux entreprises. Le portail d'Apigee existe mais demande un réel effort de personnalisation. Zuplo génère un portail directement à partir de votre spécification OpenAPI sur chaque plan, y compris le niveau gratuit.
GitOps par défaut. Chaque modification est une demande de tirage (pull request). Vous obtenez gratuitement des révisions, des journaux d'audit et la possibilité de git revert. Pas de clics d'interface utilisateur à traquer lorsque quelque chose tombe en panne à 3 heures du matin.
Native de l'edge, sans démarrage à froid. Zuplo fonctionne sur Cloudflare Workers, ce qui signifie que chaque requête de passerelle atteint le centre de données le plus proche parmi plus de 300 et démarre en quelques millisecondes. AWS API Gateway plus Lambda ajoute régulièrement 100 à 800 ms de démarrage à froid.

Si votre équipe est déjà investie dans Kong ou Apigee et que la charge opérationnelle est gérable, changer en vaut rarement la peine. Si vous choisissez une nouvelle solution, ou si votre passerelle actuelle vous pose des problèmes, le flux de travail Zuplo est l'amélioration la plus nette de toutes les plateformes actuellement disponibles.

Fonctionnalités clés de la passerelle API Zuplo

Programmabilité TypeScript-first

Le comportement de la passerelle est défini dans des fichiers TypeScript qui se trouvent à côté de vos routes. Les politiques entrantes et sortantes personnalisées sont des fonctions qui reçoivent la requête, font ce que vous voulez, et renvoient la requête ou la réponse modifiée. Vous bénéficiez de l'ensemble de la chaîne d'outils TypeScript : types, autocomplétion, refactoring et tests.

Une politique sortante triviale qui supprime un en-tête interne avant de répondre aux clients :

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

C'est toute la politique. Déposez-la dans modules/strip-internal-header.ts, référencez-la dans votre route, poussez sur Git, et elle est déployée.

Plus de 60 politiques pré-construites

La plupart des équipes n'écriront pas de code personnalisé pour les bases. Zuplo fournit plus de 60 politiques pré-construites couvrant l'authentification par clé API, la validation JWT, OAuth 2.0, la limitation de débit (fenêtre fixe, fenêtre glissante, seau à jetons), la validation des requêtes et réponses par rapport à votre schéma OpenAPI, CORS, les listes d'adresses IP autorisées, la transformation des requêtes et une poignée d'intégrations en amont. Vous les connectez en modifiant la définition de la route ; aucune modification de code n'est requise pour les cas standards.

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

Pointez le portail vers votre spécification OpenAPI et vous obtenez un site de documentation hébergé avec des consoles interactives d'essai, des exemples de code en cURL, JavaScript, Python, Go et autres, ainsi qu'une émission de clés API en libre-service. Les utilisateurs finaux peuvent s'inscrire, générer des clés et commencer à appeler l'API sans aucune intervention humaine. Pour les API SaaS qui dépendent de l'adoption par les développeurs, cela seul justifie souvent la plateforme.

Monétisation API intégrée

Zuplo propose une intégration Stripe pour vendre l'accès à l'API. Vous définissez des plans (gratuit, pro, entreprise), connectez Stripe, et le portail gère le paiement, la gestion des abonnements et la facturation de l'utilisation. C'est rare dans les passerelles API ; Kong et AWS API Gateway laissent tous deux la monétisation à la charge du lecteur. Si vous facturez les appels API, le flux de monétisation Zuplo élimine un développement de plusieurs semaines.

Gestionnaire de serveur MCP pour les agents IA

Le dernier ajout est le gestionnaire de serveur MCP. Pointez-le vers votre spécification OpenAPI, choisissez les opérations à exposer, et votre API existante devient invocable par Claude Code, OpenAI Codex, Cursor et tout autre client compatible MCP. Les mêmes politiques d'authentification et de limitation de débit que vous avez appliquées aux appelants humains s'appliquent aux agents IA. Zuplo a publié un guide détaillé sur l'exposition des API via MCP qui couvre la configuration en détail.

Déploiement en périphérie, latence inférieure à 50 ms

Chaque passerelle se déploie par défaut sur plus de 300 emplacements périphériques de Cloudflare. La plateforme revendique une latence inférieure à 50 ms en périphérie sans démarrage à froid. En pratique, cela signifie qu'un utilisateur à Singapour qui accède à votre API atteint une passerelle résidente à Singapour, qui se connecte ensuite à l'endroit où réside votre origine. Vous ne configurez pas cela ; c'est le seul mode de déploiement.

Comment Zuplo fonctionne en coulisses

Une requête arrive au point d'accès périphérique le plus proche et passe par ce pipeline :

Correspondance de route. L'URL et la méthode de la requête sont comparées à votre fichier routes.oas.json pour trouver le bon gestionnaire.
Politiques entrantes. Tout ce que vous avez configuré (authentification par clé API, validation JWT, limitation de débit, validation de schéma) s'exécute dans l'ordre. Si une politique lève une erreur ou renvoie une réponse, le pipeline est court-circuité et cette réponse est renvoyée au client.
Gestionnaire. Le gestionnaire proxyfie vers votre origine en amont, renvoie une valeur statique, exécute du TypeScript personnalisé ou invoque le gestionnaire de serveur MCP.
Politiques sortantes. Les transformations de réponse, la suppression d'en-têtes et toute logique de sortie personnalisée sont exécutées.
Réponse. La réponse finale est renvoyée au client ; les journaux et les métriques sont envoyés à la couche d'observabilité de Zuplo (ou à votre propre fournisseur via des intégrations).

Le tout fonctionne dans un Cloudflare Worker, ce qui explique pourquoi les chiffres de latence sont maintenus et pourquoi vous ne payez pas pour la capacité inactive.

Configuration de votre première passerelle Zuplo

Vous pouvez construire une passerelle fonctionnelle en une trentaine de minutes. Voici le déroulement du processus :

Inscrivez-vous sur zuplo.com et créez un nouveau projet. Choisissez l'intégration GitHub pour que le projet soit synchronisé avec un dépôt que vous contrôlez.
Importez une spécification OpenAPI. Si votre API en amont en possède déjà une, importez-la. Zuplo transforme chaque opération en une route. Si vous n'avez pas encore de spécification, vous pouvez esquisser des routes dans l'interface utilisateur et exporter la spécification plus tard.
Ajoutez une politique d'authentification par clé API. Dans l'éditeur de routes, ajoutez la politique api-key-inbound. Zuplo crée la base de données des consommateurs et l'interface utilisateur d'émission des clés pour vous.
Ajoutez une limitation de débit. Insérez la politique rate-limit-inbound avec un budget de requêtes tel que 100 requêtes par minute par clé API. Il s'agit d'un bloc JSON dans le fichier de route.
Déployez. Poussez sur votre branche. Zuplo construit un environnement de prévisualisation avec une URL unique. Passez en production avec une fusion (merge).
Testez la passerelle de bout en bout. Utilisez Apidog pour envoyer des requêtes à la nouvelle URL de la passerelle avec des clés API valides et invalides, des limites de débit dépassées et des charges utiles incorrectes. L'inspecteur de réponse visuel facilite la confirmation que la bonne politique a été déclenchée dans le bon ordre.

Le premier projet se déploie en quelques minutes. Le travail le plus difficile consiste à bien nommer les routes et à décider où placer la logique personnalisée, ce qui est le même problème que vous auriez sur n'importe quelle plateforme.

Écrire des politiques personnalisées en TypeScript

Les politiques pré-construites couvrent les cas courants. Pour tout le reste, écrivez une politique personnalisée. Un exemple typique est l'enrichissement de la requête avec des données provenant d'un service interne avant qu'elle n'atteigne votre origine :

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

Trois choses à noter ici. Premièrement, la politique est une fonction asynchrone normale ; la tester est un test unitaire, pas un test d'intégration lourd en fixtures. Deuxièmement, les variables d'environnement proviennent de context.environment, qui est typé et extrait des paramètres de votre projet. Troisièmement, le retour d'une Response court-circuite le pipeline, c'est ainsi que vous exprimez proprement les échecs d'authentification ou les erreurs en amont.

Tarification Zuplo en 2026

La tarification de Zuplo est exceptionnellement simple pour cette catégorie. Trois plans :

Gratuit, 0 $ par mois. 100 000 requêtes par mois, environnements illimités, clés API illimitées, portails développeurs illimités, 1 Go d'égresse, déploiement sur les plus de 300 emplacements périphériques, jusqu'à deux développeurs de passerelle. Trafic de production réel ; pas un niveau de jeu.
Builder, 25 $ par mois. Même base plus jusqu'à 1 million de requêtes par mois, deux domaines personnalisés, 1 Go d'égresse pour 100 000 requêtes, requêtes supplémentaires à 100 $ pour 100 000, support communautaire.
Entreprise, tarification personnalisée à partir de 1 000 $ par mois sur un contrat annuel. Requêtes et domaines illimités, options de SLA de 99,5 % à 99,999 %, intégration GitHub Enterprise/GitLab/Azure DevOps, support 24/7 optionnel, SSO, RBAC, modules d'observabilité.

Les produits AI Gateway et Developer Portal ont des niveaux distincts, y compris un portail auto-hébergé open-source à 0 $/mois. Les chiffres actuels sont disponibles sur la page de tarification Zuplo et méritent d'être vérifiés avant de signer un contrat.

À titre de comparaison : AWS API Gateway facture 3,50 $ par million de requêtes REST, puis le transfert de données, puis les coûts Lambda si vous utilisez des intégrations Lambda. Le niveau entreprise de Kong est personnalisé et se situe historiquement bien au-dessus du seuil de 1 000 $ de Zuplo. Le niveau gratuit à lui seul rend Zuplo difficile à battre pour les projets en phase de démarrage.

Quand Zuplo est le bon choix (et quand il ne l'est pas)

Zuplo est un excellent choix lorsque :

Vous voulez une passerelle gérée et ne voulez pas exécuter Kong sur Kubernetes.
Votre équipe maîtrise TypeScript ou JavaScript.
Vous avez besoin d'un portail développeur sans fournisseur distinct.
Vous prévoyez de monétiser l'API et souhaitez une facturation Stripe intégrée.
Vous exposez votre API à des agents IA et souhaitez un support MCP sans construire le serveur vous-même.
Votre trafic est mondial et la latence en périphérie est importante.

Zuplo n'est pas le bon choix lorsque :

Vous avez besoin d'un contrôle open-source complet du code de la passerelle (Kong est la solution).
Votre stack est entièrement sur site sans sortie Internet (un Kong ou Tyk auto-hébergé convient mieux).
Vous avez des exigences très spécifiques qui nécessitent un accès aux composants internes de NGINX.
Vous êtes déjà fortement investi dans Apigee ou MuleSoft et le coût de la migration l'emporte sur le gain.

Tester votre passerelle Zuplo avec Apidog

Une fois votre passerelle en ligne dans un environnement de prévisualisation, vous devez tester chaque route, chaque politique et chaque cas limite avant de la promouvoir en production. C'est là qu'un client API dédié prend toute son importance.

Apidog importe directement votre spécification OpenAPI, de sorte que la même spécification qui alimente vos routes Zuplo alimente également votre suite de tests. À partir de là, vous pouvez :

Appeler chaque route avec des clés API valides et invalides pour confirmer que les politiques d'authentification fonctionnent correctement.
Envoyer des charges utiles malformées pour vérifier que la validation des requêtes les rejette avec le statut attendu.
Bombarder des points d'accès pour valider que les politiques de limitation de débit se déclenchent au bon seuil.
Enregistrer des variables d'environnement pour votre URL de prévisualisation Zuplo, votre URL de production et vos clés API afin de pouvoir basculer entre les environnements en un seul clic.
Générer des exemples de code en cURL, JavaScript, Python et Go à coller dans les guides d'exploitation de votre équipe.

Vous pouvez également exécuter les scénarios de test automatisés d'Apidog contre la passerelle, ce qui est plus rapide que d'écrire des scripts ponctuels. Si vous n'avez jamais utilisé Apidog auparavant, l'extension Apidog pour VS Code vous permet d'envoyer des requêtes sans quitter votre éditeur, et le guide de test API sans Postman vous accompagne dans la migration si vous venez d'un autre client. Téléchargez Apidog pour commencer.

Questions fréquentes sur la passerelle API Zuplo

Zuplo est-il open source ?

Le runtime de la passerelle principale est propriétaire, mais Zuplo a rendu open source le portail développeur et plusieurs bibliothèques de support sur GitHub. Si vous avez besoin d'une option auto-hébergée, le portail open source ainsi qu'un déploiement Kubernetes auto-hébergé de la passerelle couvrent la plupart des besoins. La plupart des équipes restent sur le service géré.

Zuplo peut-il fonctionner sur ma propre infrastructure ?

Oui. Le plan Enterprise inclut une option Kubernetes auto-hébergée. Le compromis est que vous renoncez au déploiement global en périphérie et que vous prenez en charge les opérations du cluster vous-même. Pour les équipes ayant des règles strictes de résidence des données, c'est le bon choix.

Comment Zuplo se compare-t-il à Cloudflare API Shield ?

API Shield est un produit axé sur la sécurité (validation de schéma, détection d'abus, mTLS) qui se place devant toute origine. Zuplo est une plateforme complète de gestion d'API : routage, politiques, portail développeur, monétisation, support MCP. Les deux peuvent coexister. Si vous n'avez besoin que de signaux de sécurité, API Shield est suffisant. Si vous avez besoin du cycle de vie complet, Zuplo est la plateforme.

Zuplo fonctionne-t-il avec ma spécification OpenAPI existante ?

Oui. OpenAPI est la source de vérité dans Zuplo. Importez la spécification, les routes apparaissent, le portail développeur est généré à partir de la même spécification, et les politiques de validation des requêtes utilisent les mêmes schémas. Si votre spécification est désordonnée, le processus d'importation est le moment où vous le découvrez.

Puis-je exposer ma passerelle Zuplo à des agents IA comme Claude ou Codex ?

Oui, via le gestionnaire de serveur MCP. Vous pointez le gestionnaire vers votre spécification OpenAPI, choisissez les opérations à exposer, et la passerelle devient invocable par tout client compatible MCP. Les mêmes politiques d'authentification et de limitation de débit que vous avez définies pour les appelants humains s'appliquent automatiquement.

Combien de temps prend un déploiement Zuplo ?

Un cycle de push-to-deploy prend généralement moins de soixante secondes pour un environnement de prévisualisation. Les promotions en production sont plus rapides car l'artefact est déjà construit. Il n'y a pas de fenêtres de maintenance ; les déploiements sont atomiques.

Que se passe-t-il si Cloudflare tombe en panne ?

Zuplo fonctionne sur le réseau edge de Cloudflare, donc une panne régionale de Cloudflare affectera cette région. Le plan Enterprise offre des options de basculement multi-cloud pour les équipes qui ont besoin d'une disponibilité de 99,999 %. La plupart des équipes acceptent la dépendance compte tenu du bilan de fiabilité de Cloudflare.

Conclusion

Zuplo est la passerelle API pour les équipes qui souhaitent des fonctionnalités d'entreprise sans la charge opérationnelle. Les politiques natives TypeScript, les déploiements GitOps, un portail développeur auto-généré, la monétisation intégrée, et maintenant le support MCP pour les agents IA en font une plateforme complète plutôt qu'une simple couche de routage. Le niveau gratuit est suffisamment généreux pour un trafic de production réel, et le plan Enterprise gère le reste.

Si vous êtes en phase d'évaluation, effectuez la configuration de trente minutes avec l'une de vos API réelles, testez-la avec Apidog pour valider chaque politique, et décidez sur la base de preuves plutôt que de pages marketing. La combinaison d'une passerelle edge gérée et d'un client de test robuste est le chemin le plus rapide pour passer de « nous avons une API » à « nous avons un produit ». Téléchargez Apidog et commencez à tester.

bouton