zuplo 7.3.2 → 7.4.3

package/docs/ai-gateway/apps.mdx

@@ -27,8 +27,8 @@ Each app has three things of its own:
 - **An API key**—authenticates the app's requests when the gateway runs the
   [authentication policy](./policy-chains.mdx#authentication).
 - **A [policy chain](./policy-chains.mdx)**—the ordered policies that run on the
-  app's requests: model access, budgets, caching, guardrails, and custom
-  policies. The chain starts out empty unless the app's team has a
+  app's requests: model access, app-specific budgets, caching, guardrails, and
+  custom policies. The chain starts out empty unless the app's team has a
   [policy template](./policy-templates.mdx).
 
 ## API Keys

package/docs/ai-gateway/custom-policies.mdx

@@ -7,9 +7,9 @@ description:
   push, and add it to an app's policy chain in the portal.
 ---
 
-The AI Gateway's built-in policies cover model access, budgets, caching,
-guardrails, and tracing—but your gateway can run any policy you can write in
-TypeScript. A custom policy lives in your gateway's
+The AI Gateway's built-in policies cover model access, app-specific budgets,
+caching, guardrails, and tracing—but your gateway can run any policy you can
+write in TypeScript. A custom policy lives in your gateway's
 [repository](./source-control.mdx), is declared in `config/policies.json`, and
 from then on appears in the portal's **Add Policy** dialog like any built-in
 policy. Apps add it to their [policy chains](./policy-chains.mdx), and it runs

package/docs/ai-gateway/fallback.mdx

@@ -7,8 +7,8 @@ description:
 ---
 
 Fallbacks let an app keep serving requests when its primary model fails, times
-out, or runs over its usage limits, instead of returning an error to the caller.
-They're configured with the **Fallback Model** policy in the app's
+out, or an applicable usage limit is exceeded, instead of returning an error to
+the caller. They're configured with the **Fallback Model** policy in the app's
 [policy chain](./policy-chains.mdx).
 
 The AI Gateway offers two independent fallback mechanisms, each triggered by a
@@ -17,7 +17,7 @@ different condition:
 | Mechanism              | Triggers when…                                                                                         | Without a fallback set…                     |
 | ---------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------- |
 | **Fallback & Timeout** | The primary fails with a retryable error (`5xx`, `408`, `425`, `429`), a network failure, or a timeout | The gateway returns the error to the caller |
-| **Quota Fallback**     | One of the app's usage limits is exceeded                                                              | The request is blocked with a `429`         |
+| **Quota Fallback**     | An app, team, or gateway usage limit is exceeded                                                       | The request is blocked with a `429`         |
 
 Both are configured entirely in the Zuplo Portal, and either can route to _any_
 provider—the fallback doesn't have to share the primary's provider. Fallback
@@ -57,21 +57,22 @@ is configured, the primary model call runs unbounded.
 ## Quota fallback
 
 The quota fallback routes requests to an alternate, usually cheaper, model when
-one of the app's [usage limits](./usage-limits.mdx) is exceeded, rather than
-blocking the request with a `429`. This keeps an app available after it crosses
-a budget, token, or request threshold, while shifting the overflow traffic to a
-lower-cost model.
+an app, team, or gateway [usage limit](./usage-limits.mdx) is exceeded, rather
+than blocking the request with a `429`. This keeps an app available after an
+applicable budget, token, or request threshold is crossed, while shifting the
+overflow traffic to a lower-cost model.
 
-For the quota fallback to activate, the chain needs the **Budgets and Costs**
-policy after Fallback Model—it detects the exceeded limit and switches to the
-fallback selection. If you leave the quota fallback empty, the app blocks
-requests with a `429` once it goes over quota.
+The **Fallback Model** policy supplies the quota fallback selection. Team and
+gateway limits can activate it whether or not the chain includes **Budgets and
+Costs**. Add Budgets and Costs when the app also needs its own limits, and place
+it after Fallback Model. If you leave the quota fallback empty, the gateway
+blocks requests with a `429` once an applicable limit is exceeded.
 
 :::tip
 
 Point the quota fallback at a smaller, cheaper model so overflow traffic stays
 inexpensive while remaining available. The fallback's own usage still counts
-toward the app's limits.
+toward every applicable limit.
 
 :::
 

package/docs/ai-gateway/getting-started.mdx

@@ -107,7 +107,8 @@ account, Zuplo project, and AI Gateway team roles control access.
    on later teams, letting you nest them. To set gateway-wide spending limits
    across this Zuplo project, open the gateway's **Settings → Usage Limits**;
    for team-specific limits, use the team's **Usage & Limits** tab. See
-   [Usage Limits](./usage-limits.mdx).
+   [Usage Limits](./usage-limits.mdx). Gateway and team limits apply to every
+   app regardless of its policy chain.
 
 5. **Create an app**
 
@@ -117,8 +118,8 @@ account, Zuplo project, and AI Gateway team roles control access.
    In the **Apps & Teams** tab, select the team you just created and click
    **Create App** in the team's header. Give the app a descriptive name (for
    example, "Tennis Chat") and confirm the team that owns it. That's the whole
