What Is the Zuplo API Gateway?

Most API gateways still feel like they were designed for a 2014 ops team. You write YAML, you wrestle with a control plane, and you wait for someone with cluster access to push your changes. Zuplo flips that model. It is a programmable, edge-native API gateway where your routes live in a Git repo, your policies are TypeScript, and every commit deploys to 300+ global locations in seconds.

This guide explains what the Zuplo API gateway does, how it differs from Kong and AWS API Gateway, what it costs, and how to ship your first gateway in under thirty minutes. You will see code examples for routing, authentication, and rate limiting, plus a section on testing every endpoint with Apidog before it hits production.

Zuplo sits in a category that used to be dominated by Kong, Apigee, and AWS API Gateway. The pitch is simple: developers get a real programming language, ops gets a managed service, and product gets a built-in monetization layer. The trade-offs and the actual workflow are what this post unpacks.

TL;DR

• Zuplo is a fully managed, edge-native API gateway that runs your routes across 300+ Cloudflare data centers with sub-50ms latency and zero cold starts.
• Configuration is GitOps-native; your gateway lives in a Git repository and ships through CI/CD, not a UI.
• Policies are written in TypeScript with full IDE support, not YAML or Lua.
• The free tier covers 100K requests per month with unlimited environments, API keys, and developer portals.
• Built-in features include API key auth, JWT, OAuth2, rate limiting, request validation, an auto-generated developer portal, and Stripe-powered monetization.
• Zuplo now ships an MCP Server Handler, so any gateway route can be exposed to Claude, Codex, Cursor, or any MCP client.
• Test every Zuplo route end-to-end with Apidog before you flip the toggle in production.

What is Zuplo?

Zuplo is an API management platform built around three ideas: code over config, edge over region, and Git over GUI. It runs as a fully managed service on Cloudflare’s edge network, so a single deployment lands in 300+ data centers without you provisioning anything.

Where most gateways treat your config as a YAML artifact stored in a control plane database, Zuplo treats your gateway as a TypeScript project. You get a routes.oas.json file describing endpoints, a folder of TypeScript modules for custom logic, and a config file for the policies you wire in. Push to GitHub and the platform builds, validates, and deploys.

The platform supports REST, GraphQL, gRPC, WebSockets, and SOAP. It is SOC 2 Type II compliant, runs across AWS, Azure, and GCP backends, and offers a self-hosted Kubernetes option for teams with strict data residency rules. Pricing starts free and scales with request volume instead of per-seat fees. The full breakdown lives on the Zuplo pricing page.

Why developers pick Zuplo over Kong, Apigee, and AWS API Gateway

Each gateway has a personality. Kong is the open-source heavyweight that gives you maximum control and asks for Lua expertise in return. Apigee is the enterprise platform with deep analytics and a steep learning curve. AWS API Gateway is the default if your stack already lives in AWS, but the developer portal is missing and the cold-start tax on Lambda integrations is real.

Zuplo aims at a different buyer: the small team that wants enterprise-grade features without the platform-engineering headcount to run them.

A few specific differences:

• Code, not YAML. A rate-limiting policy in Zuplo is three lines of TypeScript. The same policy in Kong is roughly fifteen lines of YAML wired into a plugin. The Kong vs Zuplo comparison Zuplo publishes makes this concrete; if you spend most of your day in TypeScript or JavaScript, the Zuplo config will feel native.
• Developer portal included. Kong’s portal is enterprise-only. Apigee’s portal exists but takes real effort to brand. Zuplo generates a portal directly from your OpenAPI spec on every plan, free tier included.
• GitOps by default. Every change is a pull request. You get reviews, audit logs, and git revert for free. No UI clicks to chase down when something breaks at 3 AM.
• Edge-native, no cold starts. Zuplo runs on Cloudflare Workers, which means each gateway request hits the closest of 300+ data centers and starts in single-digit milliseconds. AWS API Gateway plus Lambda routinely adds 100–800ms of cold start.

If your team is already invested in Kong or Apigee and the operational load is fine, switching is rarely worth it. If you are picking fresh, or your current gateway is fighting you, the Zuplo workflow is the clearest improvement of any platform shipping today.

Core features of the Zuplo API gateway

TypeScript-first programmability

The gateway behavior is defined in TypeScript files that live next to your routes. Custom inbound and outbound policies are functions that receive the request, do whatever you want, and return the modified request or response. You get the full TypeScript toolchain: types, autocomplete, refactoring, and tests.

A trivial outbound policy that strips an internal header before responding to 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;
}

That is the entire policy. Drop it in modules/strip-internal-header.ts, reference it in your route, push to Git, and it ships.

60+ pre-built policies

