zuplo 7.4.1 → 7.4.4

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>

package/docs/dedicated/akamai/architecture.mdx

@@ -2,8 +2,7 @@
 title: Akamai Dedicated Architecture
 sidebar_label: Architecture
 description:
-  Architecture overview for Zuplo API Gateway deployments on Akamai Connected
-  Cloud.
+  Architecture overview for Zuplo Gateway deployments on Akamai Connected Cloud.
 ---
 
 Zuplo integrates with Akamai Connected Cloud to provide a secure, highly
@@ -20,11 +19,11 @@ components:
    handles incoming client requests, providing caching, DDoS protection, and
    edge security.
 2. **Akamai Global Traffic Manager (GTM)** - Routes traffic to the appropriate
-   Zuplo API Gateway instances based on geographic location, health status, and
-   load balancing policies.
-3. **Zuplo API Gateway** - Deployed on Akamai Connected Cloud, the gateway
-   handles authentication, authorization, rate limiting, and request routing.
-   Origin IP ACL ensures only Akamai edge servers can reach the gateway.
+   Zuplo Gateway instances based on geographic location, health status, and load
+   balancing policies.
+3. **Zuplo Gateway** - Deployed on Akamai Connected Cloud, the gateway handles
+   authentication, authorization, rate limiting, and request routing. Origin IP
+   ACL ensures only Akamai edge servers can reach the gateway.
 4. **Backend Services** - Your origin servers can be hosted on Akamai compute,
    customer VPCs, on-premise data centers, or public cloud providers.
 
@@ -48,7 +47,7 @@ to Zuplo and your backend services:
   </DiagramGroup>
   <DiagramGroup id="akamai-cloud" label="Akamai Connected Cloud">
     <DiagramNode id="gateway" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
   </DiagramGroup>
   <DiagramGroup id="backends" label="Backend Services">
@@ -67,9 +66,9 @@ to Zuplo and your backend services:
 2. **CDN to GTM** - The edge server forwards the request to Akamai Global
    Traffic Manager, which determines the optimal Zuplo instance to handle the
    request.
