zuplo 7.4.1 → 7.4.3

package/docs/api-management/introduction.md

@@ -3,7 +3,7 @@ title: Zuplo API Management
 sidebar_label: Introduction
 ---
 
-The Zuplo API Gateway is a fully-managed, lightweight API management platform
+The Zuplo Gateway is a fully-managed, lightweight API management platform
 designed for developers. It offers fast deployment, GitOps-friendly workflows,
 and unlimited environments. Whether you're an individual developer or part of an
 engineering team, Zuplo makes it easy to:

package/docs/articles/api-key-api.mdx

@@ -45,8 +45,8 @@ Consumers can contain one or more API Keys.
 
 Buckets are the top level group for this service. A bucket could be used with a
 single Zuplo environment or shared among multiple environments or projects. By
-default a Zuplo API Gateway project will be created with several buckets that
-map to production, preview, and development (working copy) environments.
+default a Zuplo Gateway project will be created with several buckets that map to
+production, preview, and development (working copy) environments.
 
 Enterprise plan customers run complex configurations where buckets are shared
 across gateway projects or even accounts. This can allow your end-users to
@@ -148,7 +148,7 @@ The response will look like this:
 }
 ```
 
-You can use this API Key to call your Zuplo API Gateway that's protected by the
+You can use this API Key to call your Zuplo Gateway that's protected by the
 [API Key Authentication](/docs/policies/api-key-inbound) policy.
 
 ### Query Consumers with API Keys By Tags

package/docs/articles/custom-ci-cd-azure.mdx

@@ -3,7 +3,7 @@ title: "Azure Pipelines"
 sidebar_label: Azure Pipelines
 ---
 
-Azure Pipelines brings enterprise-grade CI/CD to your Zuplo API gateway. Build
+Azure Pipelines brings enterprise-grade CI/CD to your Zuplo Gateway. Build
 complex deployment workflows with stages, approvals, and integrations across
 your Azure ecosystem.
 

package/docs/articles/custom-ci-cd-bitbucket.mdx

@@ -4,8 +4,8 @@ sidebar_label: Bitbucket Pipelines
 ---
 
 Bitbucket Pipelines brings CI/CD directly into your Bitbucket workflow. Define
-pipelines in `bitbucket-pipelines.yml` and deploy your Zuplo API gateway
-alongside your code reviews and pull requests.
+pipelines in `bitbucket-pipelines.yml` and deploy your Zuplo Gateway alongside
+your code reviews and pull requests.
 
 ## Why Bitbucket Pipelines with Zuplo?
 

package/docs/articles/custom-code-patterns.md

@@ -5,7 +5,7 @@ sidebar_label: Custom Code
 
 Zuplo is fully programmable. You can write custom TypeScript code for inbound
 policies, outbound policies, and request handlers to extend every part of your
-API gateway. This guide covers the function signatures, common patterns, and
+Zuplo Gateway. This guide covers the function signatures, common patterns, and
 best practices for writing custom code.
 
 ## Custom Inbound Policy

package/docs/articles/custom-domains.mdx

@@ -208,8 +208,8 @@ enabled. If you wish to upgrade to a higher TLS version, please contact
 
 <EnterpriseFeature name="Alias Domains" />
 
-Sometimes your API Gateway might be running behind another service such as a
-CDN, WAF or load balancer. In this case, your API Gateway's domain may not be
+Sometimes your Zuplo Gateway might be running behind another service such as a
+CDN, WAF or load balancer. In this case, your Zuplo Gateway's domain may not be
 the same as the domain your clients use to access your API. In this case, you
 can add an alias domain to your Zuplo project. An alias domain will configure
 your API and documentation to use the alias domain for any public facing URLs

package/docs/articles/development-options.mdx

@@ -8,9 +8,9 @@ flexible and fastest way to work with your Zuplo API and Developer Portal.
 
 ## Local Development
 
-The [local experience](./local-development.mdx) allows users to run both the API
-Gateway and Dev Portal locally. It also includes a local version of the Route
-Designer that's integrated into the Zuplo Portal (portal.zuplo.com). Local
+The [local experience](./local-development.mdx) allows users to run both the
+Zuplo Gateway and Dev Portal locally. It also includes a local version of the
+Route Designer that's integrated into the Zuplo Portal (portal.zuplo.com). Local
 development allows customers to use the IDE of their choice and run everything
 locally.
 
@@ -20,7 +20,7 @@ iterate on their APIs without needing to deploy to the cloud.
 
 Local development is the fastest way to develop and test your APIs as you can
 test changes immediately without waiting for a deployment. Changes to your API
-are automatically loaded into the local API Gateway and Dev Portal.
+are automatically loaded into the local Zuplo Gateway and Dev Portal.
 
 ## Web-Based Development Experience
 

package/docs/articles/fastly-zuplo-host-setup.mdx

@@ -8,7 +8,7 @@ necessary setup for most people as Zuplo already runs at the edge and can be
 used for CDN like caching. However, there are some scenarios where you may want
 to put Zuplo behind Fastly. For example, if you are using Fastly's
 [WAF or DDoS protection](./waf-ddos-fastly.mdx) and want to ensure that all
-traffic goes through Fastly before hitting your Zuplo API Gateway.
+traffic goes through Fastly before hitting your Zuplo Gateway.
 
 ## Configuring Zuplo as a Fastly Host
 
@@ -16,15 +16,15 @@ The following settings will allow you to run Zuplo as a host behind Fastly.
 
 ### Zuplo Configuration
 
-It's recommended that you use a custom domain for your Zuplo API Gateway. This
-will allow you to more configure your Fastly host as well as ensure that your
-domain is stable regardless of your Zuplo configuration.
+It's recommended that you use a custom domain for your Zuplo Gateway. This will
+allow you to more configure your Fastly host as well as ensure that your domain
+is stable regardless of your Zuplo configuration.
 
 ### Fastly Configuration
 
 1. Create a new Fastly CDN service or use an existing one.
 2. Create a new Origin and name it whatever you like.
-3. Set the **Address** to your Zuplo API Gateway domain. For example,
+3. Set the **Address** to your Zuplo Gateway domain. For example,
    `api.example.com` if using a custom domain, or
    `my-project-main-021839d.zuplo.app` without a custom domain.
 4. Enable TLS and keep the port as `443`.

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.