zuplo 7.3.2 → 7.4.3

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
 

package/docs/dedicated/source-control.mdx

@@ -3,8 +3,8 @@ title: "Managed Dedicated: Source Control"
 sidebar_label: "Source Control"
 ---
 
-Zuplo supports GitOps workflows for managing your API Gateway configuration.
-This means that you can store all of your API Gateway configuration in a Git
+Zuplo supports GitOps workflows for managing your Zuplo Gateway configuration.
+This means that you can store all of your Zuplo Gateway configuration in a Git
 repository and use Git to manage changes to your configuration. This allows you
 to track changes to your configuration over time, collaborate with others, and
 easily roll back changes if needed.
@@ -27,7 +27,7 @@ project.
 
 ## Create a Git Repository
 
-Next, you will need to create a Git repository to store your API Gateway
+Next, you will need to create a Git repository to store your Zuplo Gateway
 configuration. You can use a service like GitHub, GitLab, or Bitbucket to create
 a new repository.
 
@@ -44,7 +44,8 @@ git push -u origin main
 
 If you are using GitHub, you can connect your Zuplo project to your GitHub
 repository using the Zuplo integration. This will configure Zuplo to
-automatically deploy your API Gateway when you push changes to your repository.
+automatically deploy your Zuplo Gateway when you push changes to your
+repository.
 
 For the full instructions on how to connect your Zuplo project to GitHub, see
 [GitHub Integration](../articles/source-control-setup-github.mdx).
@@ -52,7 +53,7 @@ For the full instructions on how to connect your Zuplo project to GitHub, see
 ## Custom CI: Deploy your API
 
 If you aren't using GitHub, or would like to set up a custom CI/CD pipeline, you
