Copy page

GraphQL

Using Zuplo with GraphQL APIs

Yes, Zuplo supports GraphQL. Zuplo is a proxy-based API gateway, and a GraphQL API is just an HTTP endpoint — typically a single POST /graphql route. Proxy your existing GraphQL server through Zuplo, then layer on authentication, rate limiting, caching, analytics, and documentation using the same policies you use for REST, plus policies built specifically for the GraphQL request shape.

This page summarizes everything Zuplo offers for GraphQL APIs and links to each guide and policy reference.

Connect and route

Proxy any GraphQL server through a POST /graphql route using the URL Rewrite handler. The Route Designer ships a GraphQL Endpoint template, and the x-graphql route extension (a boolean flag in routes.oas.json — set "x-graphql": true on the route operation) marks a route as GraphQL so the gateway and Dev Portal treat it accordingly.

• Set up an endpoint — add or mark a GraphQL route

Secure the endpoint

GraphQL's flexibility is also its attack surface: a single request can nest arbitrarily deep, fan out into thousands of resolver calls, or map your whole schema through introspection. Zuplo closes these gaps at the edge.

• Secure your GraphQL API — complexity limits and introspection controls

Authenticate and rate-limit

Because a GraphQL route is a standard Zuplo route, every general-purpose policy works on it — including authentication and rate limiting. Attach an API key auth policy or any other auth policy as an inbound policy on the POST /graphql route, then add a rate limiting policy to protect your upstream from traffic spikes. No GraphQL-specific configuration is required; these policies operate on the HTTP request before the GraphQL-specific policies run.

• API key authentication — authenticate consumers with API keys
• Rate limiting — throttle requests per consumer, IP, or globally

Accelerate with caching

A normal CDN keys on the URL, so it can't cache GraphQL queries sent as request bodies. The GraphQL cache parses each query, normalizes it into a canonical form, and serves semantically identical queries from one edge cache entry.

• Cache GraphQL responses — serve repeated queries from the edge

Observe traffic

Report GraphQL operations and their errors to analytics, even when the upstream returns errors inside a 200 response (GraphQL servers signal per-field errors in the response body rather than with HTTP status codes). The GraphQL analytics dashboard surfaces operation volume, latency, and error classes once traffic flows.

• GraphQL analytics — monitor operations, latency, and errors

Document in the Dev Portal

The @zudoku/plugin-graphql Dev Portal plugin (an npm package included with Zudoku) renders a browsable type reference and an interactive playground in your Dev Portal, generated from your schema or a live endpoint. Register one instance per API.

• Document the API in your Dev Portal — add the GraphQL plugin

Expose GraphQL to AI agents

Turn GraphQL queries into MCP tools — MCP (Model Context Protocol) is a standard that lets AI agents discover and call API operations — so AI agents can call your GraphQL API with the same policies and auth applied.

• MCP Server GraphQL endpoints — expose queries as MCP tools

Zuplo and GraphQL federation

Zuplo is a proxy-based API gateway, not a native GraphQL federation gateway. It does not perform schema composition, query planning, or subgraph orchestration — those are the job of a dedicated federation layer such as Apollo Router or a similar tool.

When you use a federated architecture, Zuplo sits in front of your federation gateway as the public-facing entry point. Traffic flows through Zuplo first for authentication, rate limiting, and analytics, then Zuplo forwards the request to Apollo Router (or your federation tool of choice), which resolves the query across your subgraphs. This layered pattern gives you edge-level security and observability without interfering with the federation layer's query planning.

Request flow with federation
Client → Zuplo (auth, rate limit, analytics) → Apollo Router → Subgraphs

If your GraphQL API is a single server (no federation), Zuplo connects to it directly and no federation layer is needed.

Policies at a glance

Every GraphQL-aware policy Zuplo ships, with its direction and purpose:

Next steps

• Set up an endpoint — proxy your GraphQL API through the gateway
• Secure your GraphQL API — complexity limits and introspection controls
• Cache GraphQL responses — cut latency with edge caching
• MCP Server GraphQL endpoints — expose queries to AI agents