-   dialog—models, budgets, and other behavior are configured on the app's policy
-   chain in the next step.
+   dialog—models, app-specific budgets, and other behavior are configured on the
+   app's policy chain in the next step.
 
    :::tip
 
@@ -148,9 +149,9 @@ account, Zuplo project, and AI Gateway team roles control access.
 
    :::
 
-   This is also where you add budgets, semantic caching, guardrails, and any
-   custom policies. Changes to the chain apply within about a minute—no redeploy
-   needed. See [Policy Chains](./policy-chains.mdx).
+   This is also where you add app-specific budgets, semantic caching,
+   guardrails, and any custom policies. Changes to the chain apply within about
+   a minute—no redeploy needed. See [Policy Chains](./policy-chains.mdx).
 
 7. **Get the app's URL and API key**
 
@@ -300,8 +301,8 @@ metrics.
 
 ## Next steps
 
-- [Policy Chains](./policy-chains.mdx): add budgets, semantic caching, and
-  guardrails to your app's chain
+- [Policy Chains](./policy-chains.mdx): add app-specific budgets, semantic
+  caching, and guardrails to your app's chain
 - [Custom Policies](./custom-policies.mdx): write your own policy and add it to
   an app's chain
 - [Policy Templates](./policy-templates.mdx): give every new app in a team a
@@ -317,4 +318,4 @@ metrics.
 | 404 "Unsupported AI Gateway endpoint"     | The path must end with a supported `/v1/...` operation—usually the URL is missing its `/v1` segment. Use the app's API URL plus `/v1/chat/completions`, for example |
 | 400 error asking for `providerName/model` | Prefix the model with the provider name configured in the portal—`openai/gpt-5-mini`, not `gpt-5-mini`                                                              |
 | 403 error listing the allowed models      | The app's Model Filtering policy doesn't include the requested model; add it on the app's Policies tab or use a listed one                                          |
-| Budget limit reached immediately          | Check the limits at every level—gateway, team, and the app's Budgets and Costs policy—since any level's limit blocks the request                                    |
+| Budget limit reached immediately          | Check the gateway and team limits, which always apply, plus the app's Budgets and Costs policy; any level's limit can block the request                             |

package/docs/ai-gateway/introduction.mdx

@@ -16,11 +16,12 @@ responses while applying policies, controls, and monitoring.
 Each piece of software that calls the gateway registers as an **app**—your
 support chatbot is one app; an internal coding agent is another. A single AI
 Gateway holds as many apps as you need, and you control exactly which policies
-run for each one. Every app has its own ordered policy chain, so the
-customer-facing chatbot can enforce budgets and guardrails while the internal
-agent runs with none. Beyond the built-in policies, you can write your own in
-TypeScript, and apps add them to their chains like any other policy. Chain
-changes apply within about a minute, with no redeploy. See [Apps](./apps.mdx).
+run for each one. Every app has its own ordered policy chain, so you can give
+the customer-facing chatbot an app-specific budget and guardrails while leaving
+those controls out of the internal agent's chain. Beyond the built-in policies,
+you can write your own in TypeScript, and apps add them to their chains like any
+other policy. Chain changes apply within about a minute, with no redeploy. See
+[Apps](./apps.mdx).
 
 ## Key Benefits
 
@@ -59,15 +60,15 @@ provider. Each app has its own URL, API key, and policy chain, so one gateway
 serves teams with completely different configurations.
 
 Each request arrives at the URL of the app it belongs to. The gateway identifies