-can use the Zuplo CLI to deploy your API Gateway.
+can use the Zuplo CLI to deploy your Zuplo Gateway.
 
 ```bash
 npx zuplo deploy --api-key $ZUPLO_API_KEY --project your-project-name --environment my-env

package/docs/handlers/custom-handler.mdx

@@ -3,10 +3,10 @@ title: Function Handler (Custom Handler)
 sidebar_label: Function Handler
 ---
 
-As an API gateway, the Request Handler is the most important part of a Zuplo
-project. This document shows how you can build a custom handler - this is often
-used by developers building BFF (backend-for-frontend), doing orchestration or
-custom traffic management.
+As a unified gateway for APIs, AI, and MCP, the Request Handler is the most
+important part of a Zuplo project. This document shows how you can build a
+custom handler - this is often used by developers building BFF
+(backend-for-frontend), doing orchestration or custom traffic management.
 
 A request handler is a module with an export that fulfills the following type
 definition (typescript).

package/docs/handlers/mcp-server.mdx

@@ -7,7 +7,7 @@ The MCP (Model Context Protocol) Server handler allows you to run a lightweight,
 stateless MCP server on your gateway that automatically transforms your API
 routes into MCP tools.
 
-This enables your API gateway to seamlessly serve external AI tools and agents
+This enables your Zuplo Gateway to seamlessly serve external AI tools and agents
 through [Model Context Protocol](https://modelcontextprotocol.io/introduction)
 interactions by using your existing APIs, without needing to duplicate
 functionality or rebuild business logic in your backend.

package/docs/handlers/url-forward.mdx

@@ -5,8 +5,7 @@ sidebar_label: URL Forward
 
 The URL Forward handler proxies requests to a different API without writing any
 code. It appends the incoming path section of the URL onto the specified
-`baseUrl` property, making it ideal for creating API gateways and backend
-proxying.
+`baseUrl` property, making it ideal for creating gateways and backend proxying.
 
 :::tip
 

package/docs/mcp-server/introduction.mdx

@@ -53,9 +53,9 @@ by:
 4. **Developer Experience**: Easy configuration and deployment using your
    existing OpenAPI specifications
 
-The MCP Server Handler transforms your existing Zuplo API gateway into a
-powerful toolset that AI systems can discover, understand, and invoke - bringing
-AI capabilities directly into your business workflows!
+The MCP Server Handler transforms your existing Zuplo Gateway into a powerful
+toolset that AI systems can discover, understand, and invoke - bringing AI
+capabilities directly into your business workflows!
 
 ## MCP Implementation Options
 
@@ -63,7 +63,7 @@ Zuplo provides two approaches for implementing MCP servers:
 
 ### 1. MCP Server Handler: Transform Routes into AI Tools
 
-The MCP Server Handler automatically transforms your API gateway routes into MCP
+The MCP Server Handler automatically transforms your gateway routes into MCP
 tools that AI systems can discover and use.
 
 #### How It Works

package/docs/policies/_index.md

@@ -5,10 +5,10 @@
 | set-query-params-inbound | Add or Set Query Parameters | Adds or sets query parameters on the incoming request. | api-gateway |
 | set-headers-inbound | Add or Set Request Headers | Adds or sets headers on the incoming request. | api-gateway |
 | ai-gateway-auth-v2-inbound | AI Gateway Authentication | Authenticates requests to an AI Gateway endpoint with application API keys.  Add this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header.  When the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires `configuration.id === request.params.app_id` and returns 403 on mismatch. | ai-gateway |
-| ai-gateway-configuration-executor-v2-inbound | AI Gateway Configuration Executor | Loads the app configuration for the request (when auth or the configuration loader has not already) and runs the inbound policy chain from that configuration.  Place this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration. | ai-gateway |
+| ai-gateway-configuration-executor-v2-inbound | AI Gateway Configuration Executor | Loads the app configuration for the request (when auth or the configuration loader has not already), runs the inbound policy chain from that configuration, and enforces limits inherited from parent teams or the gateway root.  Place this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration. | ai-gateway |
 | ai-gateway-configuration-loader-v2-inbound | AI Gateway Configuration Loader | Loads the AI Gateway app configuration for the request into the request-scoped channel and does nothing else.  Place this policy on AI Gateway routes before `ai-gateway-configuration-executor-v2-inbound` when you want configuration loading separated from chain execution. When `ai-gateway-auth-v2-inbound` already populated the channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter.  If this policy is omitted, the configuration executor still loads configuration itself before running the application chain. | ai-gateway |
 | ai-gateway-fallback-model-v2-inbound | AI Gateway Fallback Model | Adds failure and quota fallbacks to an existing AI Gateway model selection.  Place this policy after AI Gateway Model Filtering. It never creates a model selection, so a misplaced policy cannot bypass filtering. | ai-gateway |
-| ai-gateway-metering-v2-inbound | AI Gateway Metering | Meters AI Gateway usage and enforces app and ancestor usage limits.  Limits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
+| ai-gateway-metering-v2-inbound | AI Gateway Metering | Meters AI Gateway usage and enforces limits configured by the application.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
 | ai-gateway-model-filtering-v2-inbound | AI Gateway Model Filtering | Matches AI Gateway requests against curated allow lists or open block lists, then stores the winning model reference for the route handler. | ai-gateway |
 | ai-gateway-semantic-cache-v2-inbound | AI Gateway Semantic Cache | AI Gateway Semantic Cache policy. This inbound policy looks up the semantic cache on entry and, on a miss, registers a response-sending hook to write the upstream response back into the cache.  Caching parameters (semanticTolerance, expirationSecondsTtl, namespace, recentMessageCount) come from the policy options, and presence in the route's chain is what enables it. An id from the authenticated app configuration always provides the cache namespace so application-supplied options cannot cross tenant partitions. The cache key covers the system prompt plus the last `recentMessageCount` messages (default 1) — applied when storing and when matching — so multi-turn conversations can hit entries cached from earlier, shorter ones.  Cache outcomes are reported on the response via the RFC 9211 `Cache-Status` header under the cache name `zp-aigw-sem-cache` (hit: `zp-aigw-sem-cache; hit; detail="similarity=0.93"`; miss: `zp-aigw-sem-cache; fwd=miss; stored`). Responses also include the `x-ai-gateway-cache: HIT\|MISS` and `x-ai-gateway-cache-similarity` headers. | ai-gateway |
 | akamai-ai-firewall-v2-inbound | Akamai AI Firewall | Akamai AI Firewall Inbound Policy | ai-gateway |

package/docs/policies/ai-gateway-configuration-executor-v2-inbound/schema.json

@@ -12,7 +12,7 @@
   "requiresAI": true,
   "policyType": "ai-gateway-configuration-executor-v2",
   "products": ["ai-gateway"],
-  "description": "Loads the app configuration for the request (when auth or the configuration loader has not already) and runs the inbound policy chain from that configuration.\n\nPlace this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration.",
+  "description": "Loads the app configuration for the request (when auth or the configuration loader has not already), runs the inbound policy chain from that configuration, and enforces limits inherited from parent teams or the gateway root.\n\nPlace this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {