zuplo 7.6.9 → 7.6.10

package/docs/ai-gateway/integrations/claude-code.mdx

@@ -6,10 +6,9 @@ description:
   authenticated, metered, and routed by the gateway.
 ---
 
-The Zuplo AI Gateway supports the [Anthropic](https://docs.claude.com/en/home)
-`/v1/messages` API endpoint. This means that you can configure
-[Claude Code](https://www.claude.com/product/claude-code) to work seamlessly via
-the AI Gateway.
+You can configure [Claude Code](https://www.claude.com/product/claude-code) to
+send its model requests through the Zuplo AI Gateway, so the gateway
+authenticates, meters, and routes every Claude Code session.
 
 ## Claude Code Setup
 
@@ -25,25 +24,37 @@ the AI Gateway.
 
 4. Copy the **API URL** and **API Key** shown at the top of the app page
 
-5. Add the API key and gateway URL to your environment, or Claude Code settings,
-   using either approach below
+5. Add the API key, gateway URL, and model mappings to `.claude/settings.json`
 
 </Stepper>
 
-### Environment
+### Before copying: replace the provider name
 
-```
-ANTHROPIC_AUTH_TOKEN=<your-ai-gateway-app-api-key>
-ANTHROPIC_BASE_URL=https://my-gateway-main-2e18f50.zuplo.app/config_fe0a04972d2848e0a94ae4b8bcd1497e
-ANTHROPIC_MODEL=anthropic/claude-sonnet-5
-ANTHROPIC_SMALL_FAST_MODEL=anthropic/claude-haiku-4-5
-ANTHROPIC_DEFAULT_OPUS_MODEL=anthropic/claude-opus-5
-ANTHROPIC_DEFAULT_SONNET_MODEL=anthropic/claude-sonnet-5
-ANTHROPIC_DEFAULT_HAIKU_MODEL=anthropic/claude-haiku-4-5
-```
+:::warning
+
+The examples below assume your provider is named `anthropic`. Replace that
+prefix with the name of **your** provider before copying the configuration. For
+example, a provider named `my-anthropic` routes `my-anthropic/claude-sonnet-5`,
+while a Bedrock provider named `bedrock` routes
+`bedrock/anthropic.claude-sonnet-5`. The model part must be an id that provider
+understands.
+
+:::
+
+The gateway routes every request using `providerName/model`. The provider prefix
+picks which of your providers handles the request — a gateway can contain
+several providers that serve Anthropic models.
 
 ### Using settings.json
 
+You can configure Claude Code either globally or per project by editing the
+settings file:
+
+- **Global:** `~/.claude/settings.json`
+- **Project-specific:** `.claude/settings.json` in your project directory
+
+Add the following environment configuration to the settings file:
+
 ```json
 {
   "env": {
@@ -53,7 +64,8 @@ ANTHROPIC_DEFAULT_HAIKU_MODEL=anthropic/claude-haiku-4-5
     "ANTHROPIC_SMALL_FAST_MODEL": "anthropic/claude-haiku-4-5",
     "ANTHROPIC_DEFAULT_OPUS_MODEL": "anthropic/claude-opus-5",
     "ANTHROPIC_DEFAULT_SONNET_MODEL": "anthropic/claude-sonnet-5",
-    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "anthropic/claude-haiku-4-5"
+    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "anthropic/claude-haiku-4-5",
+    "ANTHROPIC_DEFAULT_FABLE_MODEL": "anthropic/claude-fable-5"
   }
 }
 ```
@@ -68,20 +80,7 @@ Claude Code appends `/v1/messages` to the base URL itself, so
 Restart Claude and it will switch to using your new AI Gateway configuration and
 all your Claude Code LLM requests will route through the AI Gateway.
 
-### Model names include your provider's name
-
-The gateway routes every request by a model reference of the form
-`providerName/model`, where `providerName` is the name of the provider **you
-configured** in your gateway — not a fixed vendor id. A single gateway can
-contain several providers that serve Anthropic models — Anthropic itself, Google
-Vertex AI, AWS Bedrock, or multiple keyed instances of the same vendor — so the
-gateway never guesses a provider for a bare model name like `claude-sonnet-5`.
-
-The examples on this page assume the provider is named `anthropic`. Use the name
-of your own provider: a provider named `my-anthropic` routes
-`my-anthropic/claude-sonnet-5`, and a Bedrock provider named `bedrock` routes
-`bedrock/anthropic.claude-sonnet-5` (the model part is always the id the
-provider itself understands).
+### Configure every Claude Code model variable
 
 The model ids in these examples reflect what was current when this page was
 written, and ids differ across providers — a Bedrock provider serves different
@@ -96,8 +95,10 @@ the model variables above must be set to a prefixed reference:
   built-in default model unprefixed and the first request fails.
 - `ANTHROPIC_SMALL_FAST_MODEL` — the model for background tasks.
 - `ANTHROPIC_DEFAULT_OPUS_MODEL`, `ANTHROPIC_DEFAULT_SONNET_MODEL`,
-  `ANTHROPIC_DEFAULT_HAIKU_MODEL` — what the `opus`/`sonnet`/`haiku` aliases
-  resolve to, so `claude --model opus` and `/model sonnet` keep working.
+  `ANTHROPIC_DEFAULT_HAIKU_MODEL`, `ANTHROPIC_DEFAULT_FABLE_MODEL` — what the
+  `opus`/`sonnet`/`haiku`/`fable` aliases resolve to, so `claude --model opus`
+  and `/model sonnet` keep working. In these examples,
+  `ANTHROPIC_DEFAULT_FABLE_MODEL` maps `fable` to `anthropic/claude-fable-5`.
 
 :::caution{title='HTTP 400: model must use "providerName/model"'}
 

package/docs/ai-gateway/integrations/claude-desktop.mdx

@@ -0,0 +1,157 @@
+---
+title: Claude Desktop
+sidebar_label: Claude Desktop
+description:
+  Point Claude Desktop at an AI Gateway app so every Chat, Cowork, and Code
+  session is authenticated, metered, and routed by the gateway.
+---
+
+[Claude Desktop](https://claude.com/download) can use the Zuplo AI Gateway as
+its inference provider, so the gateway authenticates, meters, and routes every
+Chat, Cowork, and Code session started from the desktop app.
+
+This page covers routing Claude Desktop's model requests through the AI Gateway.
+To give Claude Desktop tools from a Zuplo MCP route instead, see
+[Connect Claude Desktop and Claude.ai](../../mcp-gateway/connect-clients/claude-desktop.mdx).
+
+## Claude Desktop Setup
+
+<Stepper>
+
+1. Create a [new provider](../managing-providers.mdx) in the AI Gateway for
+   Anthropic
+
+2. [Set up a new team](../managing-teams.mdx)
+
+3. Create a [new app](../managing-apps.mdx) to use with Claude Desktop and
+   assign it to the team you created
+
+4. Copy the **API URL** and **API Key** shown at the top of the app page
+
+5. Enter the API URL, API key, and model list in Claude Desktop's third-party
+   inference settings
+
+</Stepper>
+
+### Before copying: replace the provider name
+
+:::warning
+
+The examples below assume your provider is named `anthropic`. Replace that
+prefix with the name of **your** provider before copying the configuration. For
+example, a provider named `my-anthropic` routes `my-anthropic/claude-sonnet-5`,
+while a Bedrock provider named `bedrock` routes
+`bedrock/anthropic.claude-sonnet-5`. The model part must be an id that provider
+understands.
+
+:::
+
+The gateway routes every request using `providerName/model`. The provider prefix
+picks which of your providers handles the request — a gateway can contain
+several providers that serve Anthropic models.
+
+### Configure third-party inference
+
+Configure Claude Desktop's inference provider in its in-app configuration
+window, available on macOS and Windows:
+
+<Stepper>
+
+1. From the menu bar (macOS) or the application menu (Windows), select **Help →
+   Troubleshooting → Enable Developer Mode**.
+
+2. Open **Developer → Configure Third-Party Inference**.
+
+3. In the **Connection** section, set **Inference provider** to **Gateway**.
+
+4. In the **Gateway credentials** card, set **Gateway base URL** to the app's
+   API URL, for example
+   `https://my-gateway-main-2e18f50.zuplo.app/config_fe0a04972d2848e0a94ae4b8bcd1497e`,
+   and **Gateway API key** to the app's API key.
+
+5. Leave **Credential kind** set to **Static API key** and **Gateway auth
+   scheme** set to **Bearer**.
+
+6. In the **Models** section, add the models the app may use to the **Model
+   list**. See [Add models to the Model list](#add-models-to-the-model-list).
+
+7. Click **Apply locally**. Claude Desktop writes the configuration and
+   relaunches into it.
+
+</Stepper>
+
+:::note
+
+Claude Desktop appends `/v1/messages` to the base URL itself, so **Gateway base
+URL** is the app's URL _without_ the `/v1` suffix.
+
+:::
+
+:::caution{title="Keep the auth scheme set to Bearer"}
+
+The gateway reads the API key from the `Authorization: Bearer` header, so keep
+**Gateway auth scheme** set to **Bearer**. Likewise, keep **Credential kind**
+set to **Static API key** — AI Gateway apps authenticate with their own API
+keys, not identity-provider tokens.
+
+:::
+
+### Add models to the Model list
+
+The **Model list** in the **Models** section overrides the model list Claude
+Desktop discovers on its own. Click **Add** once per model the app may use, and
+fill in each entry:
+
+- **Model ID** — the full `providerName/model` reference, for example
+  `anthropic/claude-sonnet-5`. A bare id such as `claude-sonnet-5` fails to
+  route through the gateway.
+- **Display name** — the name shown in the model picker, for example
+  `Claude Sonnet 5`. Leave it blank and Claude Desktop formats a name from the
+  id.
+- **Offer 1M-context variant** — leave this off unless your provider's
+  deployment accepts 1M-token context for the model.
+- **Tier alias** — the Claude tier (Opus, Sonnet, Haiku, or Fable) this model
+  stands in for. Setting it pins what the bare alias (for example `opus`)
+  resolves to, so tier names route to your prefixed model reference.
+
+The first entry is the default selection in the model picker. Include a
+Haiku-tier model — Claude Desktop runs background and sub-agent tasks on a
+small, fast model.
+
+The model ids in these examples reflect what was current when this page was
+written, and ids differ across providers — a Bedrock provider serves different
+ids than Anthropic directly, and availability can vary by region. Check
+[your provider's page](../managing-providers.mdx) in the portal for the models
+it currently serves, and use those ids.
+
+The app's
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy controls which models the app may use.
+
+### Verify the configuration
+
+After Claude Desktop relaunches, send a message in a Chat conversation and start
+a Cowork session. Both requests route through the gateway and count against the
+[app](../managing-apps.mdx) in the Zuplo Portal, as do Code sessions started
+from the desktop app. Terminal Claude Code sessions outside the desktop app use
+a separate configuration — see [Claude Code](./claude-code.mdx).
+
+:::caution{title='HTTP 400: model must use "providerName/model"'}
+
+If a request fails with `The request body model must use "providerName/model"`,
+the selected model reference is missing its provider prefix. Give every entry in
+the model list a full `providerName/model` reference.
+
+:::
+
+### Deploy to a fleet
+
+To roll the configuration out to many devices, use the configuration window's
+**Export** menu instead of **Apply locally**. It generates a `.mobileconfig`
+profile for macOS MDM tools such as Jamf, a `.reg` policy file for Intune or
+Group Policy, and related deployment artifacts. Managed configuration takes
+precedence over local settings, so users can't point the app at a different
+endpoint. For the deployment workflow and the full configuration key reference,
+see Anthropic's
+[Deploy Claude Desktop with an LLM gateway](https://claude.com/docs/third-party/claude-desktop/gateway)
+and [Deploy with MDM](https://claude.com/docs/third-party/claude-desktop/mdm).

package/docs/mcp-gateway/connect-clients/claude-desktop.mdx

@@ -153,6 +153,8 @@ file-based configuration.
 ## Related
 
 - [Connect MCP clients overview](./overview.mdx)
+- To route Claude Desktop's model requests through Zuplo instead, see the
+  [Claude Desktop AI Gateway integration](../../ai-gateway/integrations/claude-desktop.mdx)
 - Anthropic's official guide:
   [Connect to remote MCP servers](https://modelcontextprotocol.io/docs/develop/connect-remote-servers)
 - Anthropic's setup article:

package/docs/policies/auth0-jwt-auth-inbound/doc.md

@@ -121,5 +121,10 @@ When configured, this enables OAuth clients to find metadata information about
 how to interact with your OAuth 2.0 protected resources according to
 [`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
 
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
 See [this document](/docs/articles/oauth-authentication) for more information
 about OAuth authorization in Zuplo.

package/docs/policies/auth0-jwt-auth-inbound/schema.json

@@ -56,7 +56,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/docs/policies/clerk-jwt-auth-inbound/doc.md

@@ -81,5 +81,10 @@ When configured, this enables OAuth clients to find metadata information about
 how to interact with your OAuth 2.0 protected resources according to
 [`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
 
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
 See [this document](/docs/articles/oauth-authentication) for more information
 about OAuth authorization in Zuplo.

package/docs/policies/clerk-jwt-auth-inbound/schema.json

@@ -51,7 +51,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/docs/policies/cognito-jwt-auth-inbound/doc.md

@@ -0,0 +1,17 @@
+## OAuth 2.0 Protected Resource Metadata
+
+The Cognito JWT Auth policy supports OAuth protected resource metadata
+discovery. To enable this feature, set the `oAuthResourceMetadataEnabled` option
+to `true` and add the
+[`OAuthProtectedResourcePlugin` to `modules/zuplo.runtime.ts`](/docs/programmable-api/oauth-protected-resource-plugin).
+When configured, this enables OAuth clients to find metadata information about
+how to interact with your OAuth 2.0 protected resources according to
+[`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
+
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
+See [this document](/docs/articles/oauth-authentication) for more information
+about OAuth authorization in Zuplo.

package/docs/policies/cognito-jwt-auth-inbound/schema.json

@@ -56,7 +56,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/docs/policies/firebase-jwt-inbound/doc.md

@@ -0,0 +1,17 @@
+## OAuth 2.0 Protected Resource Metadata
+
+The Firebase JWT Auth policy supports OAuth protected resource metadata
+discovery. To enable this feature, set the `oAuthResourceMetadataEnabled` option
+to `true` and add the
+[`OAuthProtectedResourcePlugin` to `modules/zuplo.runtime.ts`](/docs/programmable-api/oauth-protected-resource-plugin).
+When configured, this enables OAuth clients to find metadata information about
+how to interact with your OAuth 2.0 protected resources according to
+[`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
+
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
+See [this document](/docs/articles/oauth-authentication) for more information
+about OAuth authorization in Zuplo.

package/docs/policies/firebase-jwt-inbound/schema.json

@@ -51,7 +51,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/docs/policies/okta-jwt-auth-inbound/doc.md

@@ -0,0 +1,23 @@
+## OAuth 2.0 Protected Resource Metadata
+
+The Okta JWT Auth policy supports OAuth protected resource metadata discovery.
+To enable this feature, set the `oAuthResourceMetadataEnabled` option to `true`
+and add the
+[`OAuthProtectedResourcePlugin` to `modules/zuplo.runtime.ts`](/docs/programmable-api/oauth-protected-resource-plugin).
+When configured, this enables OAuth clients to find metadata information about
+how to interact with your OAuth 2.0 protected resources according to
+[`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
+
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
+Okta custom authorization servers always advertise the `device_sso` and
+`interclient_access` scopes in their own metadata and reject authorization
+requests that combine them with your scopes (`illegal_scope_combination`). Set
+`scopesSupported` on the plugin when this policy protects an MCP server, so
+clients never fall back to that list.
+
+See [this document](/docs/articles/oauth-authentication) for more information
+about OAuth authorization in Zuplo.

package/docs/policies/okta-jwt-auth-inbound/schema.json

@@ -56,7 +56,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/docs/policies/open-id-jwt-auth-inbound/doc.md

@@ -56,3 +56,21 @@ export async function myHandler(request: ZuploRequest, context: ZuploContext) {
 For a complete example of using the user object in a
 [RequestHandler](../handlers/custom-handler.md), see
 [Setting up JWT auth with Auth0](../policies/auth0-jwt-auth-inbound.md).
+
+## OAuth 2.0 Protected Resource Metadata
+
+The OpenID JWT Auth policy supports OAuth protected resource metadata discovery.
+To enable this feature, set the `oAuthResourceMetadataEnabled` option to `true`
+and add the
+[`OAuthProtectedResourcePlugin` to `modules/zuplo.runtime.ts`](/docs/programmable-api/oauth-protected-resource-plugin).
+When configured, this enables OAuth clients to find metadata information about
+how to interact with your OAuth 2.0 protected resources according to
+[`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
+
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
+See [this document](/docs/articles/oauth-authentication) for more information
+about OAuth authorization in Zuplo.

package/docs/policies/open-id-jwt-auth-inbound/schema.json

@@ -89,7 +89,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           },
           "examples": [

package/docs/policies/propel-auth-jwt-inbound/doc.md

@@ -84,5 +84,10 @@ When configured, this enables OAuth clients to find metadata information about
 how to interact with your OAuth 2.0 protected resources according to
 [`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
 
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.
+
 See [this document](/docs/articles/oauth-authentication) for more information
 about OAuth authorization in Zuplo.

package/docs/policies/propel-auth-jwt-inbound/schema.json

@@ -56,7 +56,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/docs/policies/supabase-jwt-auth-inbound/doc.md

@@ -27,3 +27,8 @@ to `true` and add the
 When configured, this enables OAuth clients to find metadata information about
 how to interact with your OAuth 2.0 protected resources according to
 [`RFC 9728`](https://datatracker.ietf.org/doc/html/rfc9728).
+
+When the plugin is configured with `scopesSupported`, the 401 response also
+lists those scopes in the `scope` parameter of its `WWW-Authenticate` header, so
+MCP clients request exactly the scopes your resource expects instead of every
+scope the authorization server advertises.

package/docs/policies/supabase-jwt-auth-inbound/schema.json

@@ -66,7 +66,7 @@
               "type": "boolean",
               "default": false,
               "x-advanced": true,
-              "description": "Flag that determines whether OAuth protected resource metadata is enabled."
+              "description": "Enables OAuth 2.0 Protected Resource Metadata discovery (RFC 9728). When `true`, requests without a bearer token receive a 401 whose `WWW-Authenticate` header points `resource_metadata` at the `/.well-known/oauth-protected-resource` document for the request path and, when the `OAuthProtectedResourcePlugin` declares `scopesSupported`, lists those scopes in `scope`. Requires the `OAuthProtectedResourcePlugin` in `zuplo.runtime.ts` or a user-defined route at that path."
             }
           }
         }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "7.6.9",
+  "version": "7.6.10",
   "type": "module",
   "description": "The official Zuplo CLI for local development and platform management",
   "homepage": "https://zuplo.com/docs/cli/overview",
@@ -32,9 +32,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "7.6.9",
-    "@zuplo/core": "7.6.9",
-    "@zuplo/runtime": "7.6.9",
-    "@zuplo/test": "7.6.9"
+    "@zuplo/cli": "7.6.10",
+    "@zuplo/core": "7.6.10",
+    "@zuplo/runtime": "7.6.10",
+    "@zuplo/test": "7.6.10"
   }
 }