zuplo 7.3.2 → 7.4.3

package/docs/articles/policies.mdx

@@ -28,6 +28,6 @@ Explore the navigation to see all of the built-in policies.
 ## Custom Policies
 
 The ability to write custom policies that run in-process of your Gateway is at
-the core of what makes Zuplo the Programmable API Gateway. You can write
-policies to handle virtually any task. To learn more about
+the core of what makes Zuplo a programmable gateway for APIs, AI, and MCP. You
+can write policies to handle virtually any task. To learn more about
 [writing custom policies see the documentation](../policies/custom-code-inbound.mdx).

package/docs/articles/securing-backend-mtls.mdx

@@ -6,9 +6,9 @@ sidebar_label: Gateway to Origin
 <EnterpriseFeature name="mTLS Client Certificates" />
 
 Mutual TLS (mTLS) authentication establishes a trust relationship between your
-Zuplo API Gateway and your backend services using client certificates. With
-mTLS, both the client (Zuplo Gateway) and the server (your backend) authenticate
-each other, creating a "Zero Trust" security model.
+Zuplo Gateway and your backend services using client certificates. With mTLS,
+both the client (Zuplo Gateway) and the server (your backend) authenticate each
+other, creating a "Zero Trust" security model.
 
 This is particularly useful for enterprise customers who need to ensure that
 both parties in a connection verify each other's identity before exchanging

package/docs/articles/securing-the-gateway-with-client-mtls.mdx

@@ -17,9 +17,9 @@ Zuplo.
 
 :::note
 
-Client mTLS is enforced at the Zuplo **API gateway** only. It is not available
-on the Zuplo developer portal — the portal cannot require client certificates
-from visitors.
+Client mTLS is enforced at the Zuplo **gateway** only. It is not available on
+the Zuplo developer portal — the portal cannot require client certificates from
+visitors.
 
 :::
 

package/docs/articles/securing-your-backend.mdx

@@ -6,7 +6,7 @@ When using a gateway, it's important to ensure that your backend API is only
 receiving traffic via the gateway to be confident that your policies are being
 correctly applied to all traffic.
 
-![Zuplo as an API gateway](../../public/media/securing-your-backend/b7290dd1-43fa-49f8-8629-6b4899e2e9f3.png)
+![Zuplo as a gateway](../../public/media/securing-your-backend/b7290dd1-43fa-49f8-8629-6b4899e2e9f3.png)
 
 That means securing the communication between Zuplo and your backend API
 (origin). Several options do this, and the right one depends on where your

package/docs/articles/security.mdx

@@ -49,7 +49,7 @@ infrastructure remain secure.
   instead are connected to Cloudflare using outbound secure tunnels.
 - Each service that's exposed is protected by DDoS, Firewall, WAF, and other
   security measures.
-- Internal and external APIs are protected by Zuplo API Gateway.
+- Internal and external APIs are protected by Zuplo Gateway.
 - Internal services can only be connected to by Zuplo employees using an
   identity and device policy-enforced proxy using secure tunnels.
 - Interconnected Zuplo services utilize mTLS authentication or gateway

package/docs/articles/terraform.mdx

@@ -21,7 +21,7 @@ require you to:
 - Use tools like Terraform to bridge the gap between code and infrastructure
 - Handle complex state reconciliation and drift detection
 
-Zuplo eliminates this complexity entirely. Every aspect of your API gateway
+Zuplo eliminates this complexity entirely. Every aspect of your gateway
 configuration is stored as human-readable code and configuration files in your
 repository:
 
@@ -43,7 +43,7 @@ partial states, no drift, and no manual cleanup required.
 
 This atomic deployment model means:
 
-- **No half-deployed states**: Your API gateway is always in a known, consistent
+- **No half-deployed states**: Your gateway is always in a known, consistent
   state
 - **Simple rollbacks**: Just revert your Git commit and redeploy
 - **No state management**: Git is your single source of truth

package/docs/articles/testing.mdx

@@ -3,9 +3,9 @@ title: Testing Your API
 sidebar_label: Testing
 ---
 
-Zuplo provides multiple ways to test your API gateway at every stage of
-development. Whether you are iterating locally, reviewing a pull request in a
-preview environment, or gating production deployments in CI/CD, the
+Zuplo provides multiple ways to test your gateway at every stage of development.
+Whether you are iterating locally, reviewing a pull request in a preview
+environment, or gating production deployments in CI/CD, the
 [`zuplo test`](../cli/test.mdx) command and the `@zuplo/test` library give you a
 consistent testing experience.
 