Most teams will not write custom code for the basics. Zuplo ships 60+ pre-built policies covering API key auth, JWT validation, OAuth 2.0, rate limiting (fixed-window, sliding-window, token bucket), request and response validation against your OpenAPI schema, CORS, IP allowlists, request transformation, and a handful of upstream integrations. You wire them in by editing the route definition; no code changes required for standard cases.

Auto-generated developer portal

Point the portal at your OpenAPI spec and you get a hosted documentation site with interactive try-it consoles, code samples in cURL, JavaScript, Python, Go, and others, plus self-serve API key issuance. End users can sign up, generate keys, and start calling the API without a single human in the loop. For SaaS APIs that depend on developer adoption, this alone often justifies the platform.

Built-in API monetization

Zuplo ships a Stripe integration for selling API access. You define plans (free, pro, enterprise), connect Stripe, and the portal handles checkout, subscription management, and usage billing. This is rare in API gateways; Kong and AWS API Gateway both leave monetization as an exercise for the reader. If you are charging for API calls, the Zuplo monetization flow eliminates a multi-week build.

MCP Server Handler for AI agents

The newest addition is the MCP Server Handler. Point it at your OpenAPI spec, pick which operations to expose, and your existing API becomes callable by Claude Code, OpenAI Codex, Cursor, and any other MCP-compatible client. The same auth and rate-limiting policies you applied to human callers apply to AI agents. Zuplo published a walkthrough on exposing APIs through MCP that covers the configuration in detail.

Edge deployment, sub-50ms latency

Every gateway deploys to 300+ Cloudflare edge locations by default. The platform claims sub-50ms latency at the edge with no cold starts. In practice this means a user in Singapore hitting your API hits a Singapore-resident gateway, which then proxies to wherever your origin lives. You do not configure this; it is the only deployment mode.

How Zuplo works under the hood

A request arrives at the nearest edge location and runs through this pipeline:

1. Route match. The request URL and method are matched against your routes.oas.json to find the right handler.
2. Inbound policies. Anything you wired in (API key auth, JWT validation, rate limiting, schema validation) runs in order. If a policy throws or returns a response, the pipeline short-circuits and that response goes back to the client.
3. Handler. The handler proxies to your upstream origin, returns a static value, runs custom TypeScript, or invokes the MCP Server Handler.
4. Outbound policies. Response transformations, header stripping, and any custom outbound logic run.
5. Response. The final response goes back to the client; logs and metrics ship to Zuplo’s observability layer (or to your own provider via integrations).

The whole thing runs in a Cloudflare Worker, which is why the latency numbers hold up and why you do not pay for idle capacity.

Setting up your first Zuplo gateway

You can build a working gateway in roughly thirty minutes. Here is the shape of the workflow:

1. Sign up at zuplo.com and create a new project. Pick the GitHub integration so the project syncs to a repo you control.
2. Import an OpenAPI spec. If your upstream API already has one, import it. Zuplo turns each operation into a route. If you do not have a spec yet, you can sketch routes in the UI and export the spec later.
3. Add an API key auth policy. In the route editor, add the api-key-inbound policy. Zuplo creates the consumer database and the key issuance UI for you.
4. Add a rate limit. Drop in the rate-limit-inbound policy with a request budget like 100 requests per minute per API key. This is one JSON block in the route file.
5. Deploy. Push to your branch. Zuplo builds a preview environment with a unique URL. Promote to production with a merge.
6. Test the gateway end-to-end. Use Apidog to fire requests at the new gateway URL with valid and invalid API keys, exceeded rate limits, and bad payloads. The visual response inspector makes it easy to confirm the right policy fired in the right order.

The first project deploys in minutes. The harder work is naming routes well and deciding where to put custom logic, which is the same problem you would have on any platform.

Writing custom policies in TypeScript

The pre-built policies cover the common cases. For everything else, write a custom policy. A typical example is enriching the request with data from an internal service before it reaches your origin:

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

Three things worth noting here. First, the policy is a normal async function; testing it is a unit test, not a fixture-heavy integration test. Second, environment variables come from context.environment, which is type-safe and pulled from your project settings. Third, returning a Response short-circuits the pipeline, which is how you express auth failures or upstream errors cleanly.

Zuplo pricing in 2026

Zuplo’s pricing is unusually straightforward for this category. Three plans:

• Free, $0 per month. 100K requests per month, unlimited environments, unlimited API keys, unlimited developer portals, 1 GB egress, deployment to all 300+ edge locations, up to two gateway developers. Real production traffic; not a toy tier.
• Builder, $25 per month. Same baseline plus up to 1M requests per month, two custom domains, 1 GB egress per 100K requests, additional requests at $100 per 100K, community support.
• Enterprise, custom pricing starting at $1,000 per month on an annual contract. Unlimited requests and domains, 99.5% to 99.999% SLA options, GitHub Enterprise/GitLab/Azure DevOps integration, optional 24/7 support, SSO, RBAC, observability add-ons.

