¿Qué es el API Gateway de Zuplo?

La mayoría de los gateways API todavía parecen haber sido diseñados para un equipo de operaciones de 2014. Escribes YAML, luchas con un plano de control y esperas a que alguien con acceso al clúster impulse tus cambios. Zuplo cambia ese modelo. Es un gateway API programable y nativo de la periferia (edge-native) donde tus rutas residen en un repositorio Git, tus políticas son TypeScript y cada commit se despliega en más de 300 ubicaciones globales en segundos.

Esta guía explica qué hace el gateway API de Zuplo, cómo se diferencia de Kong y AWS API Gateway, cuánto cuesta y cómo implementar tu primer gateway en menos de treinta minutos. Verás ejemplos de código para enrutamiento, autenticación y limitación de tasas, además de una sección sobre cómo probar cada endpoint con Apidog antes de que llegue a producción.

Zuplo se encuentra en una categoría que solía estar dominada por Kong, Apigee y AWS API Gateway. La propuesta es simple: los desarrolladores obtienen un lenguaje de programación real, las operaciones obtienen un servicio gestionado y el producto obtiene una capa de monetización incorporada. Los compromisos y el flujo de trabajo real son lo que este post desglosa.

En resumen

• Zuplo es un gateway API totalmente gestionado y nativo de la periferia (edge-native) que ejecuta tus rutas en más de 300 centros de datos de Cloudflare con una latencia inferior a 50 ms y cero arranques en frío.
• La configuración es GitOps-nativa; tu gateway reside en un repositorio Git y se despliega a través de CI/CD, no de una interfaz de usuario.
• Las políticas están escritas en TypeScript con soporte completo de IDE, no en YAML o Lua.
• El nivel gratuito cubre 100K solicitudes al mes con entornos ilimitados, claves API y portales para desarrolladores.
• Las características integradas incluyen autenticación por clave API, JWT, OAuth2, limitación de tasas, validación de solicitudes, un portal para desarrolladores autogenerado y monetización impulsada por Stripe.
• Zuplo ahora incluye un manejador de servidor MCP, por lo que cualquier ruta de gateway puede ser expuesta a Claude, Codex, Cursor o cualquier cliente MCP.
• Prueba cada ruta de Zuplo de extremo a extremo con Apidog antes de activar el interruptor en producción.

¿Qué es Zuplo?

Zuplo es una plataforma de gestión de API construida en torno a tres ideas: código sobre configuración, periferia sobre región y Git sobre GUI. Se ejecuta como un servicio totalmente gestionado en la red edge de Cloudflare, por lo que un único despliegue llega a más de 300 centros de datos sin que tú tengas que provisionar nada.

Mientras que la mayoría de los gateways tratan tu configuración como un artefacto YAML almacenado en una base de datos del plano de control, Zuplo trata tu gateway como un proyecto TypeScript. Obtienes un archivo routes.oas.json que describe los endpoints, una carpeta de módulos TypeScript para lógica personalizada y un archivo de configuración para las políticas que conectas. Haz un push a GitHub y la plataforma compila, valida y despliega.

La plataforma soporta REST, GraphQL, gRPC, WebSockets y SOAP. Cumple con SOC 2 Tipo II, funciona con backends de AWS, Azure y GCP, y ofrece una opción de Kubernetes autoalojado para equipos con estrictas reglas de residencia de datos. Los precios comienzan siendo gratuitos y escalan con el volumen de solicitudes en lugar de tarifas por asiento. El desglose completo se encuentra en la página de precios de Zuplo.

Por qué los desarrolladores eligen Zuplo en lugar de Kong, Apigee y AWS API Gateway

Cada gateway tiene una personalidad. Kong es el peso pesado de código abierto que te da el máximo control y a cambio requiere experiencia en Lua. Apigee es la plataforma empresarial con análisis profundos y una curva de aprendizaje empinada. AWS API Gateway es la opción por defecto si tu stack ya reside en AWS, pero el portal para desarrolladores falta y el "impuesto" de arranque en frío en las integraciones de Lambda es real.