-that app, runs its policy chain (model access, cost controls, security
-guardrails), routes to the selected LLM provider, and streams the response back.
-Throughout this process, the gateway captures metrics without exposing
-underlying provider credentials.
+that app, runs its policy chain (model access, app-specific cost controls,
+security guardrails), routes to the selected LLM provider, and streams the
+response back. Throughout this process, the gateway captures metrics without
+exposing underlying provider credentials.
 
-Every control is opt-in. An app whose policy chain is empty proxies requests
-immediately—each request names its own model, and no model restrictions,
-budgets, guardrails, or caching apply until you add the policies that enforce
-them.
+Every app-specific control is opt-in. An app whose policy chain is empty runs no
+app-selected controls: each request names its own model, and no app-specific
+model restrictions, budgets, guardrails, or caching apply. Gateway and team
+usage limits still apply.
 
 ## Core Features
 
@@ -90,9 +91,9 @@ runs, so gateway changes go through your normal review workflow. See
 ### Per-App Policy Chains
 
 Each app runs its own ordered chain of policies—model filtering, fallback
-models, budgets, semantic caching, guardrails, tracing, and any custom policies
-declared in the repository. Team policy templates give new apps a consistent
-starting pipeline. See [Policy Chains](./policy-chains.mdx) and
+models, app-specific budgets, semantic caching, guardrails, tracing, and any
+custom policies declared in the repository. Team policy templates give new apps
+a consistent starting pipeline. See [Policy Chains](./policy-chains.mdx) and
 [Custom Policies](./custom-policies.mdx).
 
 ### Team Hierarchy & Budgets
@@ -113,8 +114,8 @@ Each app gets its own:
 
 - **Unique Gateway URL**: Single endpoint regardless of underlying provider
 - **API Key**: Zuplo-managed key that never exposes provider credentials
-- **Policy Chain**: Model access, budgets, caching, guardrails, and custom
-  policies, applied in the order the app chooses
+- **Policy Chain**: Model access, app-specific budgets, caching, guardrails, and
+  custom policies, applied in the order the app chooses
 
 ### Zuplo accounts and projects
 

package/docs/ai-gateway/managing-apps.mdx

@@ -2,8 +2,8 @@
 title: Managing Apps
 description:
   Create, edit, and delete AI Gateway apps. Apps are created with just a name
-  and a team; models, budgets, and other behavior live on the app's policy
-  chain.
+  and a team; models, app-specific budgets, and other behavior live on the app's
+  policy chain.
 ---
 
 An app represents one caller of your AI Gateway—a service, an agent, or a
@@ -47,7 +47,8 @@ permission to view the Zuplo project that contains the AI Gateway.
 That's the whole dialog. The portal then takes you to the app's **Policies**
 tab. If the app's team defines a [policy template](./policy-templates.mdx), the
 new app starts with that chain; otherwise the chain is empty and the app is
-unrestricted until you add policies.
+subject to no app-specific controls until you add policies. Team and gateway
+usage limits still apply.
 
 ## Restricting models
 
@@ -86,16 +87,17 @@ over—see [Dynamic model routing](./cookbooks/dynamic-model-routing.mdx).
 
 App budgets live on the **Budgets and Costs** policy in the app's chain. Open
 the app's **Policies** tab and configure it with daily or monthly limits for
-spending, tokens, or requests. If you don't set app limits, the team's and
-gateway's limits still apply. See [Usage Limits](./usage-limits.mdx).
+spending, tokens, or requests. Team and gateway limits apply to every app
+automatically, even when the app's chain doesn't include Budgets and Costs. See
+[Usage Limits](./usage-limits.mdx).
 
 ## Editing an App
 
 To edit an app, open the
 [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps) tab of your
 AI Gateway project in the Zuplo Portal. Select the app you want to edit. The
-app's behavior—models, budgets, caching, guardrails—is edited on the
-**Policies** tab; the app's name lives on the **Settings** tab. Make your
+app's behavior—models, app-specific budgets, caching, guardrails—is edited on
+the **Policies** tab; the app's name lives on the **Settings** tab. Make your
 changes and click the **Save** button. Policy chain changes apply within about a
 minute.
 

package/docs/ai-gateway/policy-chains.mdx

