zuplo 7.1.9 → 7.1.10

package/docs/ai-gateway/apps.mdx

@@ -9,13 +9,21 @@ description:
 An app represents one caller of your AI Gateway—a service, an agent, or a
 feature in a larger codebase. A support chatbot on your website is one app; the
 batch job that summarizes tickets overnight is another. Each app belongs to a
-[team](./teams.mdx) and can reach the AI providers assigned to that team.
+[team](./teams.mdx), which controls dashboard access to the app. Access to AI
+providers is governed separately by the user's Zuplo account and Zuplo project
+roles. A Zuplo account contains one or more projects, and the AI Gateway is the
+Zuplo project that contains these providers, teams, and apps. See
+[Role Permissions](../articles/accounts/roles-and-permissions.mdx).
 
 Each app has three things of its own:
 
-- **An API URL**—the endpoint the app's code calls, shown at the top of the app
-  page. The gateway attributes requests made to this URL to the app, tracking
-  usage independently per app. See the [Universal API](./universal-api.mdx).
+- **An API URL**—the endpoint the app's code calls, shown in full at the top of
+  the app page. Expand it to see the ready-to-paste URL for each service the
+  gateway mounts under the app—**Chat Completions** (`v1/chat/completions`),
+  **Responses** (`v1/responses`, OpenAI only), and **Messages** (`v1/messages`,
+  Anthropic only)—and copy the one your client needs. The gateway attributes
+  requests made to this URL to the app, tracking usage independently per app.
+  See the [Universal API](./universal-api.mdx).
 - **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
@@ -32,15 +40,24 @@ validated key or from the `{app_id}` segment of the request URL, so an app
 without authentication still tracks usage independently.
 
 To find an app's API key, open the