Zuplo se dirige a un tipo de comprador diferente: el equipo pequeño que desea características de nivel empresarial sin la necesidad de personal de ingeniería de plataforma para ejecutarlas.

Algunas diferencias específicas:

• Código, no YAML. Una política de limitación de tasas en Zuplo son tres líneas de TypeScript. La misma política en Kong son aproximadamente quince líneas de YAML conectadas a un plugin. La comparación que Zuplo publica entre Kong y Zuplo lo hace concreto; si pasas la mayor parte de tu día en TypeScript o JavaScript, la configuración de Zuplo te resultará familiar.
• Portal para desarrolladores incluido. El portal de Kong es solo para empresas. El portal de Apigee existe pero requiere un esfuerzo real para personalizarlo. Zuplo genera un portal directamente desde tu especificación OpenAPI en cada plan, incluido el nivel gratuito.
• GitOps por defecto. Cada cambio es una solicitud de extracción (pull request). Obtienes revisiones, registros de auditoría y git revert de forma gratuita. No hay clics en la interfaz de usuario que perseguir cuando algo falla a las 3 AM.
• Nativo de la periferia (Edge-native), sin arranques en frío. Zuplo se ejecuta en Cloudflare Workers, lo que significa que cada solicitud de gateway llega al centro de datos más cercano de los más de 300 y comienza en milisegundos de un solo dígito. AWS API Gateway más Lambda añade rutinariamente entre 100 y 800 ms de arranque en frío.

Si tu equipo ya ha invertido en Kong o Apigee y la carga operativa está bien, el cambio rara vez vale la pena. Si estás eligiendo desde cero, o tu gateway actual te está dando problemas, el flujo de trabajo de Zuplo es la mejora más clara de cualquier plataforma disponible actualmente.

Características principales del gateway API de Zuplo

Programabilidad con prioridad en TypeScript

El comportamiento del gateway se define en archivos TypeScript que residen junto a tus rutas. Las políticas de entrada y salida personalizadas son funciones que reciben la solicitud, hacen lo que quieras y devuelven la solicitud o respuesta modificada. Obtienes toda la cadena de herramientas de TypeScript: tipos, autocompletado, refactorización y pruebas.

Una política de salida trivial que elimina una cabecera interna antes de responder a los clientes:

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

Esa es toda la política. Colócala en modules/strip-internal-header.ts, referénciala en tu ruta, haz un push a Git y se desplegará.

Más de 60 políticas predefinidas

La mayoría de los equipos no escribirán código personalizado para lo básico. Zuplo ofrece más de 60 políticas predefinidas que cubren autenticación por clave API, validación JWT, OAuth 2.0, limitación de tasas (ventana fija, ventana deslizante, cubo de tokens), validación de solicitudes y respuestas contra tu esquema OpenAPI, CORS, listas blancas de IP, transformación de solicitudes y un puñado de integraciones upstream. Las conectas editando la definición de la ruta; no se requieren cambios de código para los casos estándar.

Portal para desarrolladores autogenerado

Apuntando el portal a tu especificación OpenAPI, obtienes un sitio de documentación alojado con consolas interactivas "pruébalo tú mismo", ejemplos de código en cURL, JavaScript, Python, Go y otros, además de la emisión de claves API de autoservicio. Los usuarios finales pueden registrarse, generar claves y empezar a llamar a la API sin la intervención de un solo ser humano. Para las API SaaS que dependen de la adopción por parte de los desarrolladores, esto por sí solo a menudo justifica la plataforma.

Monetización de API integrada

Zuplo incluye una integración con Stripe para vender acceso a la API. Defines planes (gratuito, pro, empresarial), conectas Stripe y el portal se encarga del proceso de pago, la gestión de suscripciones y la facturación por uso. Esto es raro en los gateways API; Kong y AWS API Gateway dejan la monetización como un ejercicio para el lector. Si estás cobrando por las llamadas a la API, el flujo de monetización de Zuplo elimina una construcción de varias semanas.

Manejador de servidor MCP para agentes de IA

La adición más reciente es el Manejador de Servidor MCP. Apúntalo a tu especificación OpenAPI, elige qué operaciones exponer y tu API existente se volverá invocable por Claude Code, OpenAI Codex, Cursor y cualquier otro cliente compatible con MCP. Las mismas políticas de autenticación y limitación de tasas que aplicaste a los llamantes humanos se aplican a los agentes de IA. Zuplo publicó un tutorial sobre cómo exponer APIs a través de MCP que cubre la configuración en detalle.

Despliegue en la periferia (Edge), latencia inferior a 50 ms

Cada gateway se despliega en más de 300 ubicaciones de borde de Cloudflare por defecto. La plataforma afirma una latencia inferior a 50 ms en el borde sin arranques en frío. En la práctica, esto significa que un usuario en Singapur que accede a tu API llega a un gateway residente en Singapur, que luego proxy a donde reside tu origen. Esto no se configura; es el único modo de despliegue.

Cómo funciona Zuplo por dentro

Una solicitud llega a la ubicación de borde más cercana y pasa por esta pipeline:

1. Coincidencia de ruta. La URL y el método de la solicitud se comparan con tu routes.oas.json para encontrar el manejador correcto.
2. Políticas de entrada. Todo lo que hayas configurado (autenticación por clave API, validación JWT, limitación de tasas, validación de esquema) se ejecuta en orden. Si una política lanza una excepción o devuelve una respuesta, la pipeline se interrumpe y esa respuesta se devuelve al cliente.
3. Manejador. El manejador actúa como proxy para tu origen upstream, devuelve un valor estático, ejecuta TypeScript personalizado o invoca el Manejador de Servidor MCP.
4. Políticas de salida. Se ejecutan las transformaciones de respuesta, la eliminación de cabeceras y cualquier lógica de salida personalizada.
5. Respuesta. La respuesta final se envía de vuelta al cliente; los registros y las métricas se envían a la capa de observabilidad de Zuplo (o a tu propio proveedor a través de integraciones).

Todo el proceso se ejecuta en un Cloudflare Worker, razón por la cual los números de latencia se mantienen y no pagas por la capacidad inactiva.

Configurando tu primer gateway Zuplo

Puedes construir un gateway funcional en aproximadamente treinta minutos. Aquí te mostramos el esquema del flujo de trabajo:

1. Regístrate en zuplo.com y crea un nuevo proyecto. Elige la integración con GitHub para que el proyecto se sincronice con un repositorio que tú controlas.
2. Importa una especificación OpenAPI. Si tu API upstream ya tiene una, impórtala. Zuplo convierte cada operación en una ruta. Si aún no tienes una especificación, puedes esbozar rutas en la interfaz de usuario y exportar la especificación más tarde.
3. Agrega una política de autenticación por clave API. En el editor de rutas, añade la política api-key-inbound. Zuplo crea la base de datos de consumidores y la interfaz de emisión de claves por ti.
4. Agrega una limitación de tasas. Inserta la política rate-limit-inbound con un presupuesto de solicitudes como 100 solicitudes por minuto por clave API. Este es un bloque JSON en el archivo de ruta.
5. Despliega. Haz un push a tu rama. Zuplo construye un entorno de vista previa con una URL única. Promueve a producción con una fusión (merge).
6. Prueba el gateway de extremo a extremo. Usa Apidog para enviar solicitudes a la nueva URL del gateway con claves API válidas e inválidas, límites de tasas excedidos y cargas útiles incorrectas. El inspector visual de respuestas facilita la confirmación de que la política correcta se ejecutó en el orden adecuado.

El primer proyecto se despliega en minutos. El trabajo más difícil es nombrar bien las rutas y decidir dónde colocar la lógica personalizada, lo cual es el mismo problema que tendrías en cualquier plataforma.

Escribiendo políticas personalizadas en TypeScript

Las políticas predefinidas cubren los casos comunes. Para todo lo demás, escribe una política personalizada. Un ejemplo típico es enriquecer la solicitud con datos de un servicio interno antes de que llegue a tu origen:

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