@@ -32,7 +32,7 @@ suite against it.
 npx zuplo dev
 ```
 
-The API gateway starts on `http://localhost:9000` by default. You can change the
+The gateway starts on `http://localhost:9000` by default. You can change the
 port with the `--port` flag. See the [`zuplo dev` reference](../cli/dev.mdx) for
 all available options.
 
@@ -370,7 +370,7 @@ describe("Authentication", () => {
 
 ## Writing integration tests
 
-Integration tests verify that your API gateway behaves correctly end-to-end,
+Integration tests verify that your gateway behaves correctly end-to-end,
 including routing, policies, and backend connectivity. Because `zuplo test` runs
 against a live endpoint (local or deployed), every test is inherently an
 integration test.
@@ -451,7 +451,7 @@ describe("Request validation", () => {
 :::caution{title="Advanced"}
 
 Custom testing can be complicated and is best used only to test your own logic
-rather than trying to mock large portions of your API Gateway.
+rather than trying to mock large portions of your gateway.
 
 :::
 

package/docs/articles/troubleshooting-slow-responses.mdx

@@ -11,9 +11,9 @@ systematic approach helps you identify the root cause quickly. This guide walks
 you through diagnosing latency issues — whether the source is the gateway, your
 backend, the network, or something else entirely.
 
-## Understanding API Gateway Latency
+## Understanding Gateway Latency
 
-Every API gateway adds some processing overhead to requests. For Zuplo, this
+Every gateway adds some processing overhead to requests. For Zuplo, this
 overhead is minimal:
 
 - **Base latency**: Approximately 20–30ms with no policies enabled
@@ -90,9 +90,8 @@ testing services to confirm whether the slowness is location-specific.
 
 ### Backend Response Time
 
-The most common cause of slow responses through any API gateway is a slow
-backend. The gateway adds its processing time _on top of_ whatever the backend
-takes.
+The most common cause of slow responses through any gateway is a slow backend.
+The gateway adds its processing time _on top of_ whatever the backend takes.
 
 **How to identify**: Compare direct backend response times with gateway response
 times. If both are slow, the issue is the backend.
@@ -366,7 +365,7 @@ back-and-forth diagnostic questions.
 
 - [OpenTelemetry](./opentelemetry.mdx) — Distributed tracing and logging for
   detailed request lifecycle visibility
-- [Performance Testing Your API Gateway](./performance-testing.mdx) — How to
+- [Performance Testing Your Gateway](./performance-testing.mdx) — How to
   benchmark and compare gateway performance accurately
 - [Proactive Monitoring](./monitoring-your-gateway.mdx) — Setting up health
   checks and monitoring for your gateway

package/docs/articles/troubleshooting.md

@@ -4,7 +4,7 @@ sidebar_label: Troubleshooting
 ---
 
 This guide covers common errors you may encounter when building, deploying, and
-running your Zuplo API gateway, along with steps to diagnose and fix them.
+running your Zuplo Gateway, along with steps to diagnose and fix them.
 
 ## Build errors
 

package/docs/articles/use-openapi-extension-data.mdx

@@ -3,7 +3,7 @@ title: Using the OpenAPI Extension Data in Code
 sidebar_label: "OpenAPI Extension Data"
 description:
   Learn how to add custom vendor-specific extensions to OpenAPI files and access
-  that data in your Zuplo API Gateway code.
+  that data in your Zuplo Gateway code.
 tags:
   - openapi
   - custom-code
@@ -15,9 +15,9 @@ add custom configuration to the API definition. An example of this is the
 intended for public use.
 
 This same type of extensibility can be used to add custom data to the OpenAPI
-file which can then be used inside of your Zuplo API Gateway. This data can be
-used to configure the behavior of the API Gateway, such as setting up rate
-limiting, authentication, or other custom behavior.
+file which can then be used inside of your Zuplo Gateway. This data can be used
+to configure the behavior of the gateway, such as setting up rate limiting,
+authentication, or other custom behavior.
 
 In this article, we will show you how to use the OpenAPI extension data in your
 code.

package/docs/articles/waf-ddos-akamai.md

@@ -9,20 +9,20 @@ configured to run as a custom origin behind Akamai.
 ## Securing Zuplo from Direct Access
 
 With any WAF product, you will want to ensure that network traffic can't bypass
-your WAF and hit your API Gateway directly. Akamai offers several ways to ensure
-that your API Gateway is only accessible through the WAF.
+your WAF and hit your Zuplo Gateway directly. Akamai offers several ways to
+ensure that your gateway is only accessible through the WAF.
 
 The information below is a summary of Akamai's own recommendations for securing
-your backend - regardless of whether you are using Zuplo, another API Gateway,
-or Akamai origins. You can reference the
+your backend - regardless of whether you are using Zuplo, another gateway, or
+Akamai origins. You can reference the
 [Akamai documentation](https://techdocs.akamai.com/application-security/docs/origin-server-protection).
 
 ### IP Address Restrictions
 
 Akamai maintains a list of IP addresses that you can use to restrict access to
-your API Gateway. This is a good way to ensure that only Akamai can access your
-API Gateway. However, as Akamai is a multi-tenant service, this method isn't
-sufficient to protect unauthorized traffic from hitting your API Gateway.
+your Zuplo Gateway. This is a good way to ensure that only Akamai can access
+your gateway. However, as Akamai is a multi-tenant service, this method isn't
+sufficient to protect unauthorized traffic from hitting your gateway.
 
 In Zuplo, you can use a
 [custom code policy](../policies/custom-code-inbound.mdx) to limit traffic to
@@ -46,15 +46,15 @@ in Akamai Control Center.
 ```
 
 With this policy in place, only Akamai traffic will be allowed to hit your Zuplo
-API Gateway.
+Gateway.
 
 ### Custom Headers
 
 Another way to ensure that traffic is coming from Akamai is to use custom
 headers. Custom headers can be added to your Akamai configuration and then
-checked by your API Gateway. This provides an additional layer of security on
+checked by your Zuplo Gateway. This provides an additional layer of security on
 top of IP address restrictions and prevents any unauthorized traffic from
-hitting your API Gateway - regardless of the source.
+hitting your gateway - regardless of the source.
 
 In Akamai, you can configure custom headers using the Property Manager or the
 Akamai API. Add a custom header with a secret value that only you and Akamai
@@ -95,7 +95,7 @@ export default async function policy(
 ```
 
 With this policy in place, only requests that include the custom header with the
-secret value will be allowed to hit your Zuplo API Gateway.
+secret value will be allowed to hit your Zuplo Gateway.
 
 ## Additional Akamai Origin Security Options
 
@@ -148,5 +148,5 @@ Learn more:
 [Modify Incoming Request Header](https://techdocs.akamai.com/property-mgr/docs/modify-incoming-req-header)
 
 These security measures can be used individually or combined to create multiple
-layers of protection for your Zuplo API Gateway when running behind Akamai App &
-API Protector.
+layers of protection for your Zuplo Gateway when running behind Akamai App & API
+Protector.

package/docs/articles/waf-ddos-aws-waf-shield.mdx

@@ -9,22 +9,22 @@ to run as a custom backend behind CloudFront.
 ## Securing Zuplo from Direct Access
 
 With any WAF product, you will want to ensure that network traffic can't bypass
-your WAF and hit your API Gateway directly. AWS WAF + Shield offer several ways
-to ensure that your API Gateway is only accessible through the WAF.
+your WAF and hit your Zuplo Gateway directly. AWS WAF + Shield offer several
+ways to ensure that your gateway is only accessible through the WAF.
 
 The information below is a summary of Amazon's own recommendations for securing
-your backend - regardless of whether you are using Zuplo, another API Gateway,
-or AWS origins. You can also reference
+your backend - regardless of whether you are using Zuplo, another gateway, or
+AWS origins. You can also reference
 [the AWS documentation](https://docs.aws.amazon.com/whitepapers/latest/secure-content-delivery-amazon-cloudfront/custom-origin-with-cloudfront.html)
 directly.
 
 ### IP Address Restrictions
 
 Amazon maintains a list of CloudFront IP addresses (separate from other AWS
-uses) that you can use to restrict access to your API Gateway. This is a good
-way to ensure that only CloudFront can access your API Gateway. However, as
+uses) that you can use to restrict access to your Zuplo Gateway. This is a good
+way to ensure that only CloudFront can access your gateway. However, as
 CloudFront is available to any AWS customer, this method isn't sufficient to
-protect unauthorized traffic from hitting your API Gateway.
+protect unauthorized traffic from hitting your gateway.
 
 In Zuplo, you can use a
 [custom code policy](../policies/custom-code-inbound.mdx) to limit traffic to
@@ -48,15 +48,15 @@ configure the policy with the `CLOUDFRONT` ranges from the
 ```
 
 With this policy in place, only CloudFront traffic will be allowed to hit your
-Zuplo API Gateway.
+Zuplo Gateway.
 
 ### Custom Headers
 
 Another way to ensure that traffic is coming from CloudFront is to use custom
 headers. Custom headers can be added to your CloudFront distribution and then
-checked by your API Gateway. This provides an additional layer of security on
+checked by your Zuplo Gateway. This provides an additional layer of security on
 top of IP address restrictions and prevents any unauthorized traffic from
-hitting your API Gateway - regardless of the source.
+hitting your gateway - regardless of the source.
 
 In Zuplo, you can use a small custom code policy to limit traffic to only those
 requests that include the custom header and secret value.
@@ -93,12 +93,12 @@ export default async function policy(
 ```
 
 With this policy in place, only requests that include the custom header with the
-secret value will be allowed to hit your Zuplo API Gateway.
+secret value will be allowed to hit your Zuplo Gateway.
 
 ### Identity Based Options
 
 Unfortunately, AWS WAF + Shield don't offer identity-based options like IAM or
-network based options for securing your API Gateway. This is true for
+network based options for securing your Zuplo Gateway. This is true for
 [both AWS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html)
-and non-AWS API Gateway products. If you require these options, you will need to
-use a different WAF product in front of your Zuplo API Gateway.
+and non-AWS gateway products. If you require these options, you will need to use
+a different WAF product in front of your Zuplo Gateway.

package/docs/articles/waf-ddos-fastly.mdx

@@ -12,20 +12,20 @@ Refer to Zuplo's documentation on
 ## Securing Zuplo from Direct Access
 
 With any WAF product, you will want to ensure that network traffic can't bypass
-your WAF and hit your API Gateway directly. Fastly offers several ways to ensure
-that your API Gateway is only accessible through the WAF.
+your WAF and hit your Zuplo Gateway directly. Fastly offers several ways to
+ensure that your gateway is only accessible through the WAF.
 
 The information below is a summary of Fastly's own recommendations for securing
-your backend - regardless of whether you are using Zuplo, another API Gateway,
-or Fastly origins. You can reference the
+your backend - regardless of whether you are using Zuplo, another gateway, or
+Fastly origins. You can reference the
 [Fastly documentation](https://www.fastly.com/documentation/guides/integrations/non-fastly-services/developer-guide-backends/).
 
 ### IP Address Restrictions
 
 Fastly maintains a list of IP addresses that you can use to restrict access to
-your API Gateway. This is a good way to ensure that only Fastly can access your
-API Gateway. However, as Fastly is a multi-tenant service, this method isn't
-sufficient to protect unauthorized traffic from hitting your API Gateway.
+your Zuplo Gateway. This is a good way to ensure that only Fastly can access
+your gateway. However, as Fastly is a multi-tenant service, this method isn't
+sufficient to protect unauthorized traffic from hitting your gateway.
 
 In Zuplo, you can use a
 [custom code policy](../policies/custom-code-inbound.mdx) to limit traffic to
@@ -49,16 +49,16 @@ configure the policy with the address ranges from
 ```
 
 With this policy in place, only Fastly traffic will be allowed to hit your Zuplo
-API Gateway.
+Gateway.
 
 ### Signed Headers
 
 Another way to ensure that traffic is coming from Fastly is to use signed
 headers. Signed headers can be added using a
 [VLC Snippet](https://docs.fastly.com/en/guides/about-vcl-snippets) and then
-checked by your API Gateway. This provides an additional layer of security on
+checked by your Zuplo Gateway. This provides an additional layer of security on
 top of IP address restrictions and prevents any unauthorized traffic from
-hitting your API Gateway - regardless of the source.
+hitting your gateway - regardless of the source.
 
 In Fastly, you will need to create a VCL snippet that adds a signed header as
 shown below. This example uses the `shared_secret` value stored in an
@@ -179,16 +179,16 @@ export default async function (
 ```
 
 With this policy in place, only requests that include a valid sign header will
-be allowed to hit your Zuplo API Gateway.
+be allowed to hit your Zuplo Gateway.
 
 ### JWT Header
 
 Another way to ensure that traffic is coming from Fastly is to add a JWT header
 to the outgoing request. JWT headers can be added using a
 [VLC Snippet](https://docs.fastly.com/en/guides/about-vcl-snippets) and then
-checked by your API Gateway. This provides an additional layer of security on
+checked by your Zuplo Gateway. This provides an additional layer of security on
 top of IP address restrictions and prevents any unauthorized traffic from
-hitting your API Gateway - regardless of the source.
+hitting your gateway - regardless of the source.
 
 :::tip
 
@@ -247,7 +247,7 @@ To verify the JWT header in Zuplo, you can utilize the JWT Auth Inbound policy.
 ### mTLS Authentication
 
 Fastly supports mTLS authentication for backend services. This is a good way to
-ensure that only Fastly can access your API Gateway. For documentation on
+ensure that only Fastly can access your Zuplo Gateway. For documentation on
 configuring Fastly with mTLS, see the
 [Fastly documentation](https://docs.fastly.com/en/guides/working-with-hosts#advanced-tls-options).
 To configure Zuplo to accept mTLS connections, see the

package/docs/articles/waf-ddos.mdx

@@ -2,8 +2,8 @@
 title: Zuplo + WAF/DDoS Services
 ---
 
-Many customers using Zuplo (or any other API Gateway) often choose to deploy WAF
-and DDoS protection in front of their gateway. You can use any WAF - we have
+Many customers using Zuplo (or any other gateway) often choose to deploy WAF and
+DDoS protection in front of their gateway. You can use any WAF - we have
 customers today using Azure, AWS, Akamai, CloudFlare and many other options.
 
 However, there are some things to consider depending on how you host Zuplo
@@ -56,7 +56,7 @@ Akamai's App & API Protector provides comprehensive WAF and DDoS protection with
 a global edge network. Akamai offers advanced bot management, API security, and
 DDoS mitigation that works well with Zuplo's edge-deployed architecture. With
 over 4,000 edge locations worldwide, Akamai ensures minimal latency when
-protecting your Zuplo API Gateway.
+protecting your Zuplo Gateway.
 
 Key features include:
 
@@ -74,14 +74,14 @@ your users, maintaining the low-latency benefits of Zuplo's edge deployment.
 ### Cloudflare WAF + DDoS
 
 Cloudflare is the easiest solution for custom WAF + DDoS in front of your Zuplo
-API Gateway deployed as managed-edge. Because managed-edge is already terminated
+Gateway deployed as managed-edge. Because managed-edge is already terminated
 with Cloudflare, the integration is seamless and requires virtually zero
 configuration. Simply point your Cloudflare managed domain to Zuplo and you are
 protected. You can fully customize your WAF, firewall, DDoS or any other
 security configuration offered by Cloudflare. When a request comes into
 Cloudflare, it will be routed first through your account's configuration, then
-will be sent to your Zuplo API Gateway. The same thing happens on the outbound
-as well.
+will be sent to your Zuplo Gateway. The same thing happens on the outbound as
+well.
 
 A custom domain configured on Zuplo that utilizes Cloudflare DNS is completely
 protected from requests bypassing your WAF and hitting Zuplo directly.
@@ -106,7 +106,7 @@ the two products together.
 
 AWS offers DDoS (Shield) and WAF products that run at CloudFront edge locations.
 This is another good option for edge-based WAF/DDoS protection in front of your
-Zuplo API Gateway. AWS CloudFront is also in hundreds of edge locations that are
+Zuplo Gateway. AWS CloudFront is also in hundreds of edge locations that are
 very close to Cloudflare locations (again, this isn't something either company
 discloses, but we suspect there is significant overlap in the physical locations
 used by AWS and Cloudflare).

package/docs/cli/authentication.mdx

@@ -43,7 +43,7 @@ following these steps:
    the CLI.
 
 Most commands take an `--api-key` argument. For example, to list your available
-Zuplo API Gateways, run:
+Zuplo Gateways, run:
 
 ```bash
 zuplo list --api-key zpka_d67b7e241bb948758f415b79aa8exxxx_2efbxxxx

package/docs/cli/lint.mdx

@@ -0,0 +1,103 @@
+---
+title: "Zuplo CLI: Lint"
+sidebar_label: lint
+---
+
+<CliCommand
+  command="lint"
+  description="Lints your OpenAPI specs and policies for errors and Zuplo conventions"
+  options={[
+  {
+    "name": "dir",
+    "type": "string",
+    "description": "The directory containing your Zuplo API",
+    "default": ".",
+    "required": false,
+    "deprecated": false,
+    "hidden": false,
+    "normalize": true
+  },
+  {
+    "name": "config",
+    "type": "string",
+    "description": "Path to a lint config file. Defaults to zuplo.lint.jsonc or zuplo.lint.json in the project directory.",
+    "required": false,
+    "deprecated": false,
+    "hidden": false,
+    "normalize": true
+  },
+  {
+    "name": "format",
+    "type": "string",
+    "description": "Output format",
+    "default": "text",
+    "required": false,
+    "deprecated": false,
+    "hidden": false,
+    "choices": [
+      "text",
+      "json",
+      "sarif"
+    ]
+  },
+  {
+    "name": "fail-on",
+    "type": "string",
+    "description": "Severity threshold that fails the command. Defaults to the failOn value in your lint config, or 'error'.",
+    "required": false,
+    "deprecated": false,
+    "hidden": false,
+    "choices": [
+      "error",
+      "warn",
+      "none"
+    ]
+  },
+  {
+    "name": "lint-binary",
+    "type": "string",
+    "description": "Path to a zuplo-lint executable to use instead of the one installed with the CLI",
+    "required": false,
+    "deprecated": false,
+    "hidden": true,
+    "normalize": true
+  },
+  {
+    "name": "fix",
+    "type": "boolean",
+    "description": "Rewrite your OpenAPI files to fix what can be fixed automatically, then report what is left",
+    "default": false,
+    "required": false,
+    "deprecated": false,
+    "hidden": false
+  }
+]}
+  examples={[
+  [
+    "$0 lint",
+    "Lint the project in the current directory"
+  ],
+  [
+    "$0 lint --fix",
+    "Apply the fixes that can be made automatically"
+  ],
+  [
+    "$0 lint --fail-on warn",
+    "Fail the command on warnings as well as errors"
+  ],
+  [
+    "$0 lint --format sarif > results.sarif",
+    "Emit SARIF for GitHub Code Scanning"
+  ]
+]}
+  usage="$0 lint [options]"
+>
+
+</CliCommand>
+
+## Global options
+
+The following global options are available for all commands:
+
+- [`--help`](./global-options.mdx#help)
+- [`--api-key`](./global-options.mdx#api-key)

package/docs/concepts/how-zuplo-works.mdx

@@ -2,8 +2,9 @@
 title: How Zuplo Works
 ---
 
-Zuplo is a programmable API gateway that runs at the edge. This page explains
-the architecture, runtime, and deployment model.
+Zuplo is the unified gateway for APIs, AI, and MCP — one programmable policy
+engine that runs at the edge. This page explains the architecture, runtime, and
+deployment model.
 
 ## Architecture
 
@@ -14,7 +15,7 @@ policies before reaching the client.
 
 <Diagram height="h-96">
   <DiagramNode id="clients">Clients</DiagramNode>
-  <DiagramGroup id="zuplo" label="Zuplo API Gateway">
+  <DiagramGroup id="zuplo" label="Zuplo Gateway">
     <DiagramNode id="inbound" variant="zuplo">
       Inbound Policies
     </DiagramNode>
@@ -102,7 +103,7 @@ HTTP-based protocols. HTTP/2 is fully supported.
 
 ## Programmability
 
-While most API gateways limit you to configuration, Zuplo lets you write custom
+While most gateways limit you to configuration, Zuplo lets you write custom
 logic that runs in-process at the gateway layer:
 
 - **[Custom policies](../policies/custom-code-inbound.mdx)** - intercept

package/docs/concepts/upstream-credentials.mdx

@@ -20,7 +20,7 @@ the caller's identity is known and before the request leaves for the origin.
 
 <Diagram height="h-96">
   <DiagramNode id="caller">Caller</DiagramNode>
-  <DiagramGroup id="zuplo" label="Zuplo API Gateway">
+  <DiagramGroup id="zuplo" label="Zuplo Gateway">
     <DiagramNode id="verify" variant="zuplo">
       Verify caller credential
     </DiagramNode>