zuplo 7.4.1 → 7.4.3

package/docs/articles/migration-overview.md

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

package/docs/articles/monorepo-deployment.mdx

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

package/docs/articles/performance-testing.mdx

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

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

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

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

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

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