Tres cosas a tener en cuenta aquí. Primero, la política es una función asíncrona normal; probarla es una prueba unitaria, no una prueba de integración con muchas dependencias. Segundo, las variables de entorno provienen de context.environment, que es de tipo seguro y se obtiene de la configuración de tu proyecto. Tercero, devolver una Response interrumpe la pipeline, que es la forma de expresar fallos de autenticación o errores upstream de forma limpia.

Precios de Zuplo en 2026

Los precios de Zuplo son inusualmente sencillos para esta categoría. Tres planes:

• Gratuito, $0 al mes. 100K solicitudes al mes, entornos ilimitados, claves API ilimitadas, portales para desarrolladores ilimitados, 1 GB de salida, despliegue en las más de 300 ubicaciones edge, hasta dos desarrolladores de gateway. Tráfico de producción real; no es un nivel de juguete.
• Builder, $25 al mes. La misma base más hasta 1 millón de solicitudes al mes, dos dominios personalizados, 1 GB de salida por cada 100K solicitudes, solicitudes adicionales a $100 por cada 100K, soporte comunitario.
• Empresarial, precios personalizados a partir de $1,000 al mes con un contrato anual. Solicitudes y dominios ilimitados, opciones de SLA del 99.5% al 99.999%, integración con GitHub Enterprise/GitLab/Azure DevOps, soporte opcional 24/7, SSO, RBAC, complementos de observabilidad.

Los productos AI Gateway y Developer Portal tienen niveles separados, incluyendo un portal autoalojado de código abierto a $0/mes. Los números actuales se encuentran en la página de precios de Zuplo y vale la pena revisarlos antes de firmar un contrato.

Para comparar: AWS API Gateway cobra $3.50 por millón de solicitudes REST, luego la transferencia de datos y luego los costos de Lambda si usas integraciones de Lambda. El nivel empresarial de Kong es personalizado y históricamente se sitúa muy por encima del mínimo de $1,000 de Zuplo. Solo el nivel gratuito hace que Zuplo sea difícil de superar para proyectos en etapas iniciales.

Cuándo Zuplo es la opción correcta (y cuándo no)

Zuplo es una excelente opción cuando:

• Deseas un gateway gestionado y no quieres ejecutar Kong en Kubernetes.
• Tu equipo domina TypeScript o JavaScript.
• Necesitas un portal para desarrolladores sin un proveedor separado.
• Planeas monetizar la API y deseas que la facturación de Stripe esté integrada.
• Estás exponiendo tu API a agentes de IA y quieres soporte MCP sin construir el servidor tú mismo.
• Tu tráfico es global y la latencia en el edge es importante.

Zuplo no es la opción correcta cuando:

• Necesitas control total de código abierto sobre el código del gateway (Kong es la respuesta).
• Tu stack está completamente on-premise sin salida a internet (Kong autoalojado o Tyk encajan mejor).
• Tienes requisitos muy especializados que necesitan acceso a los internos de NGINX.
• Ya estás profundamente invertido en Apigee o MuleSoft y el costo de la migración supera el beneficio.

Probando tu gateway Zuplo con Apidog

Una vez que tu gateway esté activo en un entorno de vista previa, necesitas probar cada ruta, cada política y cada caso extremo antes de promocionar a producción. Aquí es donde un cliente API dedicado demuestra su valor.

Apidog importa directamente tu especificación OpenAPI, por lo que la misma especificación que impulsa tus rutas Zuplo también impulsa tu suite de pruebas. Desde allí puedes:

• Llamar a cada ruta con claves API válidas e inválidas para confirmar que las políticas de autenticación se comportan correctamente.
• Enviar cargas útiles mal formadas para verificar que la validación de solicitudes las rechaza con el estado esperado.
• Bombardear endpoints para validar que las políticas de limitación de tasas se activan en el umbral correcto.
• Guardar variables de entorno para tu URL de vista previa de Zuplo, tu URL de producción y tus claves API para que puedas alternar entre entornos con un solo clic.
• Generar ejemplos de código en cURL, JavaScript, Python y Go para pegar en los manuales de tu equipo.