The AI Gateway and Developer Portal products have separate tiers, including an open-source self-hosted portal at $0/month. The current numbers live on the Zuplo pricing page and are worth checking before signing a contract.

For comparison: AWS API Gateway charges $3.50 per million REST requests, then data transfer, then Lambda costs if you use Lambda integrations. Kong’s enterprise tier is custom and historically lands well above Zuplo’s $1,000 floor. The free tier alone makes Zuplo hard to beat for early-stage projects.

When Zuplo is the right call (and when it is not)

Zuplo is a strong fit when:

• You want a managed gateway and do not want to run Kong on Kubernetes.
• Your team is fluent in TypeScript or JavaScript.
• You need a developer portal without a separate vendor.
• You plan to monetize the API and want Stripe billing wired in.
• You are exposing your API to AI agents and want MCP support without building the server yourself.
• Your traffic is global and edge latency matters.

Zuplo is the wrong call when:

• You need full open-source control of the gateway code (Kong is the answer).
• Your stack is fully on-premise with no internet egress (self-hosted Kong or Tyk fits better).
• You have deeply specialized requirements that need access to NGINX internals.
• You are already deeply invested in Apigee or MuleSoft and the migration cost outweighs the gain.

Testing your Zuplo gateway with Apidog

Once your gateway is live in a preview environment, you need to test every route, every policy, and every edge case before promoting to production. This is where a dedicated API client earns its keep.

Apidog imports your OpenAPI spec directly, so the same spec that powers your Zuplo routes also powers your test suite. From there you can:

• Call each route with valid and invalid API keys to confirm auth policies behave correctly.
• Send malformed payloads to verify request validation rejects them with the expected status.
• Hammer endpoints to validate rate-limit policies kick in at the right threshold.
• Save environment variables for your Zuplo preview URL, your production URL, and your API keys so you can flip between environments with one click.
• Generate code samples in cURL, JavaScript, Python, and Go to paste into your team’s runbooks.

You can also run Apidog’s automated test scenarios against the gateway, which is faster than writing one-off scripts. If you have not used Apidog before, the Apidog VS Code extension lets you fire requests without leaving your editor, and the API testing without Postman guide walks through the migration if you are coming from another client. Download Apidog to get started.

Common questions about the Zuplo API gateway

Is Zuplo open source?

The core gateway runtime is closed source, but Zuplo open-sourced the developer portal and several supporting libraries on GitHub. If you need a self-hosted option, the open-source portal plus a self-hosted Kubernetes deployment of the gateway covers most needs. Most teams stay on the managed service.

Can Zuplo run on my own infrastructure?

Yes. The Enterprise plan includes a self-hosted Kubernetes option. The trade-off is that you give up the global edge deployment and take on the cluster operations yourself. For teams with strict data residency rules, this is the right call.

How does Zuplo compare to Cloudflare API Shield?

API Shield is a security-focused product (schema validation, abuse detection, mTLS) that sits in front of any origin. Zuplo is a full API management platform: routing, policies, developer portal, monetization, MCP support. The two can coexist. If you only need security signals, API Shield is enough. If you need the full lifecycle, Zuplo is the platform.

Does Zuplo work with my existing OpenAPI spec?

Yes. OpenAPI is the source of truth in Zuplo. Import the spec, the routes appear, the developer portal generates from the same spec, and request validation policies use the same schemas. If your spec is messy, the import process is the moment you find out.

Can I expose my Zuplo gateway to AI agents like Claude or Codex?

Yes, through the MCP Server Handler. You point the handler at your OpenAPI spec, choose which operations to expose, and the gateway becomes callable by any MCP-compatible client. The same auth and rate-limit policies you defined for human callers apply automatically.

How long does a Zuplo deployment take?

A push-to-deploy cycle typically takes under sixty seconds for a preview environment. Production promotions are faster because the artifact is already built. There are no maintenance windows; deployments are atomic.

What happens if Cloudflare goes down?

Zuplo runs on Cloudflare’s edge network, so a Cloudflare regional outage will affect that region. The Enterprise plan offers multi-cloud failover options for teams that need 99.999% availability. Most teams accept the dependency given Cloudflare’s reliability record.

Conclusion

Zuplo is the API gateway for teams that want enterprise features without the operational burden. TypeScript-native policies, GitOps deployments, an auto-generated developer portal, built-in monetization, and now MCP support for AI agents make it a complete platform instead of a thin routing layer. The free tier is generous enough for real production traffic, and the Enterprise plan handles the rest.

If you are evaluating, do the thirty-minute setup with one of your real APIs, run it through Apidog to validate every policy, and decide from evidence instead of marketing pages. The combination of a managed edge gateway and a strong test client is the fastest path from “we have an API” to “we have a product.” Download Apidog and start testing.