@@ -8,9 +8,9 @@ description:
 ---
 
 Every request to an AI Gateway app runs down through the app's **policy chain**:
-an ordered list of policies that control model access, budgets, caching,
-guardrails, and tracing for that app. Different apps on the same gateway can run
-completely different chains.
+an ordered list of policies that control model access, app-specific budgets,
+caching, guardrails, and tracing for that app. Different apps on the same
+gateway can run completely different chains.
 
 The chain works in two layers:
 
@@ -24,8 +24,9 @@ The chain works in two layers:
   portal. Chain changes apply within about a minute, with no deploy.
 
 No policy is required. An app whose chain is empty still serves requests: each
-request names its own model, and no model restrictions, budgets, guardrails, or
-caching apply. Every control is something you add.
+request names its own model, and no app-specific model restrictions, budgets,
+guardrails, or caching apply. Team and gateway usage limits apply regardless of
+the app's policy chain.
 
 A request passes through whatever the app selected before the AI Gateway handler
 calls the provider:
@@ -105,14 +106,19 @@ Model Filtering → Fallback Model → Budgets and Costs → Semantic Cache
   never creates one. A chain with Fallback Model but no Model Filtering does
   nothing at all—the policy logs a warning and passes the request through
   unchanged. That's also why a fallback can never bypass the filter.
-- **Budgets and Costs** third: it needs the resolved selection so an exceeded
-  budget can activate the quota fallback.
+- **Budgets and Costs** third: it configures the app's own limits and needs the
+  resolved selection so an exceeded app limit can activate the quota fallback.
 - **Semantic Cache** after Budgets and Costs: cache hits still count toward
   request limits.
 
 Tracing policies work well at the end of the chain, so traces reflect the
 request the earlier policies produced.
 
+Team and gateway limits are enforced outside the app's policy chain. When one is
+exceeded, the app's quota fallback works whether or not its chain includes
+Budgets and Costs, as long as Model Filtering and Fallback Model supply a
+fallback selection.
+
 ## Built-in policies
 
 See the [policies overview](./policies/overview.mdx) for every policy an app can

package/docs/ai-gateway/policy-templates.mdx

@@ -8,9 +8,10 @@ description:
 ---
 
 A team's **policy template** is the policy chain that apps created in that team
-start with. Use templates to make sure every app in a team begins with your
-required policies—Budgets and Costs with a sensible budget, a guardrail, your
-custom compliance policy—while controlling what individual apps may change.
+start with. Use templates to give every app in a team the same app-specific
+controls—such as Model Filtering, Budgets and Costs with an app budget, a
+guardrail, or a custom compliance policy—while controlling what individual apps
+may change. Team and gateway limits don't depend on the template.
 
 ## How templates apply
 

package/docs/ai-gateway/usage-limits.mdx

@@ -83,22 +83,20 @@ requests to that model instead of blocking with a `429`—see
 [Fallback Models](./fallback.mdx). The fallback's usage still counts toward the
 limits.
 
-:::warning
+:::note{title="App, team, and gateway limits are configured separately"}
 
-An app without the Budgets and Costs policy in its chain doesn't enforce
-app-level limits. Team and gateway limits still protect overall spend, but
-per-app budgets need Budgets and Costs in the chain—use a
-[policy template](./policy-templates.mdx) to make sure every app starts with it.
+The Budgets and Costs policy configures and enforces an app's own limits. Team
+and gateway limits apply to every app automatically, whether or not the app's
+policy chain includes Budgets and Costs.
 
 :::
 
 :::caution{title="Budgets fail open by default"}
 
-The Budgets and Costs policy's `throwOnFailure` option defaults to `false`, so
-if the metering service is unavailable the request proceeds unmetered: no limit
-is checked and the request reaches the provider even if the app is already over
-budget. Set `throwOnFailure` to `true` to fail closed instead, so a metering
-outage rejects the request rather than letting it escape the budget.
+The Budgets and Costs policy's `throwOnFailure` option controls how an error
+while checking the app's own limits is handled. It defaults to `false`, so the
+request continues through the gateway. Set it to `true` to reject the request
+instead. Team and gateway limit checks run independently of this policy.
 
 :::
 

package/docs/api-management/introduction.md

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

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

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

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

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

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

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

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

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

package/docs/articles/custom-domains.mdx

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

package/docs/articles/development-options.mdx

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

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

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