También puedes ejecutar los escenarios de prueba automatizados de Apidog contra el gateway, lo cual es más rápido que escribir scripts únicos. Si no has usado Apidog antes, la extensión de Apidog para VS Code te permite enviar solicitudes sin salir de tu editor, y la guía de pruebas de API sin Postman te explica la migración si vienes de otro cliente. Descarga Apidog para empezar.

Preguntas frecuentes sobre el gateway API de Zuplo

¿Es Zuplo de código abierto?

El runtime principal del gateway es de código cerrado, pero Zuplo ha abierto el código del portal para desarrolladores y varias bibliotecas de apoyo en GitHub. Si necesitas una opción autoalojada, el portal de código abierto más un despliegue de Kubernetes autoalojado del gateway cubre la mayoría de las necesidades. La mayoría de los equipos permanecen en el servicio gestionado.

¿Puede Zuplo ejecutarse en mi propia infraestructura?

Sí. El plan Enterprise incluye una opción de Kubernetes autoalojado. El inconveniente es que renuncias al despliegue global en el edge y asumes las operaciones del clúster tú mismo. Para equipos con reglas estrictas de residencia de datos, esta es la opción correcta.

¿Cómo se compara Zuplo con Cloudflare API Shield?

API Shield es un producto enfocado en la seguridad (validación de esquemas, detección de abusos, mTLS) que se sitúa frente a cualquier origen. Zuplo es una plataforma completa de gestión de API: enrutamiento, políticas, portal para desarrolladores, monetización, soporte MCP. Ambos pueden coexistir. Si solo necesitas señales de seguridad, API Shield es suficiente. Si necesitas el ciclo de vida completo, Zuplo es la plataforma.

¿Funciona Zuplo con mi especificación OpenAPI existente?

Sí. OpenAPI es la fuente de verdad en Zuplo. Importa la especificación, las rutas aparecen, el portal para desarrolladores se genera a partir de la misma especificación y las políticas de validación de solicitudes utilizan los mismos esquemas. Si tu especificación es desordenada, el proceso de importación es el momento en que lo descubrirás.

¿Puedo exponer mi gateway Zuplo a agentes de IA como Claude o Codex?

Sí, a través del Manejador de Servidor MCP. Apuntas el manejador a tu especificación OpenAPI, eliges qué operaciones exponer y el gateway se vuelve invocable por cualquier cliente compatible con MCP. Las mismas políticas de autenticación y limitación de tasas que definiste para los llamantes humanos se aplican automáticamente.

¿Cuánto tiempo tarda un despliegue de Zuplo?

Un ciclo de push-to-deploy suele tardar menos de sesenta segundos para un entorno de vista previa. Las promociones a producción son más rápidas porque el artefacto ya está construido. No hay ventanas de mantenimiento; los despliegues son atómicos.

¿Qué sucede si Cloudflare se cae?

Zuplo se ejecuta en la red de borde de Cloudflare, por lo que una interrupción regional de Cloudflare afectará a esa región. El plan Enterprise ofrece opciones de conmutación por error multi-nube para equipos que necesitan una disponibilidad del 99.999%. La mayoría de los equipos aceptan la dependencia dado el historial de fiabilidad de Cloudflare.

Conclusión

Zuplo es el gateway API para equipos que desean características empresariales sin la carga operativa. Las políticas nativas de TypeScript, los despliegues GitOps, un portal para desarrolladores autogenerado, la monetización integrada y ahora el soporte MCP para agentes de IA lo convierten en una plataforma completa en lugar de una fina capa de enrutamiento. El nivel gratuito es lo suficientemente generoso para el tráfico de producción real, y el plan Enterprise se encarga del resto.

Si estás evaluando, realiza la configuración de treinta minutos con una de tus API reales, pruébala con Apidog para validar cada política y decide basándote en la evidencia en lugar de en las páginas de marketing. La combinación de un gateway edge gestionado y un potente cliente de pruebas es el camino más rápido de "tenemos una API" a "tenemos un producto". Descarga Apidog y empieza a probar.