-3. **GTM to Zuplo** - GTM routes the request to a Zuplo API Gateway. Origin IP
-   ACL ensures only traffic from Akamai's edge network reaches the gateway.
-4. **Zuplo to Backend** - The Zuplo API Gateway processes the request (applying
+3. **GTM to Zuplo** - GTM routes the request to a Zuplo Gateway. Origin IP ACL
+   ensures only traffic from Akamai's edge network reaches the gateway.
+4. **Zuplo to Backend** - The Zuplo Gateway processes the request (applying
    policies, authentication, rate limiting) and forwards it to your backend
    services.
 
@@ -94,7 +93,7 @@ providing seamless failover.
 
 ### Secure connectivity with Origin IP ACL
 
-The connection between Akamai edge servers and Zuplo API Gateways uses
+The connection between Akamai edge servers and Zuplo Gateways uses
 [Origin IP ACL](https://techdocs.akamai.com/origin-ip-acl/docs/welcome) to
 restrict access to the gateway. Origin IP ACL ensures that only requests from
 Akamai's edge network can reach your Zuplo origin. This provides:
@@ -112,9 +111,9 @@ connect to your gateway.
 
 ## Multi-region deployment
 
-Deploy your Zuplo API Gateway to multiple regions on Akamai Connected Cloud for
-high availability, lower latency, and disaster recovery. GTM intelligently
-routes traffic to the closest healthy region.
+Deploy your Zuplo Gateway to multiple regions on Akamai Connected Cloud for high
+availability, lower latency, and disaster recovery. GTM intelligently routes
+traffic to the closest healthy region.
 
 <Diagram height="h-[500px]" direction="vertical">
   <DiagramNode id="client">Client</DiagramNode>
@@ -128,7 +127,7 @@ routes traffic to the closest healthy region.
   </DiagramGroup>
   <DiagramGroup id="region1" label="Akamai Cloud - Region 1">
     <DiagramNode id="gateway1" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
     <DiagramNode id="backend1" variant="green">
       Backend (Region 1)
@@ -136,7 +135,7 @@ routes traffic to the closest healthy region.
   </DiagramGroup>
   <DiagramGroup id="region2" label="Akamai Cloud - Region 2">
     <DiagramNode id="gateway2" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
     <DiagramNode id="backend2" variant="green">
       Backend (Region 2)
@@ -144,7 +143,7 @@ routes traffic to the closest healthy region.
   </DiagramGroup>
   <DiagramGroup id="region3" label="Akamai Cloud - Region 3">
     <DiagramNode id="gateway3" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
     <DiagramNode id="backend3" variant="green">
       Backend (Region 3)
@@ -181,15 +180,15 @@ Configure GTM properties with appropriate settings:
 
 ## Backend connectivity
 
-Zuplo API Gateway supports multiple methods for securing connections to your
-backend services. Most authentication methods work regardless of where your
-backend is hosted, giving you flexibility to choose the approach that best fits
-your security requirements.
+Zuplo Gateway supports multiple methods for securing connections to your backend
+services. Most authentication methods work regardless of where your backend is
+hosted, giving you flexibility to choose the approach that best fits your
+security requirements.
 
 <Diagram height="h-[300px]" direction="vertical">
   <DiagramGroup id="akamai-cloud" label="Akamai Connected Cloud">
     <DiagramNode id="gateway" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
   </DiagramGroup>
   <DiagramGroup id="akamai-compute" label="Akamai Compute">
@@ -265,7 +264,7 @@ Consider these factors when selecting an authentication method:
 For detailed instructions on configuring Akamai CDN properties for your Zuplo
 deployment, see [Setting up Akamai CDNs](./cdn.mdx). This guide covers:
 
-- Property hostname configuration for API gateway and developer portal
+- Property hostname configuration for Zuplo Gateway and developer portal
 - Origin server settings with host header forwarding
 - Origin IP ACL configuration for secure edge-to-origin connectivity
 - Caching behaviors for API responses

package/docs/dedicated/akamai/cdn.mdx

@@ -9,7 +9,7 @@ When running managed dedicated on the Akamai Cloud, you need to set up 2 CDNs,
 one for your API endpoint deployments, and one for your developer portal.
 
 This document outlines the configurations you need to add to your Akamai CDNs to
-set them up to access your API gateway and developer portal.
+set them up to access your Zuplo Gateway and developer portal.
 
 All configurations in this guide were done on the Akamai Property Manager, see
 the
@@ -18,14 +18,14 @@ for more details.
 
 ### Domains
 
-Before you configure the CDN for your API Gateway and Developer Portal, you will
-to decide how you would like your domains to be set up. Generally, you will
+Before you configure the CDN for your Zuplo Gateway and Developer Portal, you
+will to decide how you would like your domains to be set up. Generally, you will
 provision two types of domains - a static domain for production and wildcard
 domains for preview environments.
 
 For preview environments, you will use wildcard domains so that each environment
 (normally each git branch) will have its own subdomain. For example, you might
-use `*.api.example.com` for the API gateway and `*.dev.example.com` for the
+use `*.api.example.com` for the Zuplo Gateway and `*.dev.example.com` for the
 developer portal. This will allow you to have URLs for each environment like
 `https://my-environment-123.api.example.com` and
 `https://my-environment-123.dev.example.com`.
@@ -42,20 +42,20 @@ certificates will be different.
 
 1. Provision the domains that you would like these CDNs to have and certificates
    for those domains, according to the domain section.
-2. Request the Origin URLs for your API gateway and developer portal from your
+2. Request the Origin URLs for your Zuplo Gateway and developer portal from your
    Zuplo account manager.
 3. Let your Zuplo account manager know what hostnames/domains you will be using
    in your CDNs.
 
-## API Gateway CDN
+## Zuplo Gateway CDN
 
-This section guides you on how to configure your API Gateway CDN.
+This section guides you on how to configure your Zuplo Gateway CDN.
 
-Add the API gateway domain you provisioned to the Property Hostname for the API
-Gateway CDN. See the Akamai docs on
+Add the Zuplo Gateway domain you provisioned to the Property Hostname for the
+Zuplo Gateway CDN. See the Akamai docs on
 [configuring HTTPS host names](https://techdocs.akamai.com/property-mgr/docs/serve-content-over-https).
 
-An example of how you might configure your API Gateway CDN domains for your
+An example of how you might configure your Zuplo Gateway CDN domains for your
 preview environment and your production environment is below. Note that for your
 development environment CDN, you would need the wildcard domain since many
 development environments are named things like
@@ -95,10 +95,10 @@ After configuring the CDN domains, make the following behavior changes:
    ![Set variable behavior](../../../public/media/managed-dedicated-akamai/regex-behaviour.png)
 
 2. Configure the Origin URL to point to the URL given to you by Zuplo for your
-   API gateway. Ensure that the Forward Host Header is configured to be a Custom
-   Value, and the value should be the variable you created in the previous step.
-   This would look something similar to below:
-   ![API gateway origin URL](../../../public/media/managed-dedicated-akamai/api_gateway_origin_url.png)
+   Zuplo Gateway. Ensure that the Forward Host Header is configured to be a
+   Custom Value, and the value should be the variable you created in the
+   previous step. This would look something similar to below:
+   ![Zuplo Gateway origin URL](../../../public/media/managed-dedicated-akamai/api_gateway_origin_url.png)
 
 3. Turn on Content Targeting (Edgescape) in the Geolocation rule in the Property
    Manager Sidebar.
@@ -111,10 +111,10 @@ After configuring the CDN domains, make the following behavior changes:
 This section guides you on how to set up the Developer Portal CDN.
 
 Add the Developer Portal gateway domain you provisioned to the Property Hostname
-for the API Gateway CDN. See the Akamai docs on
+for the Zuplo Gateway CDN. See the Akamai docs on
 [configuring HTTPS host names](https://techdocs.akamai.com/property-mgr/docs/serve-content-over-https).
-This is done similarly to your API gateway CDN hostname configuration, but with
-the domains you provisioned for your Developer Portal.
+This is done similarly to your Zuplo Gateway CDN hostname configuration, but
+with the domains you provisioned for your Developer Portal.
 
 An example of how you might configure your Developer Portal CDN domains for your
 preview environment and your production environment is below.
@@ -128,7 +128,7 @@ Under the Default Rule page, add the following behaviors:
 
 1.  Configure the origin URL to be the URL given to be the one given to you by
     Zuplo for your Developer Portal. This will look similarly to how you
-    configured it for your API Gateway CDN. Take note that the Forward Host
+    configured it for your Zuplo Gateway CDN. Take note that the Forward Host
     header should also be set as the Origin Hostname.
 
 2.  Modify Incoming Request Header behavior, with the following fields:
@@ -149,8 +149,8 @@ Under the Default Rule page, add the following behaviors:
 
     ![Dev portal caching behavior](../../../public/media/managed-dedicated-akamai/dev_portal_cdn_caching_behavior.png)
 
-Congratulations, you've set up your Akamai CDN to serve your API Gateway and
+Congratulations, you've set up your Akamai CDN to serve your Zuplo Gateway and
 Developer Portal! At this point, you should be able to test that these things
-are working by either hitting an endpoint in your API gateway (e.g.,
+are working by either hitting an endpoint in your Zuplo Gateway (e.g.,
 mygateway.com/my/endpoint), or navigating to a page in your developer portal
 (e.g., myportal.com/home).

package/docs/dedicated/architecture.mdx

@@ -4,27 +4,27 @@ sidebar_label: Architecture
 ---
 
 Zuplo's managed dedicated instances are highly available, scalable, and secure.
-With a managed dedicated instance of Zuplo, your API Gateway runs on isolated
+With a managed dedicated instance of Zuplo, your Zuplo Gateway runs on isolated
 instances and, when running on a cloud provider that supports it, a dedicated
 network environment. This document outlines the components and architecture of a
-managed dedicated instance of a Zuplo API Gateway.
+managed dedicated instance of a Zuplo Gateway.
 
 ## Components
 
 A managed dedicated instance of Zuplo consists of the following components:
 
-- **API Gateway**: The API Gateway is the core component of Zuplo. It receives
-  incoming requests, routes them to the appropriate backend, and returns the
-  response to the client. The API Gateway handles authentication, authorization,
-  rate limiting, and other features.
-- **Gateway Services**: Zuplo, being a highly distributed API Gateway, uses
-  services to facilitate features such as
+- **Zuplo Gateway**: The Zuplo Gateway is the core component of Zuplo. It
+  receives incoming requests, routes them to the appropriate backend, and
+  returns the response to the client. The gateway handles authentication,
+  authorization, rate limiting, and other features.
+- **Gateway Services**: Zuplo, being a highly distributed gateway, uses services
+  to facilitate features such as
   [Rate Limiting](../articles/step-2-add-rate-limiting.mdx) and
   [API Key Authentication](../articles/api-key-management.mdx).
-- **Control Plane**: The Control Plane manages the configuration of the API
-  Gateway. It deploys new configurations, manages the lifecycle of the API
+- **Control Plane**: The Control Plane manages the configuration of the Zuplo
+  Gateway. It deploys new configurations, manages the lifecycle of the Zuplo
   Gateway, and monitors its health.
-- **Analytics and Logging**: Zuplo provides analytics and logging for your API
+- **Analytics and Logging**: Zuplo provides analytics and logging for your Zuplo
   Gateway. This includes request/response logging, error logging, and analytics
   on request volume, latency, and other metrics.
 - **Developer Portal**: The Developer Portal is a web-based interface that
@@ -51,7 +51,7 @@ requirements. Examples include:
   can disable the built-in analytics. When disabled, Zuplo stops collecting or
   storing analytics data for the APIs.
 - **Custom Logging & Monitoring** - Zuplo can integrate with your existing
-  logging and monitoring systems. Logs and other data go directly from the API
+  logging and monitoring systems. Logs and other data go directly from the Zuplo
   Gateway to your logging provider. Zuplo doesn't collect or store this data.
 
 ## Security
@@ -62,11 +62,12 @@ for you to customize the networking and connectivity to meet your specific
 security requirements.
 
 - **IAM Authorization**: Managed dedicated instances of Zuplo can use the IAM
-  capabilities to control traffic between the API Gateway and other services.
+  capabilities to control traffic between the Zuplo Gateway and other services.
 - **Encryption**: Zuplo encrypts data both in transit and at rest. TLS secures
-  all data sent to or from the API Gateway. Zuplo encrypts stored data at rest.
+  all data sent to or from the Zuplo Gateway. Zuplo encrypts stored data at
+  rest.
 - **Access Control**: Zuplo provides robust authentication and access control
-  mechanisms. You control who has access to your API Gateway management
+  mechanisms. You control who has access to your Zuplo Gateway management
   capabilities, what they can do, and what data they can access.
 - **Audit Logs**: Zuplo provides detailed audit logs of all management
   operations. You can see who did what, when they did it, and what data they
@@ -86,7 +87,7 @@ instance of Zuplo and how the components interact with each other.
   <DiagramNode id="client">Client</DiagramNode>
   <DiagramGroup id="dedicated-vpc" label="Dedicated Network">
     <DiagramNode id="gateway" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
     <DiagramNode id="services" variant="zuplo">
       Gateway Services
@@ -108,7 +109,7 @@ instance of Zuplo and how the components interact with each other.
 
 When you deploy to your managed dedicated instance of Zuplo, you upload your
 source code and configuration files to the Control Plane. The Control Plane then
-deploys your API Gateway to the appropriate infrastructure. The API Gateway
+deploys your Zuplo Gateway to the appropriate infrastructure. The Zuplo Gateway
 deploys to multiple nodes in multiple regions to provide high availability and
 low latency. If you run in multiple regions, the Control Plane manages the
 deployment to each region without any downtime.
@@ -124,7 +125,7 @@ customized to meet your specific requirements.
     Control Plane
   </DiagramNode>
   <DiagramNode id="gateway" variant="zuplo">
-    Zuplo API Gateway
+    Zuplo Gateway
   </DiagramNode>
   <DiagramNode id="portal" variant="zuplo">
     Dev Portal
@@ -136,12 +137,12 @@ customized to meet your specific requirements.
 
 ### Multiple regions
 
-It's common practice to deploy your API Gateway to multiple regions to provide
+It's common practice to deploy your Zuplo Gateway to multiple regions to provide
 higher availability, lower latency, and meet regulatory requirements. Zuplo can
-deploy your API Gateway to multiple regions and manage the deployment to each
+deploy your Zuplo Gateway to multiple regions and manage the deployment to each
 region without any downtime.
 
-When you deploy your API Gateway to multiple regions, Zuplo uses a global load
+When you deploy your Zuplo Gateway to multiple regions, Zuplo uses a global load
 balancer to route traffic to the closest region. This provides low latency
 access to your APIs for end-users around the world. The load balancer also
 handles failover in case of an outage in one region.
@@ -150,13 +151,13 @@ handles failover in case of an outage in one region.
   <DiagramNode id="client">Client</DiagramNode>
   <DiagramNode id="lb">Load Balancer</DiagramNode>
   <DiagramNode id="region1" variant="zuplo">
-    API Gateway (Region 1)
+    Zuplo Gateway (Region 1)
   </DiagramNode>
   <DiagramNode id="region2" variant="zuplo">
-    API Gateway (Region 2)
+    Zuplo Gateway (Region 2)
   </DiagramNode>
   <DiagramNode id="region3" variant="zuplo">
-    API Gateway (Region 3)
+    Zuplo Gateway (Region 3)
   </DiagramNode>
   <DiagramEdge from="client" to="lb" />
   <DiagramEdge from="lb" to="region1" />
@@ -169,7 +170,7 @@ handles failover in case of an outage in one region.
 Customers running managed dedicated Zuplo typically have multiple instances of
 Zuplo deployed. The most common case is to have a production instance and a
 non-production instance. The non-production instance is used to deploy and test
-changes to your API Gateway before deploying them to production. Each instance
+changes to your Zuplo Gateway before deploying them to production. Each instance
 can run many different deployments. A typical setup, the production instance
 hosts only the production deployment, while the non-production instance hosts
 many other deployments (for example staging, development, QA, or any feature
@@ -197,10 +198,10 @@ customizable.
     Control Plane
   </DiagramNode>
   <DiagramNode id="prod" variant="zuplo">
-    API Gateway (Production)
+    Zuplo Gateway (Production)
   </DiagramNode>
   <DiagramNode id="non-prod" variant="zuplo">
-    API Gateway (Non-Production)
+    Zuplo Gateway (Non-Production)
   </DiagramNode>
   <DiagramEdge from="source" to="control" label="Deploy" />
   <DiagramEdge from="control" to="prod" />

package/docs/dedicated/custom-domains.mdx

@@ -6,10 +6,9 @@ sidebar_label: Custom Domains
 Configuration of custom domains with your managed dedicated instance of Zuplo
 varies depending on how your
 [instance networking is configured](./networking.mdx). For customers using their
-Zuplo API Gateway as the ingress the bulk of the configuration is managed by
-Zuplo. You will be provided an IP address or CNAME to point your DNS to.
-Normally, Zuplo manages the SSL certificates in this type of configuration as
-well.
+Zuplo Gateway as the ingress the bulk of the configuration is managed by Zuplo.
+You will be provided an IP address or CNAME to point your DNS to. Normally,
+Zuplo manages the SSL certificates in this type of configuration as well.
 
 Custom configurations are supported with Zuplo Managed Dedicated instances. For
 example, you can use your own SSL certificates, or if you are using your own VPC

package/docs/dedicated/federated-gateways.mdx

@@ -7,7 +7,7 @@ sidebar_label: Federated Gateways
 
 With a managed dedicated Zuplo instance you can create a federated gateway that
 allows you to connect multiple Zuplo projects together. This is useful for
-creating a single API Gateway that can route requests to multiple backend
+creating a single Zuplo Gateway that can route requests to multiple backend
 services, each running on its own Zuplo instance.
 
 ## Reasons to Use Federated Gateways

package/docs/dedicated/networking.mdx

@@ -12,9 +12,9 @@ Common configurations include:
 - Using Zuplo as the public ingress to your API and using network connectivity
   such as PrivateLink, Private Service Connect, VNet or VPC peering, or
   provider-native network hubs to connect to your backend services.
-- Restricting access to the public internet by configuring your API Gateway to
+- Restricting access to the public internet by configuring your Zuplo Gateway to
   only accept traffic from specific IP ranges or private networks, allowing you
-  to put WAFs, IDS/IPS, or other security appliances in front of your API
+  to put WAFs, IDS/IPS, or other security appliances in front of your Zuplo
   Gateway.
 - Multiple dedicated managed instances of Zuplo can be deployed across multiple
   regions to provide high availability and disaster recovery.
@@ -32,19 +32,19 @@ To discuss your networking requirements, please contact your account manager.
 
 ## Zuplo Ingress to Customer Private Network
 
-The default setup for dedicated managed Zuplo is to use your Zuplo API Gateway
-as the public ingress to your API. This is the simplest setup and allows Zuplo
-to manage things like SSL certificates on your behalf.
+The default setup for dedicated managed Zuplo is to use your Zuplo Gateway as
+the public ingress to your API. This is the simplest setup and allows Zuplo to
+manage things like SSL certificates on your behalf.
 
 In this setup your private network isn't exposed to the public internet at all.
-Instead, your Zuplo API Gateway uses a private network connection to reach your
+Instead, your Zuplo Gateway uses a private network connection to reach your
 backend services.
 
 <Diagram height="h-48">
   <DiagramNode id="client">Client</DiagramNode>
   <DiagramGroup id="dedicated-vpc" label="Dedicated Network">
     <DiagramNode id="gateway" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
   </DiagramGroup>
   <DiagramGroup id="customer-vpc" label="Customer Private Network">
@@ -54,11 +54,11 @@ backend services.
   <DiagramEdge from="gateway" to="backend" />
 </Diagram>
 
-## Customer Private Network Ingress to Zuplo API Gateway
+## Customer Private Network Ingress to Zuplo Gateway
 
 If you have custom networking requirements, such as using a static IP address
 you already own, or if you want to run services such as WAFs, IDS/IPS, or other
-security products in front of your API Gateway, Zuplo can be configured to
+security products in front of your Zuplo Gateway, Zuplo can be configured to
 accept traffic from your private network and then route it to your backend. Your
 backend could be in the same network as your ingress or in another private
 network.
@@ -71,7 +71,7 @@ network.
   </DiagramGroup>
   <DiagramGroup id="dedicated-vpc" label="Dedicated Network">
     <DiagramNode id="gateway" variant="zuplo">
-      Zuplo API Gateway
+      Zuplo Gateway
     </DiagramNode>
   </DiagramGroup>
   <DiagramEdge from="client" to="waf" />

package/docs/dedicated/overview.mdx

@@ -10,7 +10,7 @@ configurations or have strict security or compliance requirements.
 
 Managed Dedicated hosting might be the right choice for you if you need:
 
-- To run your API Gateway on the cloud provider of your choice
+- To run your Zuplo Gateway on the cloud provider of your choice
 - To customize networking configurations, such as restricting access to the
   public internet
 - Have geographical deployment requirements where the
@@ -47,7 +47,7 @@ features as you would with edge-based deployments.
 
 In addition to the standard features, managed dedicated hosting provides:
 
-- **Custom Networking Configurations** - Configure your API Gateway to only be
+- **Custom Networking Configurations** - Configure your Zuplo Gateway to only be
   accessible from specific private networks or IP ranges
 - **Private Networking Options** - Support for provider-native private
   connectivity patterns such as AWS PrivateLink, Azure Private Link, and GCP
@@ -55,7 +55,7 @@ In addition to the standard features, managed dedicated hosting provides:
 - **Isolated Network Deployment** - Your gateway runs in a dedicated, isolated
   network environment for maximum security and isolation
 - **Custom Ingress Options** - Use your own static IP addresses or security
-  appliances (WAFs, IDS/IPS) in front of your API Gateway
+  appliances (WAFs, IDS/IPS) in front of your Zuplo Gateway
 
 ### High Availability