zuplo 7.3.2 → 7.4.3

package/docs/articles/feature-flags.mdx

@@ -0,0 +1,442 @@
+---
+title: Use Feature Flags to Gate Your API
+sidebar_label: Feature Flags & Gating
+description:
+  Evaluate feature flags from providers like Statsig, PostHog, Flagsmith, and
+  GrowthBook inside Zuplo policies. Cache per-user evaluations for low latency
+  and load global flags in the background so they never block a request.
+tags:
+  - integrations
+  - custom-code
+  - caching
+---
+
+Zuplo doesn't have a dedicated feature-flag policy — instead, every provider
+works, because you evaluate flags in custom code. This guide shows the patterns
+that keep flag checks fast on a gateway, with worked examples for Statsig,
+PostHog, Flagsmith, and GrowthBook:
+
+- **Live evaluation with caching** — call the provider's API on the request and
+  cache the result per user for a short TTL. Use for flags targeted at
+  individual users, plans, or tenants.
+- **Background loading** — load flags that apply globally (kill switches,
+  maintenance mode, flag definitions) with the
+  [BackgroundLoader](../programmable-api/background-loader.mdx), which refreshes
+  out of band instead of blocking requests.
+- **Provider SDK with local evaluation** — evaluate flags in-process with no
+  per-request provider call, at the cost of a heavier cold start. See
+  [Statsig, fully local](#statsig-fully-local).
+
+## Choose a pattern
+
+| Pattern                            | Best for                                           | Latency cost per request                            |
+| ---------------------------------- | -------------------------------------------------- | --------------------------------------------------- |
+| Live evaluation + cache            | Per-user or per-plan targeting                     | One provider call per user per TTL window           |
+| Background loading                 | Global flags, kill switches, flag definition files | None in the steady state; refreshes run out of band |
+| Provider SDK with local evaluation | Complex targeting rules, many gates per request    | None after initialization, but heavier cold start   |
+
+Most APIs mix these: a background-loaded global flag set plus a small number of
+cached per-user checks on the routes that need them.
+
+## Prerequisites
+
+- A Zuplo project with an authentication policy on the routes you want to gate
+  (for example [API key authentication](../policies/api-key-inbound.mdx)). The
+  examples read `request.user`, which an inbound authentication policy populates
+  — `request.user.sub` is the user identifier and `request.user.data` carries
+  JWT claims or API key metadata such as the customer's `plan`. See
+  [Request User](../programmable-api/request-user.mdx).
+- An API key or token from your flag provider, stored as a secret
+  [environment variable](./environment-variables.mdx). Where to find each one:
+
+  | Variable                    | Provider   | Where to find it                                   | Secret? |
+  | --------------------------- | ---------- | -------------------------------------------------- | ------- |
+  | `STATSIG_SERVER_KEY`        | Statsig    | Console → Settings → API Keys → Server Secret Key  | Yes     |
+  | `STATSIG_CLIENT_KEY`        | Statsig    | Console → Settings → API Keys → Client SDK Key     | No      |
+  | `POSTHOG_PROJECT_TOKEN`     | PostHog    | Project Settings → Project ID → project token      | No      |
+  | `FLAGSMITH_ENVIRONMENT_KEY` | Flagsmith  | Environment settings → client-side environment key | No      |
+  | `GROWTHBOOK_CLIENT_KEY`     | GrowthBook | SDK Connections → client key                       | No      |
+
+  New environment variables require a redeployment before your code sees them.
+
+You only need the variables for the providers you use — skip the rest.
+
+## Pattern 1: Live evaluation with caching
+
+Every major provider exposes an HTTP endpoint that evaluates a flag for a user
+and returns the result. Call it on the first request, then cache the result in a
+[MemoryZoneReadThroughCache](../programmable-api/memory-zone-read-through-cache.mdx)
+so subsequent requests for the same user skip the network call.
+
+This example checks a Statsig gate and caches the result for 60 seconds:
+
+```ts title="modules/feature-gate-policy.ts"
+import {
+  HttpProblems,
+  MemoryZoneReadThroughCache,
+  ZuploContext,
+  ZuploRequest,
+  environment,
+} from "@zuplo/runtime";
+
+const CACHE_NAME = "feature-flags";
+const CACHE_TTL_SECONDS = 60;
+
+async function isGateEnabled(
+  gateName: string,
+  userId: string,
+  context: ZuploContext,
+): Promise<boolean> {
+  const cache = new MemoryZoneReadThroughCache<boolean>(CACHE_NAME, context);
+  const cacheKey = `statsig:${gateName}:${userId}`;
+
+  const cached = await cache.get(cacheKey);
+  if (cached !== undefined) {
+    return cached;
+  }
+
+  const response = await fetch("https://api.statsig.com/v1/check_gate", {
+    method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+      "statsig-api-key": environment.STATSIG_SERVER_KEY,
+    },
+    body: JSON.stringify({
+      gateName,
+      user: { userID: userId },
+    }),
+  });
+
+  if (!response.ok) {
+    // Fail closed: if Statsig is unreachable, deny the feature rather
+    // than exposing something that isn't rolled out. Choose deliberately —
+    // see "Decide how to fail" below.
+    context.log.error(`Statsig check failed: ${response.status}`);
+    return false;
+  }
+
+  const result = await response.json();
+  const enabled = result.value === true;
+  cache.put(cacheKey, enabled, CACHE_TTL_SECONDS);
+  return enabled;
+}
+
+export default async function policy(
+  request: ZuploRequest,
+  context: ZuploContext,
+) {
+  const userId = request.user?.sub;
+  if (!userId) {
+    return HttpProblems.unauthorized(request, context);
+  }
+
+  const enabled = await isGateEnabled("new-beta-endpoint", userId, context);
+  if (!enabled) {
+    return HttpProblems.forbidden(request, context, {
+      detail: "This feature is not enabled for your account",
+    });
+  }
+
+  return request;
+}
+```
+
+Only the first request for each user pays for the Statsig call; every request
+after that reads from memory until the TTL expires. Keep the TTL short (30–120
+seconds) so flag changes in the provider propagate quickly. To check several
+gates, fire the `check_gate` calls in parallel with `Promise.all` and cache each
+result under its own key.
+
+### Wire up the policy
+
+Register the module as a custom code policy in `config/policies.json`:
+
+```json title="config/policies.json"
+{
+  "name": "feature-gate",
+  "policyType": "custom-code-inbound",
+  "handler": {
+    "export": "default",
+    "module": "$import(./modules/feature-gate-policy)"
+  }
+}
+```
+
+Then add it to the inbound policy chain of each route you want to gate, after
+authentication:
+
+```json title="config/routes.oas.json"
+{
+  "paths": {
+    "/beta/insights": {
+      "get": {
+        "x-zuplo-route": {
+          "policies": {
+            "inbound": ["api-key-auth", "feature-gate"]
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+### Verify the gate
+
+Call the route twice — once with the flag off and once on:
+
+- **Flag off** — the request returns `403` with an `application/problem+json`
+  body: `"detail": "This feature is not enabled for your account"`.
+- **Flag on** — the request passes through to the handler normally.
+
+Because the example fails closed, a bad key or unreachable Statsig returns the
+same 403 as a disabled flag. Watch the logs for the `Statsig check failed:`
+error line to tell a provider outage apart from a legitimately denied request.
+
+## Pattern 2: Background loading for global flags
+
+Some flags apply to everyone: kill switches, maintenance mode, or a global
+rollout. Others are cheapest to fetch as one shared definition file rather than
+per-user evaluations. Either way, there's no reason to make a request wait on
+that fetch — load it in the background instead.
+
+The [BackgroundLoader](../programmable-api/background-loader.mdx) returns cached
+data immediately when available, refreshes it asynchronously when the TTL
+expires, and only blocks while the cache is empty on a cold start. Create it at
+module level so the loader is shared across requests handled by the same worker
+process ([isolate](../concepts/how-zuplo-works.mdx)).
+
+GrowthBook is a natural fit here: its CDN returns the full feature definition
+payload as a single cacheable JSON document.
+
+```ts title="modules/global-flags-policy.ts"
+import {
+  BackgroundLoader,
+  HttpProblems,
+  ZuploContext,
+  ZuploRequest,
+  environment,
+} from "@zuplo/runtime";
+
+interface GrowthBookFeatures {
+  [flagName: string]: { defaultValue: unknown };
+}
+
+const featureLoader = new BackgroundLoader<GrowthBookFeatures>(
+  async () => {
+    const response = await fetch(
+      `https://cdn.growthbook.io/api/features/${environment.GROWTHBOOK_CLIENT_KEY}`,
+    );
+    if (!response.ok) {
+      throw new Error(`Failed to load features: ${response.status}`);
+    }
+    const data = await response.json();
+    return data.features;
+  },
+  {
+    ttlSeconds: 60,
+    loaderTimeoutSeconds: 5,
+  },
+);
+
+export default async function policy(
+  request: ZuploRequest,
+  context: ZuploContext,
+) {
+  // Returns cached definitions immediately in the steady state;
+  // the only blocking case is an empty cache on a cold start.
+  const features = await featureLoader.get("features");
+
+  if (features["api-maintenance-mode"]?.defaultValue === true) {
+    return HttpProblems.serviceUnavailable(request, context, {
+      detail: "This API is temporarily unavailable for maintenance",
+    });
+  }
+
+  return request;
+}
+```
+
+Register this module as a `custom-code-inbound` policy in `config/policies.json`
+and add it to the routes you want to gate, exactly as in pattern 1.
+
+The same pattern works for any provider payload that isn't user-specific — for
+example a Statsig gate evaluated against a fixed global user, or the Flagsmith
+environment document. One BackgroundLoader per provider keeps each payload on
+its own refresh cadence.
+
+:::note
+
+The `defaultValue` shortcut covers simple on/off flags. Flags with targeting
+rules or percentage rollouts need an evaluator — either evaluate remotely
+(pattern 1) or pass the definitions to the provider's JavaScript SDK.
+
+:::
+
+## More providers
+
+The live-evaluation pattern is the same everywhere; only the endpoint, headers,
+and response shape change. Swap the fetch call inside the cached helper — and,
+for providers like PostHog that evaluate all flags in one call, cache the whole
+map keyed by user instead of a boolean keyed by gate and user.
+
+### PostHog
+
+PostHog evaluates **all** flags for a user in one call, so cache the whole map
+per `distinct_id`. Use your project token — it's safe for this public endpoint,
+though you should still store it in an environment variable.
+
+```ts
+const response = await fetch("https://us.i.posthog.com/flags?v=2", {
+  method: "POST",
+  headers: { "Content-Type": "application/json" },
+  body: JSON.stringify({
+    api_key: environment.POSTHOG_PROJECT_TOKEN,
+    distinct_id: userId,
+    person_properties: { plan: request.user?.data?.plan },
+  }),
+});
+
+const data = await response.json();
+// Cache the whole map: cache.put(`posthog:${userId}`, data.flags, 60)
+// data.flags["new-checkout"] = { key, enabled, variant, metadata: { payload } }
+const enabled = data.flags?.["new-checkout"]?.enabled === true;
+const variant = data.flags?.["new-checkout"]?.variant; // multivariate flags
+```
+
+Use `https://eu.i.posthog.com` if your PostHog project is hosted in the EU.
+
+### Flagsmith
+
+Flagsmith's edge API evaluates flags for an identity with a simple GET. Use the
+client-side environment key (not a server-side SDK key) — it's designed to be
+public.
+
+```ts
+const response = await fetch(
+  `https://edge.api.flagsmith.com/api/v1/identities/?identifier=${encodeURIComponent(userId)}`,
+  {
+    headers: { "X-Environment-Key": environment.FLAGSMITH_ENVIRONMENT_KEY },
+  },
+);
+
+const data = await response.json();
+const flag = data.flags?.find((f) => f.feature.name === "new-checkout");
+const enabled = flag?.enabled === true;
+const value = flag?.feature_state_value; // remote config value
+```
+
+### Statsig, fully local
+
+If you need many gates evaluated per request with zero provider calls, use
+Statsig's `@statsig/serverless-client` SDK, which is built for short-lived
+worker processes. Unlike the HTTP API examples above (which use the server
+secret key), the serverless client evaluates on-device and authenticates with
+the publishable client SDK key.
+
+Zuplo runs a custom JavaScript engine rather than Node.js, so third-party
+packages must be bundled into your project before you can import them — see
+[Node Modules](../programmable-api/node-modules.mdx). Bundle the SDK once, then
+import it from the bundled path:
+
+```bash
+npm install @statsig/serverless-client
+npx tsdown ./node_modules/@statsig/serverless-client --format esm --platform browser --out-dir ./modules/third-party/statsig
+```
+
+Initialize the client once at module level so the configuration download happens
+on cold start, not per request. Evaluate gates locally, and flush exposure
+events with
+[`context.waitUntil`](../programmable-api/zuplo-context.mdx#waituntil) so
+analytics never add latency to a response:
+
+```ts title="modules/statsig-local-policy.ts"
+import {
+  HttpProblems,
+  ZuploContext,
+  ZuploRequest,
+  environment,
+} from "@zuplo/runtime";
+import { StatsigServerlessClient } from "./third-party/statsig/index.mjs";
+
+const client = new StatsigServerlessClient(environment.STATSIG_CLIENT_KEY);
+// Kicks off the config download once per worker process, not per request
+const ready = client.initializeAsync();
+
+export default async function policy(
+  request: ZuploRequest,
+  context: ZuploContext,
+) {
+  await ready;
+  const enabled = client.checkGate("new-beta-endpoint", {
+    userID: request.user?.sub,
+  });
+  context.waitUntil(client.flush());
+
+  if (!enabled) {
+    return HttpProblems.forbidden(request, context, {
+      detail: "This feature is not enabled for your account",
+    });
+  }
+  return request;
+}
+```
+
+### What about LaunchDarkly?
+
+LaunchDarkly is the least HTTP-friendly option. Its server-side SDK holds a
+persistent streaming connection open and relies on Node.js APIs that don't run
+in Zuplo's engine, and LaunchDarkly doesn't document a plain-HTTP endpoint for
+server-side evaluation. Its
+[edge SDKs](https://launchdarkly.com/docs/sdk/server-side) evaluate locally but
+assume platform-specific storage bindings (Cloudflare KV, Vercel Edge Config,
+and similar), so they don't drop directly into a Zuplo project either. If
+LaunchDarkly is your provider, the practical paths are evaluating flags in your
+backend behind the gateway, or syncing flag state into a store your Zuplo code
+reads with the patterns above.
+
+## Gate an MCP server with flags
+
+If you're fronting an MCP server with the
+[MCP Gateway](../mcp-gateway/introduction.mdx), the same policies apply — MCP
+routes run the standard inbound policy chain before the handler. Add your
+feature-gate policy to the MCP route to control access per user or plan, for
+example to make MCP access a paid-tier feature or to turn off a beta server.
+
+For curating _which tools_ a server exposes, start with the static
+[capability filtering](../mcp-gateway/capability-filtering.mdx) policy, which
+needs no code. Feature flags complement it when the availability of the server
+itself must change dynamically per user without a redeploy.
+
+## Best practices
+
+1. **Decide how to fail.** If the provider is unreachable, fail closed (deny the
+   feature) for rollouts of risky functionality, or fail open (allow) for
+   cosmetic features. The examples above fail closed and log the error.
+2. **Keep per-user TTLs short.** 30–120 seconds balances provider traffic
+   against flag-change propagation. Global definitions can tolerate longer.
+3. **Cache the smallest useful value.** A boolean per gate per user stays well
+   within memory limits; don't cache whole provider responses you don't need.
+   Remember a Zuplo process has roughly 120 MB of memory — see
+   [Lazy Load Configuration](./lazy-load-configuration-into-cache.mdx) for the
+   caching trade-offs.
+4. **Store keys in environment variables.** Use secret
+   [environment variables](./environment-variables.mdx) for server keys like
+   Statsig's server secret; never hardcode them.
+5. **Log exposures in the background.** Providers use exposure events for
+   analytics and experiments. Send them with
+   [`context.waitUntil`](../programmable-api/zuplo-context.mdx#waituntil) (as in
+   the Statsig SDK example) so analytics never add latency to a request.
+
+## Next steps
+
+- [BackgroundLoader](../programmable-api/background-loader.mdx) — the primitive
+  behind pattern 2
+- [MemoryZoneReadThroughCache](../programmable-api/memory-zone-read-through-cache.mdx)
+  and [ZoneCache](../programmable-api/zone-cache.mdx) — the caching layers
+- [Custom code policies](../policies/custom-code-inbound.mdx) — how inbound
+  policies are wired and run
+- [Lazy Load Configuration](./lazy-load-configuration-into-cache.mdx) — the
+  general config-caching pattern this guide builds on
+- [Curate the tools an upstream exposes](../mcp-gateway/how-to/curate-tools.mdx)
+  — static MCP tool curation to combine with flags

package/docs/articles/gke-with-upstream-auth-policy.mdx

@@ -3,12 +3,12 @@ title: Secure a GCP Backend with Zuplo Upstream Auth
 sidebar_label: GCP Backend
 ---
 
-When using any API gateway as your API's entry point, it's critical that only
-traffic that originates from the Gateway is allowed to call your backend. There
+When using any gateway as your API's entry point, it's critical that only
+traffic that originates from the gateway is allowed to call your backend. There
 are [many way to this](./securing-your-backend.mdx) depending on your
 requirements and how your backend is hosted. This article will explain how to
 use Google IAM to secure a GKE cluster so that only requests made through your
-Zuplo API Gateway will be allowed to call your GKE ingress.
+Zuplo Gateway will be allowed to call your GKE ingress.
 
 Using GCP IAM to authorize your Zuplo Gateway to make requests to your backend
 utilizes Googles core IAM system known as
@@ -33,11 +33,11 @@ set up behind an HTTP Load Balancer can be used.
 The diagram below shows how the end-to-end system interacts. The important steps
 to this process are:
 
-1. The client makes a request to your Zuplo API Gateway
-1. The Zuplo API Gateway enforces any policies (for example authentication,
+1. The client makes a request to your Zuplo Gateway
+1. The Zuplo Gateway enforces any policies (for example authentication,
    authorization, rate limiting)
-1. The Zuplo API Gateway proxies the request to the public IP address of your
-   GCP Load Balancer. Zuplo adds authorization information to the request that
+1. The Zuplo Gateway proxies the request to the public IP address of your GCP
+   Load Balancer. Zuplo adds authorization information to the request that
    identify the request as coming from Zuplo
 1. GCP Identity Aware proxy validates that the request comes from an authorized
    Service Account identity. Unauthorized requests are rejected.

package/docs/articles/health-checks.mdx

@@ -2,19 +2,19 @@
 title: Health Check Handler
 sidebar_label: Health Checks
 description:
-  Learn how to set up health check endpoints to monitor your API Gateway and
+  Learn how to set up health check endpoints to monitor your Zuplo Gateway and
   backend services.
 tags:
   - observability
   - backends
 ---
 
-Part of running a reliable API Gateway is ensuring that the service is healthy
+Part of running a reliable Zuplo Gateway is ensuring that the service is healthy
 and available. With Zuplo, it's easy to set up a health check endpoint that can
 be used to ensure the health of both your Zuplo Gateway and your backend (as
 well as the connectivity between them).
 
-A typical health check endpoint on your API Gateway will exercise some of the
+A typical health check endpoint on your Zuplo Gateway will exercise some of the
 most important policies (such as authentication) and then make a simple request
 to your backend to ensure that it's reachable and functioning.
 
@@ -32,7 +32,7 @@ OpenAPI file this would look like:
     "/health": {
       "get": {
         "summary": "Health Check",
-        "description": "Checks the health of the API Gateway and backend.",
+        "description": "Checks the health of the Zuplo Gateway and backend.",
         "responses": {
           "200": {
             "description": "OK"

package/docs/articles/hosting-options.mdx

@@ -32,7 +32,7 @@ your service hosted to meet any sovereignty or data residency concerns.
 
 Managed Dedicated is ideal for organizations that need:
 
-- To run your API Gateway on a specific cloud provider
+- To run your Zuplo Gateway on a specific cloud provider
 - Custom networking configurations, such as restricting access to the public
   internet
 - Geographical deployment requirements where Managed Edge isn't feasible
@@ -50,7 +50,7 @@ Run Zuplo on your own infrastructure in any cloud or private data center. Zuplo
 Self-Hosted runs exclusively on Kubernetes and is installed with a single Helm
 chart into your cluster.
 
-In the standard hybrid deployment model, you run the Zuplo API Gateway and its
+In the standard hybrid deployment model, you run the Zuplo Gateway and its
 management plane on your Kubernetes cluster, while a small set of Zuplo cloud
 services provides supporting features such as deployment configuration and API
 key management. All API traffic to your gateways stays on your infrastructure.

package/docs/articles/local-development-env-variables.mdx

@@ -5,7 +5,7 @@ sidebar_label: Environment variables
 
 For security reasons, your local development doesn't have access to the
 environment variables that you have configured on the Zuplo Portal. Instead,
-your local Zuplo API Gateway will load environment variables from a .env file.
+your local Zuplo Gateway will load environment variables from a .env file.
 
 1. Create a .env file in the root of your project.
 2. Follow the following format

package/docs/articles/metrics-plugins.mdx

@@ -28,7 +28,7 @@ Zuplo supports the following metrics:
 
 - request latency
   - This measures the total time (in milliseconds) that a request takes once it
-    has entered the API Gateway. It includes any outbound calls from the
+    has entered the Zuplo Gateway. It includes any outbound calls from the
     gateway.
 - request content length
   - The content length of the request as reported by the content-length header.

package/docs/articles/migration-overview.md

@@ -3,7 +3,7 @@ title: Migrate to Zuplo from Other API Gateways
 sidebar_label: Migration Overview
 ---
 
-Moving to Zuplo from another API gateway is straightforward. Zuplo is
+Moving to Zuplo from another gateway is straightforward. Zuplo is
 OpenAPI-native, so you can import your existing API definitions and start
 configuring policies in minutes. This section provides migration guides for the
 most common API gateways.

package/docs/articles/monorepo-deployment.mdx

@@ -2,18 +2,18 @@
 title: Deploying Zuplo from a Monorepo
 sidebar_label: Monorepo Deployment
 description:
-  "Deploy a Zuplo API gateway from a monorepo subdirectory using the Zuplo CLI
-  and GitHub Actions."
+  "Deploy a Zuplo Gateway from a monorepo subdirectory using the Zuplo CLI and
+  GitHub Actions."
 ---
 
-If your Zuplo API gateway lives inside a monorepo alongside other services, you
-can deploy it using the [Zuplo CLI](../cli/overview.mdx) and your CI/CD
-provider. Zuplo's
-[built-in GitHub integration](./source-control-setup-github.mdx) connects each
-project to a dedicated repository and deploys automatically on every push.
-Because it doesn't natively support projects located in a subdirectory, you need
-to use the Zuplo CLI with a [custom CI/CD pipeline](./custom-ci-cd.mdx) to
-deploy from the correct directory.
+If your Zuplo Gateway lives inside a monorepo alongside other services, you can
+deploy it using the [Zuplo CLI](../cli/overview.mdx) and your CI/CD provider.
+Zuplo's [built-in GitHub integration](./source-control-setup-github.mdx)
+connects each project to a dedicated repository and deploys automatically on
+every push. Because it doesn't natively support projects located in a
+subdirectory, you need to use the Zuplo CLI with a
+[custom CI/CD pipeline](./custom-ci-cd.mdx) to deploy from the correct
+directory.
 
 This guide covers the project structure requirements, CI/CD configuration, local
 development, and common troubleshooting steps for monorepo setups.

package/docs/articles/performance-testing.mdx

@@ -1,17 +1,18 @@
 ---
-title: Performance Testing Your API Gateway
+title: Performance Testing Your Gateway
 sidebar_label: Performance Testing
 ---
 
 <!-- vale Vale.Spelling["Blazemeter","JMeter","wrk"] = NO -->
 
 Performance testing is critical for understanding the real-world performance of
-your API when using an API gateway like Zuplo. This guide helps you create fair
-and accurate performance tests that properly measure latency and throughput.
+your API when using a unified gateway like Zuplo. This guide helps you create
+fair and accurate performance tests that properly measure latency and
+throughput.
 
 ## Creating Fair Comparison Tests
 
-When evaluating API gateway performance, it's essential to ensure your tests
+When evaluating gateway performance, it's essential to ensure your tests
 accurately reflect real-world conditions and provide a fair comparison between
 direct backend calls and calls through your gateway.
 
@@ -53,7 +54,7 @@ traffic experiences significantly higher jitter (variance), making response
 times less predictable.
 
 This artificial performance boost from testing within the same cloud provider
-can make it appear that an API gateway adds substantially more latency than it
+can make it appear that a gateway adds substantially more latency than it
 actually does in real-world scenarios where traffic crosses network boundaries.
 
 ### Ensure Test Equality
@@ -106,14 +107,14 @@ impact in your analysis.
 
 ## Understanding Gateway Latency
 
-API gateways necessarily add some latency to process requests. For Zuplo:
+Gateways necessarily add some latency to process requests. For Zuplo:
 
 - **Base latency:** Approximately 20-30ms with no policies
 - **Per policy:** Most policies add 1-5ms each
 - **Complex policies:** Authentication, rate limiting, or custom code can add
   5-15ms
 
-This latency is the trade-off for the benefits an API gateway provides:
+This latency is the trade-off for the benefits a gateway provides:
 
 - Centralized authentication and authorization
 - Rate limiting and quota management
@@ -299,7 +300,7 @@ Managed Dedicated, Zuplo can be deployed directly to:
 
 This deployment model provides:
 
-- **Minimal latency:** Your API gateway runs in the same cloud network as your
+- **Minimal latency:** Your gateway runs in the same cloud network as your
   backend
 - **Predictable performance:** Consistent sub-10ms latency for intra-region
   traffic
@@ -364,7 +365,7 @@ periods.
 ## Summary
 
 Creating fair performance tests requires careful attention to test conditions,
-understanding of network topology, and realistic expectations about API gateway
+understanding of network topology, and realistic expectations about gateway
 overhead. By following these guidelines, you'll get accurate measurements that
 help you make informed decisions about your API architecture.
 

package/docs/articles/plugin-azure-blob.mdx

@@ -4,7 +4,7 @@ sidebar_label: Azure Blob
 ---
 
 This plugin pushes request/response logs to Azure Blob Storage. This can be used
-to save request data generated by your API Gateway to use for monitoring,
+to save request data generated by your Zuplo Gateway to use for monitoring,
 analytics, auditing, or debugging purposes.
 
 <EnterpriseFeature name="Custom logging" />

package/docs/articles/plugin-azure-event-hubs.mdx

@@ -4,8 +4,8 @@ sidebar_label: Azure Event Hubs
 ---
 
 This plugin pushes request/response logs to Azure Event Hubs. This can be used
-to stream the request data generated by your API Gateway to use for monitoring,
-analytics, auditing, or debugging purposes.
+to stream the request data generated by your Zuplo Gateway to use for
+monitoring, analytics, auditing, or debugging purposes.
 
 <EnterpriseFeature name="Custom logging" />