-[Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of your AI
-Gateway project in the Zuplo Portal and select the app. The API key appears in
-the API Key section at the top of the app page.
+[Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps) tab of your
+AI Gateway project in the Zuplo Portal and select the app. The key lives on the
+app's **API Key** tab.
+
+:::caution{title="Rotate keys to revoke access"}
+
+An issued app API key authenticates gateway traffic by the key itself. Changing
+a user's dashboard permissions or removing them from a team doesn't invalidate
+the key. To revoke access, rotate the app's API key and update authorized
+clients with the new value.
+
+:::
 
 **Additional Resources**
 
-- [Creating & Editing Apps](./managing-apps.mdx) - How to add, remove, and set
-  roles for project members.
+- [Creating & Editing Apps](./managing-apps.mdx) - How to create, configure, and
+  delete apps.
 - [Creating & Editing Teams](./managing-teams.mdx) - How to create and edit
   teams.
 - [Role Permissions](../articles/accounts/roles-and-permissions.mdx) - Details
-  on the roles available at the account and project levels.
+  on Zuplo account, Zuplo project, and AI Gateway team roles.

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

@@ -117,10 +117,10 @@ terms. By the end, one app on your gateway rejects a prompt containing
 4. **Add the policy to an app's chain**
 
    In the Zuplo Portal, open
-   [**Apps**](https://portal.zuplo.com/+/account/project/ai/apps), select your
-   app, and open its **Policies** tab. Click **Add Policy**—`content-filter` now
-   appears alongside the built-in policies. Add it, drag it to where in the
-   chain it should run, and save.
+   [**Apps & Teams**](https://portal.zuplo.com/+/account/project/ai/apps),
+   select your app, and open its **Policies** tab. Click **Add
+   Policy**—`content-filter` now appears alongside the built-in policies. Add
+   it, drag it to where in the chain it should run, and save.
 
    :::tip{title="Where in the chain?"}
 

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

@@ -8,14 +8,33 @@ description:
 ---
 
 Zuplo's AI Gateway supports the addition of custom AI providers. This allows
-users to route their AI Gateway Apps to self hosted services and models,
+users to route their AI Gateway Apps to self-hosted services and models,
 providing an additional layer of control, security and governance when using
 these models in production.
 
-:::note
+## Requirements
 
-Please note that currently only OpenAI-compatible models are supported using
-custom providers
+A custom provider must expose an OpenAI-compatible API. The gateway expects:
+
+- `POST <api-url>/v1/chat/completions` for chat completion models, accepting and
+  returning OpenAI Chat Completions schemas
+- `POST <api-url>/v1/embeddings` for embedding models, accepting and returning
+  OpenAI Embeddings schemas
+
+The gateway authenticates each request with your provider API key as a bearer
+token: `Authorization: Bearer <your-api-key>`.
+
+The gateway appends these paths to the API URL you configure, so the provider
+must serve `chat/completions` under a `/v1` path segment. A provider that serves
+its OpenAI-compatible API at a path without `/v1`—directly off the origin, for
+example—won't work as a custom provider.
+
+:::note{title="Unsupported endpoints"}
+
+Custom providers serve chat completions and embeddings only. The gateway's
+`/v1/responses` and `/v1/messages` endpoints don't accept custom-provider
+models: a `/v1/responses` request fails with a `400` error and the message
+`The /v1/responses endpoint is only supported by OpenAI provider. Current provider: <name>`.
 
 :::
 
@@ -41,7 +60,25 @@ To add a custom AI provider to your Zuplo AI Gateway, follow these steps:
    `mistral`, `xai`, `moonshot`, `zuplo`, `zuplodemo`, `zuplo-demo`). The name
    is permanent after creation.
 
-1. Specify the API URL of the custom provider you are using.
+1. Enter the provider's **API URL** as its origin root—for example
+   `https://api.together.xyz`. The gateway appends `/v1/chat/completions` (and
+   `/v1/embeddings` for embedding models) to this value itself, so the URL must
+   not carry a `/v1` suffix.
+
+   :::caution{title="Leave the /v1 suffix off"}
+
+   Vendors usually publish a base URL that already ends in `/v1`. Pasting that
+   value makes the gateway call `/v1/v1/chat/completions`, and the provider
+   answers `404`. Strip the suffix:
+
+   :::
+
+   | Vendor     | Published base URL                      | API URL to enter                     |
+   | ---------- | --------------------------------------- | ------------------------------------ |
+   | OpenRouter | `https://openrouter.ai/api/v1`          | `https://openrouter.ai/api`          |
+   | Together   | `https://api.together.xyz/v1`           | `https://api.together.xyz`           |
+   | Groq       | `https://api.groq.com/openai/v1`        | `https://api.groq.com/openai`        |
+   | Fireworks  | `https://api.fireworks.ai/inference/v1` | `https://api.fireworks.ai/inference` |
 
 1. Enter the API Key for the selected provider (if there is no API key required,
    you can leave this blank).
@@ -54,6 +91,15 @@ To add a custom AI provider to your Zuplo AI Gateway, follow these steps:
 
 </Stepper>
 
+## Verify the provider
+
+Saving a provider triggers a production deployment of your gateway, and the
+portal doesn't test the provider connection itself. Once the deployment
+completes, send a chat completions request through your app's
+[Universal API](./universal-api.mdx) URL with one of the provider's models and
+confirm a `200` response. If the provider answers `404`, check the API URL for a
+stray `/v1` suffix.
+
 ## Modify, Update or Delete your Custom AI Provider
 
 To modify, update, or delete an existing provider, open

package/docs/ai-gateway/fallback.mdx

@@ -27,8 +27,8 @@ models are referenced like any model, as `providerName/model`.
 
 <Stepper>
 
-1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of
-   your AI Gateway project and select the app to edit.
+1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps)
+   tab of your AI Gateway project and select the app to edit.
 
 1. Select the **Policies** tab. If the chain doesn't have a **Fallback Model**
    policy yet, click **Add Policy** and add it—placed directly after Model

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

@@ -10,11 +10,16 @@ description:
 This guide walks you through setting up your first AI Gateway project, from
 connecting a Git repository to making your first LLM request through Zuplo.
 
+A Zuplo account contains your members and one or more projects. The AI Gateway
+you create in this guide is a Zuplo project; its providers, teams, and apps all
+belong to that project. See
+[Role Permissions](../articles/accounts/roles-and-permissions.mdx) for how Zuplo
+account, Zuplo project, and AI Gateway team roles control access.
+
 ## Prerequisites
 
 - A Zuplo account (sign up free at [zuplo.com](https://zuplo.com))
-- An account with a supported Git provider that can create repositories (this
-  guide uses GitHub)
+- A Git provider account that can create repositories (this guide uses GitHub)
 - An API key for at least one LLM provider (OpenAI, Anthropic, Google, Mistral,
   xAI, etc.)—or none at all, if you start with the free
   [Zuplo Demo provider](./providers.mdx#zuplo-demo)
@@ -96,21 +101,24 @@ connecting a Git repository to making your first LLM request through Zuplo.
    Teams organize users and carry hierarchical budget controls and policy
    templates. Even if you're starting solo, you need at least one team.
 
-   Open the **Teams** tab and click **Create Team**. Name your team (for
+   Open the **Apps & Teams** tab and click **New Team**. Name your team (for
    example, "Root" or your company name), choose an icon, and click **Create
-   Team**. To set organization-wide spending limits, open the gateway's
-   **Settings → Usage Limits**; for team-specific limits, use the team's **Usage
-   & Limits** tab. See [Usage Limits](./usage-limits.mdx).
+   Team**. This is your first team, so there's no parent picker yet—it appears
+   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).
 
 5. **Create an app**
 
-   Apps represent individual projects or services that call the AI Gateway. Each
-   app gets its own unique URL and API key.
+   Apps represent individual software applications or services that call the AI
+   Gateway. Each app gets its own unique URL and API key.
 
-   Open the **Apps** tab and click **Create App**. Give the app a descriptive
-   name (for example, "Tennis Chat") and select 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.
+   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.
 
    :::tip
 
@@ -135,8 +143,8 @@ connecting a Git repository to making your first LLM request through Zuplo.
    :::caution{title="An unrestricted app can reach every model you configured"}
 
    Without Model Filtering, an app may call any model available through the
-   providers assigned to its team, including expensive ones. Add Model Filtering
-   for any app that should be limited to a specific set.
+   providers configured for this Zuplo project, including expensive ones. Add
+   Model Filtering for any app that should be limited to a specific set.
 
    :::
 
@@ -146,8 +154,9 @@ connecting a Git repository to making your first LLM request through Zuplo.
 
 7. **Get the app's URL and API key**
 
-   The app page shows its **API URL** and **API Key** at the top right. The API
-   URL is the gateway's hostname plus the app's ID—for example
+   The app's **API URL** is shown in full at the top of the app page, and its
+   key lives on the app's **API Key** tab. The API URL is the gateway's hostname
+   plus the app's ID—for example
    `https://my-gateway-main-2e18f50.zuplo.app/config_fe0a04972d2848e0a94ae4b8bcd1497e`.
    Copy both rather than constructing them.
 
@@ -156,6 +165,14 @@ connecting a Git repository to making your first LLM request through Zuplo.
    `https://my-gateway-main-2e18f50.zuplo.app/config_fe0a04972d2848e0a94ae4b8bcd1497e/v1`
    as a stand-in, and requests land on paths like `/v1/chat/completions`.
 
+   :::tip
+
+   Expand the API URL to get the exact endpoint for each service the gateway
+   mounts—**Chat Completions**, **Responses**, and **Messages**—and copy the one
+   your client needs instead of assembling it by hand.
+
+   :::
+
    :::note
 
    The gateway checks the key only after you add the
@@ -174,14 +191,16 @@ connecting a Git repository to making your first LLM request through Zuplo.
 
 8. **Send your first request from the Playground**
 
-   The app's **Playground** tab chats with the app's own gateway URL and API
-   key, so it exercises the same policy chain your code will hit—without wiring
-   up a client first.
+   Click **Playground** in the app's header to open it. It chats with the app's
+   own gateway URL and API key, so it exercises the same policy chain your code
+   will hit—without wiring up a client first. The button sits on every app tab,
+   so you can try a request while editing policies without losing your place.
 
    Pick a model from the selector, optionally set a system prompt, and send a
-   message. The tab shows the cURL for the next request, and **Copy cURL** puts
-   it on your clipboard to run in a terminal or adapt it for your client. Expand
-   any reply to inspect the request and the raw response.
+   message. The playground shows the cURL for the next request, and **Copy
+   cURL** puts it on your clipboard to run in a terminal or adapt it for your
+   client. Expand any reply to inspect the request and the raw response. Closing
+   the playground keeps the conversation, so you can reopen it and carry on.
 
 </Stepper>
 
@@ -263,16 +282,18 @@ curl https://my-gateway-main-2e18f50.zuplo.app/config_fe0a04972d2848e0a94ae4b8bc
   }'
 ```
 
-### Check your dashboard
+### Check your usage
 
-1. Open the [**Apps**](https://portal.zuplo.com/+/account/project/ai/apps) tab
-   of your AI Gateway project
+1. Open the
+   [**Apps & Teams**](https://portal.zuplo.com/+/account/project/ai/apps) tab of
+   your AI Gateway project
 2. Click on your app
-3. Click on the app's **Dashboard** tab to view:
-   - Request count
-   - Token usage
-   - Time to first byte
-   - Current spending
+3. The app's **Overview** tab shows:
+   - **Daily Usage** and **Monthly Usage**—spend, tokens, and requests, with
+     progress against any configured limits
+   - A **Metrics** frame with request count, token usage, and cost over time
+4. Click **View in Analytics** on the Metrics frame for the full request-level
+   breakdown, already filtered to this app.
 
 You should see your test request appear with token usage and performance
 metrics.

package/docs/ai-gateway/integrations/ai-sdk.mdx

@@ -43,9 +43,9 @@ the app you have configured in Zuplo.
 
 Models are referenced as `providerName/model`, where `providerName` is the
 provider name configured in your gateway. By default an app can reach any model
-offered by the providers assigned to its [team](../managing-teams.mdx). To limit
-it to a curated set, add the [Model Filtering](../policies/model-filtering.mdx)
-policy to the app—it applies separate rules to completions (`generateText`,
+offered by the providers configured for the Zuplo project. To limit it to a
+curated set, add the [Model Filtering](../policies/model-filtering.mdx) policy
+to the app—it applies separate rules to completions (`generateText`,
 `streamText`) and embeddings (`embed`), and rejects a capability it doesn't
 configure.
 

package/docs/ai-gateway/introduction.mdx

@@ -29,7 +29,7 @@ Google, Mistral, xAI, and more) dynamically without modifying app code.
 Configure model access through the gateway rather than hard coding it into your
 apps.
 
-**Cost Control**: Set spending limits at organization, team, and app levels with
+**Cost Control**: Set spending limits at gateway, team, and app levels with
 hierarchical budgets that cascade down through your structure. Configure daily
 and monthly thresholds with enforcement or warning notifications.
 
@@ -50,7 +50,7 @@ cached responses for similar prompts, reducing costs and improving response
 times.
 
 **Full Observability**: Real-time dashboards show request counts, token usage,
-time-to-first-byte metrics, and spending patterns across your organization.
+time-to-first-byte metrics, and spending patterns across your gateway.
 
 ## How It Works
 
@@ -73,7 +73,7 @@ them.
 
 ### Multi-Provider Support
 
-Configure multiple LLM providers within a single gateway project. Supported
+Configure multiple LLM providers within a single AI Gateway project. Supported
 providers include OpenAI, Anthropic, Google, Mistral, xAI, and OpenAI-compatible
 custom providers. See [AI Providers](./providers.mdx) for the full list of
 providers and supported capabilities. Apps reference models as
@@ -100,7 +100,7 @@ starting pipeline. See [Policy Chains](./policy-chains.mdx) and
 Organize users into teams with hierarchical structures. Set budget limits at
 each level that cascade down:
 
-- **Gateway**: Organization-wide limits (for example, $1,000/day)
+- **Gateway**: Limits across the Zuplo project (for example, $1,000/day)
 - **Teams**: Team-specific limits that can't exceed parent limits (for example,
   $500/day for the Credit Team)
 - **Apps**: Per-app limits for granular control
@@ -116,12 +116,25 @@ Each app gets its own:
 - **Policy Chain**: Model access, budgets, caching, guardrails, and custom
   policies, applied in the order the app chooses
 
+### Zuplo accounts and projects
+
+A **Zuplo account** is the top-level container for your members and projects.
+Each **Zuplo project** belongs to one account, and an AI Gateway is a type of
+Zuplo project. The providers, teams, and apps you configure for a gateway all
+belong to that project.
+
+Account roles can grant access across the projects in a Zuplo account, while
+project roles grant access to one Zuplo project. AI Gateway team roles add
+access to a team and its apps within that project. See
+[Role Permissions](../articles/accounts/roles-and-permissions.mdx) for the exact
+permissions each role grants.
+
 ## Use Cases
 
 - **Multi-tenant AI Apps**: Enforce spending limits per customer or team
 - **Agent Development**: Build AI agents that can switch providers without code
   changes
-- **Cost Management**: Control and monitor LLM spending across your organization
+- **Cost Management**: Control and monitor LLM spending across your gateway
 - **Security Compliance**: Ensure PII and prompt injection protection across all
   LLM interactions
 - **Performance**: Reduce costs and latency with semantic caching for common

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

@@ -11,22 +11,36 @@ feature in a larger codebase. Each app has its own API key, which the gateway
 checks once you add the
 [authentication policy](./policy-chains.mdx#authentication); usage is tracked
 per app whether or not that policy applies. Each app belongs to a
-[team](./teams.mdx) and can reach the AI providers assigned to that team.
+[team](./teams.mdx), which controls who can access and manage the app. Provider
+access is governed separately by the user's Zuplo account and Zuplo project
+roles. A Zuplo account contains one or more projects; this AI Gateway and its
+providers, teams, and apps belong to one Zuplo project. See
+[Role Permissions](../articles/accounts/roles-and-permissions.mdx).
+
+:::note{title="App permissions"}
+
+A team **Admin** can create, edit, and delete apps owned by that team. A team
+**Member** can access the team's apps but can't manage them. Both roles require
+permission to view the Zuplo project that contains the AI Gateway.
+
+:::
 
 ## Creating an App
 
 <Stepper>
 
-1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of
-   your AI Gateway project in the Zuplo Portal.
+1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps)
+   tab of your AI Gateway project in the Zuplo Portal.
 
-1. Click on the **Create App** button.
+1. Select the team that will own the app, then click **Create App** in the
+   team's header. An app always belongs to a team, so the tree's own create
+   action is **New Team**.
 
-1. Enter the name of your app.
+1. Enter the **App name**.
 
-1. Select the team that will own the app.
+1. Confirm the **Team**—it's prefilled with the team you started from.
 
-1. Click **Create**
+1. Click **Create app**
 
 </Stepper>
 
@@ -38,7 +52,7 @@ unrestricted until you add policies.
 ## Restricting models
 
 By default an app isn't restricted to particular models: any model available
-through the providers assigned to the app's [team](./teams.mdx) is accepted. An
+through the providers configured for the Zuplo project is accepted. An
 unrestricted app has no default model, so every request must name one as
 `providerName/model`. A request with no model, or a model without that prefix,
 gets a `400`.
@@ -57,13 +71,13 @@ and configure each capability (completions, embeddings) in one of two modes:
 The two modes are mutually exclusive per capability: a capability takes an allow
 list or a block list, never both.
 
-| Request                                                                                  | Response                      |
-| ---------------------------------------------------------------------------------------- | ----------------------------- |
-| A model the rules don't allow                                                            | `403`, listing what's allowed |
-| No `model` named, with no allow list to supply a default                                 | `400`                         |
-| A model with no `providerName/` prefix                                                   | `400`                         |
-| A capability the policy doesn't configure at all                                         | `403`                         |
-| A provider name that isn't in the project's [provider catalog](./managing-providers.mdx) | `400`                         |
+| Request                                                                                        | Response                      |
+| ---------------------------------------------------------------------------------------------- | ----------------------------- |
+| A model the rules don't allow                                                                  | `403`, listing what's allowed |
+| No `model` named, with no allow list to supply a default                                       | `400`                         |
+| A model with no `providerName/` prefix                                                         | `400`                         |
+| A capability the policy doesn't configure at all                                               | `403`                         |
+| A provider name that isn't in the Zuplo project's [provider catalog](./managing-providers.mdx) | `400`                         |
 
 When model selection needs logic instead of a list, a custom policy can take
 over—see [Dynamic model routing](./cookbooks/dynamic-model-routing.mdx).
@@ -78,16 +92,17 @@ gateway's limits still apply. See [Usage Limits](./usage-limits.mdx).
 ## Editing an App
 
 To edit an app, open the
-[Apps](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 changes and click the
-**Save** button. Policy chain changes apply within about a minute.
+[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
+changes and click the **Save** button. Policy chain changes apply within about a
+minute.
 
 ## Deleting an App
 
 To delete an app, open the
-[Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab of your AI
-Gateway project in the Zuplo Portal. Select the app you want to delete, open its
-**Settings** tab, and click the **Delete App** button. You will be prompted to
-confirm the deletion.
+[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 delete, open
+its **Settings** tab, and click the **Delete App** button. You will be prompted
+to confirm the deletion.

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

@@ -10,6 +10,19 @@ Zuplo's AI Gateway supports integration with various
 [AI providers](./providers.mdx), allowing you to leverage different models and
 services for your apps.
 
+:::note{title="Provider permissions"}
+
+AI providers are configured for a Zuplo project. A Zuplo account contains one or
+more projects: an account role can grant access across those projects, while a
+project role grants access only to that project. Adding, editing, or deleting
+providers and their models requires the **Edit** permission granted to Zuplo
+account and Zuplo project **Admins**. A Zuplo account **Developer**, or a Zuplo
+project **Developer** or **Member**, can view providers but can't manage them.
+Team membership doesn't grant provider access. See
+[Role Permissions](../articles/accounts/roles-and-permissions.mdx).
+
+:::
+
 ## Adding a New AI Provider
 
 To add a new AI provider to your Zuplo AI Gateway, follow these steps:
@@ -24,7 +37,9 @@ To add a new AI provider to your Zuplo AI Gateway, follow these steps:
 
 1. Select the desired provider from the list of
    [supported providers](./providers.mdx), or
-   [add a custom provider](./custom-providers.mdx).
+   [add a custom provider](./custom-providers.mdx). A custom provider's API URL
+   is its origin root—without the `/v1` suffix vendors usually publish—because
+   the gateway appends the operation path itself.
 
 1. Review the **Provider Name**, which fills in automatically based on the
    provider you selected (a second OpenAI configuration becomes `openai-2`). You
@@ -80,7 +95,7 @@ available fail with an error naming the model.
 
 ## Deleting an AI Provider
 
-Providers that are no longer used within your project can be deleted. To delete
-a provider, open
+Providers that are no longer used within your Zuplo project can be deleted. To
+delete a provider, open
 [**Settings → AI Providers**](https://portal.zuplo.com/+/account/project/ai/settings/data-models)
 and click the **Delete** button next to the provider you want to remove.

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

@@ -5,30 +5,38 @@ description:
   and usage limits in your AI Gateway project.
 ---
 
-Teams in the Zuplo AI Gateway are how users are granted access to AI providers
-and apps. Teams are hierarchical with access propagating downward. Teams are
-also where you define usage limits and
-[policy templates](./policy-templates.mdx).
+Teams in the Zuplo AI Gateway grant users access to apps. Teams are
+hierarchical, so access propagates to sub-teams only when the user also has at
+permission to view the Zuplo project that contains the AI Gateway. Team or
+sub-team membership doesn't grant Zuplo project access. Teams are also where you
+define usage limits and [policy templates](./policy-templates.mdx).
 
 ## Creating a Team
 
-Creating a team requires admin rights: on the project for a top-level team, or
-on the parent team for a sub-team. Members without them see a disabled **Create
-Team** button.
+Creating a team requires Admin rights on the Zuplo project or Zuplo account for
+a top-level team, or on the parent team for a sub-team. As a convenience, the
+Portal disables the **New Team** button when you don't have the required rights.
 
 <Stepper>
 
-1. Open the [Teams](https://portal.zuplo.com/+/account/project/ai/teams) tab of
-   your AI Gateway project in the Zuplo Portal.
+1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/teams)
+   tab of your AI Gateway project in the Zuplo Portal.
 
-1. Click on the **Create Team** button.
+1. Click **New Team** above the tree.
+
+1. Choose where the team sits. Once the gateway has at least one team, the
+   dialog shows a parent picker above the name field; leave it on **No parent
+   team** for a top-level team, or pick a team to create a sub-team under it.
 
 1. Enter the name of your team.
 
-1. Click **Create**
+1. Click **Create Team**
 
 </Stepper>
 
+You can also create a sub-team from the parent itself: select it in the tree and
+click **Create Sub-Team** in the team's header.
+
 After creating a team, use its tabs to configure it:
 
 - **Policies**—the team's [policy template](./policy-templates.mdx), the
@@ -39,13 +47,14 @@ After creating a team, use its tabs to configure it:
 
 ## Adding Team Members
 
-Team members are the users who belong to a team and can access the AI providers
-and apps associated with that team.
+Team members are the users who belong to a team and can access its apps,
+provided they also have permission to view the Zuplo project. AI provider access
+is separate and depends on the user's Zuplo account or Zuplo project role.
 
 <Stepper>
 
-1. Open the [Teams](https://portal.zuplo.com/+/account/project/ai/teams) tab of
-   your AI Gateway project in the Zuplo Portal.
+1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/teams)
+   tab of your AI Gateway project in the Zuplo Portal.
 
 1. Select the team you want to add members to.
 
@@ -54,20 +63,18 @@ and apps associated with that team.
 1. Click **Add Member**.
 
 1. Type the email address of the user you want to add. If the user is already a
-   member of your Zuplo account they will be directly added to the team. If they
-   don't have an account, they will be invited to join the account and then
-   added to the team.
+   member of your Zuplo account, they are added directly to the team. Otherwise,
+   they are invited to join the Zuplo account and then added to the team.
 
 1. Select the role for the user:
-   - **Member**: Can access the AI providers and apps assigned to the team.
-   - **Admin**: Can manage team settings and members, and access the AI
-     providers and apps assigned to the team.
+   - **Member**: Can access apps owned by the team.
+   - **Admin**: Can manage the team's settings, members, and apps.
 
      :::caution{title="The Member role requires RBAC"}
 
      Role-based access control (RBAC) is an optional enterprise add-on on your
-     Zuplo account. Without it, only the **Admin** role is selectable—every user
-     you add to a team is an Admin. For more information see the
+     Zuplo account. Without it, every invited user is an **Admin**. For more
+     information see the
      [document on roles and permissions](../articles/accounts/roles-and-permissions.mdx).
 
      :::

package/docs/ai-gateway/policies/akamai-ai-firewall.mdx

@@ -54,16 +54,17 @@ To protect every new app in a team, add the policy to the team's
 
 ## Options
 
-| Option                                  | Default    | What it does                                                                        |
-| --------------------------------------- | ---------- | ----------------------------------------------------------------------------------- |
-| `configurationId`                       | —          | Required. Your Akamai configuration                                                 |
-| `api-key`                               | —          | Required. Note the hyphen—`apiKey` is rejected                                      |
-| `applicationId`                         | —          | Optional Akamai application identifier                                              |
-| `endpoints`                             | All shapes | Which API shapes to inspect                                                         |
-| `onUnknownShape`                        | `deny`     | What to do with a request shape the policy can't read                               |
-| `streamingAccumulation.enabled`         | `true`     | Scan streaming completions. `false` stops scanning responses for streaming requests |
-| `streamingAccumulation.eventsInterval`  | `5`        | How many streamed events to buffer between checks                                   |
-| `streamingAccumulation.checkIntervalMs` | none       | Also check on a timer. Off unless set                                               |
+| Option                                  | Default    | What it does                                                                                                            |
+| --------------------------------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------- |
+| `configurationId`                       | —          | Required. Your Akamai configuration                                                                                     |
+| `api-key`                               | —          | Required. Note the hyphen—`apiKey` is rejected                                                                          |
+| `applicationId`                         | —          | Optional Akamai application identifier                                                                                  |
+| `endpoints`                             | All shapes | Which API shapes to inspect                                                                                             |
+| `onUnknownShape`                        | `deny`     | What to do with a request shape the policy can't read                                                                   |
+| `onError`                               | `block`    | What to do when the Akamai detect call itself fails—`block` answers `502`; `allow` lets the request through uninspected |
+| `streamingAccumulation.enabled`         | `true`     | Scan streaming completions. `false` stops scanning responses for streaming requests                                     |
+| `streamingAccumulation.eventsInterval`  | `5`        | How many streamed events to buffer between checks                                                                       |
+| `streamingAccumulation.checkIntervalMs` | none       | Also check on a timer. Off unless set                                                                                   |
 
 Unknown option keys are rejected.
 
@@ -91,18 +92,18 @@ Blocked requests are counted against the app and appear in its Dashboard—see
 
 ## Failure modes
 
-| Situation                                                      | Result                                    |
-| -------------------------------------------------------------- | ----------------------------------------- |
-| Options are invalid or incomplete                              | Fails closed—request rejected             |
-| The request body can't be read                                 | Fails closed—request rejected             |
-| An endpoint shape the policy can't inspect, such as embeddings | `400`, code `guardrail_uninspectable`     |
-| Akamai is unreachable, or returns an error                     | **Fails open**—traffic proceeds unguarded |
+| Situation                                                      | Result                                           |
+| -------------------------------------------------------------- | ------------------------------------------------ |
+| Options are invalid or incomplete                              | Fails closed—request rejected                    |
+| The request body can't be read                                 | Fails closed—request rejected                    |
+| An endpoint shape the policy can't inspect, such as embeddings | `400`, code `guardrail_uninspectable`            |
+| Akamai is unreachable, or returns an error                     | Fails closed—`502`, code `guardrail_unavailable` |
 
 :::caution
 
-Because the policy fails open, an expired Akamai key silently disables the
-firewall while the gateway keeps returning `200`s. Monitor blocked counts so a
-sudden drop to zero doesn't go unnoticed.
+With `onError: "allow"` the policy fails open instead: an expired Akamai key
+silently disables the firewall while the gateway keeps returning `200`s. Monitor
+blocked counts so a sudden drop to zero doesn't go unnoticed.
 
 :::
 

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

@@ -40,4 +40,4 @@ controls who can reach it.
 
 :::
 
-Each app's key appears on its app page—see [Apps](../apps.mdx).
+Each app's key appears on its **API Key** tab—see [Apps](../apps.mdx).

package/docs/ai-gateway/policies/comet-opik-tracing.mdx

@@ -41,8 +41,8 @@ app that should send traces:
 
 <Stepper>
 
-1. In your Comet account, create (or pick) a project and workspace and generate
-   an API key.
+1. In your Comet account, create (or pick) a Comet project and workspace and
+   generate an API key.
 
 2. In your gateway's repository, set the policy's settings and push:
 

package/docs/ai-gateway/policies/galileo-tracing.mdx

@@ -64,7 +64,7 @@ For each request, the policy automatically captures:
 1.  ### Obtain Galileo Credentials
     1. Sign up for a
        [Galileo](https://galileo.ai?utm_source=zuplo&utm_medium=web) account
-    2. Create a new project in your Galileo dashboard
+    2. Create a new Galileo project in your Galileo dashboard
     3. Generate an API key specifically for use with Zuplo
 
     :::note
@@ -154,7 +154,7 @@ Common issues and solutions:
 - **Authentication Errors**: Check that your Galileo API key is valid and has
   proper permissions
 - **Configuration Issues**: Ensure the policy declaration's environment
-  variables are set in your project settings
+  variables are set in your Zuplo project settings
 
 ## Additional Resources
 

package/docs/ai-gateway/policies/model-filtering.mdx

@@ -10,7 +10,7 @@ description:
 
 Model Filtering decides which models an app may use and creates the model
 selection the rest of the chain works from. Without it, an app can reach any
-model offered by the providers assigned to its [team](../teams.mdx).
+model offered by the providers configured for the Zuplo project.
 
 Configure each capability—completions, embeddings—in one of two modes. The modes
 are mutually exclusive per capability.

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

@@ -136,9 +136,10 @@ programmatically before the chain runs: place your own route policy between the
 loader and the executor.
 
 Both take a single option, `cacheTtlSeconds`, which sets how long the gateway
-caches a loaded app configuration. The default is `10` seconds, `10` is also the
-minimum, and a lower value throws a configuration error—as does any other option
-key.
+caches a loaded app configuration. The default is `10` seconds and `2` is the
+minimum—a lower value throws a configuration error, as does any other option
+key. New gateways scaffold the loader with `5`, so configuration changes take
+effect within about five seconds.
 
 ## Authentication
 

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

@@ -55,11 +55,13 @@ by the team policy template".
 
 A sub-team can use its parent team's template instead of defining its own,
 controlled by the **Inherit from parent** switch on the sub-team's Policies tab.
-While inheriting, the sub-team's template is read-only—it shows the parent's
-effective template. Turn the switch off to give the sub-team its own template:
-the editor starts from a copy of the parent's effective template, which you then
-adjust. Turning inheritance back on discards the sub-team's own template in
-favor of the parent's.
+The switch drafts like the page's other edits and applies when you click **Save
+changes**. While inheriting, the sub-team's template is read-only—it shows the
+parent's effective template. Turn the switch off to give the sub-team its own
+template: the editor starts from a copy of the parent's effective template,
+which you then adjust. Turning inheritance back on and saving discards the
+sub-team's own template in favor of the parent's—before you save, flip the
+switch again to restore your draft.
 
 ## Next steps
 

package/docs/ai-gateway/providers.mdx

@@ -19,6 +19,8 @@ Zuplo currently supports the following AI providers:
 - Google
 - Mistral
 - xAI (Grok)
+- [Bedrock Mantle](#bedrock-mantle)—Amazon Bedrock's compatible-APIs endpoint,
+  serving both OpenAI-compatible and Claude models
 - [Zuplo Demo](#zuplo-demo)—a free, keyless provider for trying the gateway
 - OpenAI-compatible [Custom Providers](./custom-providers.mdx) (such as Qwen,
   Kimi, etc)
@@ -32,6 +34,7 @@ The following capabilities are supported across providers:
 | Google                     | ✅               | ✅         | ❌        | ❌       |
 | Mistral                    | ✅               | ✅         | ❌        | ❌       |
 | xAI                        | ✅               | ✅         | ❌        | ❌       |
+| Bedrock Mantle             | ✅               | ✅         | ❌        | ✅       |
 | Zuplo Demo                 | ✅               | ❌         | ❌        | ❌       |
 | OpenAI-compatible (Custom) | ✅               | ✅         | ❌        | ❌       |
 
@@ -40,18 +43,48 @@ the native Anthropic Messages API (`/v1/messages`). See the
 [Universal API](./universal-api.mdx#supported-endpoints) for the endpoint each
 capability maps to.
 
+A custom provider must serve chat completions and embeddings under a `/v1` path
+segment on its API URL, and you enter that URL as an origin root—without the
+`/v1` suffix vendors usually publish. See
+[Custom Providers](./custom-providers.mdx#requirements) for the exact contract.
+
 Apps reference a provider's models as `providerName/model`—for example
 `openai/gpt-5-mini` or `anthropic/claude-sonnet-4-6`—where `providerName` is the
 name you give the provider configuration. See the
 [Universal API](./universal-api.mdx).
 
+## Bedrock Mantle
+
+**Bedrock Mantle** is Amazon Bedrock's compatible-APIs endpoint. It serves two
+model families from one host and one credential, so which capabilities apply
+depends on the model you call:
+
+- **OpenAI-compatible models** (for example `openai.gpt-oss-120b`) serve chat
+  completions and embeddings.
+- **Claude models** serve the native Anthropic Messages API, and chat
+  completions through the gateway's translation.
+
+Mantle endpoints are regional, so the provider dialog asks for an **AWS Region**
+instead of an endpoint URL and builds `https://bedrock-mantle.<region>.api.aws`
+from it. Enter a standard region code such as `us-east-1`.
+
+:::caution{title="Long-term API keys only"}
+
+Bedrock issues both long-term and short-term API keys, and the gateway accepts
+only long-term ones, which start with `ABSK`. Generate one in the AWS console
+under **Bedrock → API keys**. A short-term key (prefixed `bedrock-api-key-`)
+expires within 12 hours and is locked to the session that minted it, so the
+dialog rejects it rather than letting the connection break the same day.
+
+:::
+
 ## Zuplo Demo
 
 **Zuplo Demo** is a free provider that Zuplo operates so you can try the AI
-Gateway without a provider account. Add it like any other provider—see
-[Managing Providers](./managing-providers.mdx)—but skip the API key: the dialog
-doesn't ask for one, because your gateway authenticates to the demo service
-itself.
+Gateway without an account with an LLM provider. Add it like any other
+provider—see [Managing Providers](./managing-providers.mdx)—but skip the API
+key: the dialog doesn't ask for one, because your gateway authenticates to the
+demo service itself.
 
 The provider serves three demo persona models as chat completions, at no cost:
 
@@ -61,9 +94,9 @@ The provider serves three demo persona models as chat completions, at no cost:
 
 :::caution{title="Not for production use"}
 
-Zuplo Demo has daily per-account limits—plenty for exploring the gateway and
-demos, but not for real traffic. Swap in a keyed provider such as OpenAI or
-Anthropic before going live.
+Zuplo Demo has daily limits for each Zuplo account—plenty for exploring the
+gateway and demos, but not for real traffic. Swap in a keyed provider such as
+OpenAI or Anthropic before going live.
 
 :::
 

package/docs/ai-gateway/source-control.mdx

@@ -7,10 +7,11 @@ description:
   changes require a deploy versus applying live.
 ---
 
-Every AI Gateway project is backed by a Git repository that you own. The
-repository contains the gateway's routes and policy declarations, so gateway
-changes go through your normal review workflow, and custom policies are plain
-TypeScript files you commit alongside them.
+An AI Gateway is a Zuplo project configured for AI traffic. Every AI Gateway
+project is backed by a Git repository that you own. The repository contains the
+gateway's routes and policy declarations, so gateway changes go through your
+normal review workflow, and custom policies are plain TypeScript files you
+commit alongside them.
 
 ## Connecting a repository
 

package/docs/ai-gateway/teams.mdx

@@ -8,7 +8,7 @@ description:
 
 Teams are used to manage access to AI Gateway apps, set usage limits, and
 monitor activity. Each team can have multiple members and sub-teams. Use teams
-to group users by department, project, or any other logical grouping.
+to group users by department, initiative, or any other logical grouping.
 
 ## Teams & Apps
 
@@ -22,14 +22,19 @@ that apply to all of the team's apps combined.
 
 ## Members
 
-Members are the users who belong to a team. The permission of a member will
-depend on their role in the Zuplo account, project, and team.
+Members are the users who belong to a team. Their permissions combine their role
+in the Zuplo account, the Zuplo project that contains the AI Gateway, and the
+team.
 
 There are two roles at the team level:
 
-- **Member**: Can access the AI providers and apps assigned to the team.
-- **Admin**: Can manage team settings and members, and access the AI providers
-  and apps assigned to the team.
+- **Member**: Can access apps owned by the team.
+- **Admin**: Can manage the team's settings, members, and apps.
+
+Team roles don't grant access to AI providers. Providers are configured for the
+Zuplo project, and access to view or manage them depends on the user's Zuplo
+account or Zuplo project role. A user also needs permission to view that project
+before their team role grants access to the team's apps.
 
 For more information on roles and permissions, see the
 [document on roles and permissions](../articles/accounts/roles-and-permissions.mdx).
@@ -37,8 +42,8 @@ For more information on roles and permissions, see the
 **Additional Resources**
 
 - [Role Permissions](../articles/accounts/roles-and-permissions.mdx) - Details
-  on the roles available at the account and project levels.
+  on Zuplo account, Zuplo project, and AI Gateway team roles.
 - [Creating & Editing Teams](./managing-teams.mdx) - How to create and edit
   teams.
-- [Creating & Editing Apps](./managing-apps.mdx) - How to add, remove, and set
-  roles for project members.
+- [Creating & Editing Apps](./managing-apps.mdx) - How to create, configure, and
+  delete apps.

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

@@ -7,20 +7,20 @@ description:
 ---
 
 The Zuplo AI Gateway provides hierarchical usage limits and budget controls to
-manage LLM spending across your organization. Limits can be set at the gateway,
-team, and app levels.
+manage LLM spending across the gateway's Zuplo project. Limits can be set at the
+gateway, team, and app levels.
 
 ## Budget Hierarchy
 
 Limits at every level apply together—a request is blocked when _any_ level's
 limit is exceeded, and the error names the level that blocked it:
 
-- **Gateway** - Organization-wide limits (for example, $1,000/day), covering all
-  teams and apps combined
+- **Gateway** - Limits across the Zuplo project (for example, $1,000/day),
+  covering all teams and apps combined
 - **Teams** - Team-specific limits covering all of the team's apps combined (for
   example, $500/day for the Engineering team)
 - **Apps** - Per-app limits for granular control (for example, $10/day for a
-  hackathon project)
+  hackathon app)
 
 ## Where limits are configured
 
@@ -54,8 +54,8 @@ doesn't reset the period's usage.
 
 <Stepper>
 
-1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/apps) tab and
-   select the app.
+1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps)
+   tab and select the app.
 
 1. On the **Policies** tab, configure the **Budgets and Costs** policy (add it
    from **Add Policy** if the chain doesn't have it).
@@ -106,13 +106,13 @@ outage rejects the request rather than letting it escape the budget.
 
 Each app, team, and the gateway show current usage against their limits:
 
-1. Open the [Apps](https://portal.zuplo.com/+/account/project/ai/apps) or
-   [Teams](https://portal.zuplo.com/+/account/project/ai/teams) tab and select
-   an app or team
+1. Open the [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps)
+   tab and select an app or team
 2. The **Overview** tab shows daily and monthly usage—spend, tokens, and
    requests—with progress against any configured limits
-3. For request-level metrics (request count, token usage, time to first byte),
-   open the app's **Dashboard**
+3. The same tab's **Metrics** frame charts request count, token usage, and cost
+   over time; **View in Analytics** opens the full request-level breakdown
+   scoped to that app or team
 
 ## Related Resources
 

package/docs/articles/accounts/roles-and-permissions.mdx

@@ -1,11 +1,25 @@
 ---
 title: Role Permissions
+sidebar_label: Role Permissions
+description:
+  Compare account, project, and AI Gateway permissions for Admin, Developer,
+  Member, and team roles.
 ---
 
 <EnterpriseFeature name="Role Based Access Control" />
 
-Accounts in Zuplo can have multiple members with different roles. Each account
-member can be a role that defines the permissions they have in the account.
+:::note
+
+Without the role-based access control (RBAC) enterprise add-on, every user
+invited to an account is an **Admin**. The **Developer** and **Member**
+distinctions below apply only when RBAC is enabled.
+
+:::
+
+A Zuplo account is the top-level container for members and projects. Account
+roles grant permissions across that container and can also grant access to its
+projects. A project belongs to one Zuplo account, and project roles grant access
+only to that project.
 
 The following roles are available at the account level:
 
@@ -35,7 +49,8 @@ The following roles are available at the project level:
 
 ## Account Role Permissions
 
-The following table outlines the permissions available to each account role.
+The following table outlines the permissions granted directly by each Zuplo
+account role.
 
 | Resource       | Action          | Admin | Developer | Member |
 | -------------- | --------------- | ----- | --------- | ------ |
@@ -43,6 +58,12 @@ The following table outlines the permissions available to each account role.
 |                | View            | ✅    | ✅        | ✅     |
 | Projects       | Edit            | ✅    | ❌        | ❌     |
 |                | View            | ✅    | ✅        | ❌     |
+| AI Providers   | Edit            | ✅    | ❌        | ❌     |
+|                | View            | ✅    | ✅        | ❌     |
+| AI Teams       | Manage          | ✅    | ❌        | ❌     |
+|                | View            | ✅    | ❌        | ❌     |
+| AI Apps        | Manage          | ✅    | ❌        | ❌     |
+|                | View            | ✅    | ❌        | ❌     |
 | Custom Domains | Edit            | ✅    | ❌        | ❌     |
 |                | View            | ✅    | ✅        | ❌     |
 | Tunnels        | Edit            | ✅    | ❌        | ❌     |
@@ -58,12 +79,19 @@ The following table outlines the permissions available to each account role.
 
 ## Project Role Permissions
 
-The following table outlines the permissions available to each project role.
+The following table outlines the permissions granted directly by each Zuplo
+project role.
 
 | Resource              | Environment | Action | Admin | Developer | Member |
 | --------------------- | ----------- | ------ | ----- | --------- | ------ |
 | Project               |             | Edit   | ✅    | ❌        | ❌     |
 |                       |             | View   | ✅    | ✅        | ✅     |
+| AI Providers          |             | Edit   | ✅    | ❌        | ❌     |
+|                       |             | View   | ✅    | ✅        | ✅     |
+| AI Teams              |             | Manage | ✅    | ❌        | ❌     |
+|                       |             | View   | ✅    | ❌        | ❌     |
+| AI Apps               |             | Manage | ✅    | ❌        | ❌     |
+|                       |             | View   | ✅    | ❌        | ❌     |
 | Environment           | Production  | Edit   | ✅    | ❌        | ❌     |
 |                       |             | View   | ✅    | ✅        | ✅     |
 |                       |             | Deploy | ✅    | ❌        | ❌     |
@@ -106,3 +134,11 @@ The following table outlines the permissions available to each project role.
 |                       |             | View   | ✅    | ✅        | ✅     |
 |                       | Development | Edit   | ✅    | ❌        | ❌     |
 |                       |             | View   | ✅    | ✅        | ✅     |
+
+The AI Teams and AI Apps rows show project-wide access granted directly by a
+Zuplo account or Zuplo project role. A [team role](../../ai-gateway/teams.mdx)
+can grant additional access to a specific team and its apps, but only when the
+user also has permission to view the associated Zuplo project. A team **Admin**
+can manage the team's settings, members, and apps, while a team **Member** can
+access its apps. AI provider permissions come only from the user's Zuplo account
+or Zuplo project role; team membership doesn't grant provider access.

package/docs/policies/akamai-ai-firewall/schema.json

@@ -77,6 +77,14 @@
                 }
               },
               "additionalProperties": false
+            },
+            "onError": {
+              "type": "string",
+              "title": "On Firewall Error",
+              "x-advanced": true,
+              "description": "What to do when the Akamai detect call itself fails (invalid API key, rate limit, outage). 'block' (the default) fails closed and returns a 502 so unverified content is never served; 'allow' fails open and lets the request through without inspection. An onError value in the AI Gateway app configuration takes precedence over this option.",
+              "enum": ["block", "allow"],
+              "default": "block"
             }
           },
           "required": ["configurationId", "api-key"],
@@ -88,6 +96,7 @@
           "export": "AkamaiAIFirewallInboundPolicy",
           "module": "$import(@zuplo/runtime)",
           "options": {
+            "onError": "block",
             "streamingAccumulation": {
               "enabled": true,
               "eventsInterval": 5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "7.1.9",
+  "version": "7.1.10",
   "type": "module",
   "description": "The programmable API Gateway",
   "author": "Zuplo, Inc.",
@@ -19,9 +19,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "7.1.9",
-    "@zuplo/core": "7.1.9",
-    "@zuplo/runtime": "7.1.9",
-    "@zuplo/test": "7.1.9"
+    "@zuplo/cli": "7.1.10",
+    "@zuplo/core": "7.1.10",
+    "@zuplo/runtime": "7.1.10",
+    "@zuplo/test": "7.1.10"
   }
 }