zuplo 6.73.8 → 6.73.11

package/docs/policies/ai-gateway-model-routing-v2-inbound/doc.md

@@ -1,7 +1,8 @@
 # AI Gateway Model Routing (v2) Policy
 
 The AI Gateway Model Routing (v2) policy applies declarative allow or block
-rules to AI requests. Configured targets use `provider/model` form and split on
+rules to AI requests. The Provider Name configured in the Zuplo Portal is its
+routing address: configured targets use `providerName/model` form and split on
 the first slash, so provider-specific model IDs can contain additional slashes.
 
 ## Configuration
@@ -53,23 +54,23 @@ An allow-list entry can be a string shorthand or a full target object:
 }
 ```
 
-The first slash separates the provider from the model. Model IDs may contain
-additional slashes, such as `my-fireworks/accounts/fireworks/models/llama-v3`.
-Provider and model matching is case-insensitive. In curated mode the configured
-casing is preserved when the request is sent upstream.
+The first slash separates the Provider Name from the model. Model IDs may
+contain additional slashes, such as
+`my-fireworks/accounts/fireworks/models/llama-v3`. Provider Name and model
+matching is case-insensitive. In curated mode the configured casing is preserved
+when the request is sent upstream.
 
 ## Request behavior
 
-Clients can send a bare model name or `provider/model`. In curated mode, a bare
-name selects the one allow-list `main` with that model name; an ambiguous name
-receives a 400 response asking for `provider/model`. In block-list mode, bare
-Chat Completions and Embeddings models use OpenAI, while native Messages and
-Responses models use Anthropic and OpenAI respectively.
+Every non-empty request model must use `providerName/model`. A bare model name
+receives an actionable 400 response. When the model is omitted, curated mode
+uses allow-list entry zero; block-list mode rejects the request because it has
+no default.
 
 `/v1/embeddings` uses the `embeddings` rules; Chat Completions, Responses, and
-Anthropic Messages use `completions` rules. A request containing `/` is treated
-as `provider/model`, so model IDs containing slashes must include their
-provider.
+Anthropic Messages use `completions` rules. The first slash separates the
+Provider Name, so model IDs containing slashes remain intact after that
+separator.
 
 The pass-through routes are provider-native: `/v1/messages` accepts Anthropic
 targets and `/v1/responses` accepts OpenAI targets. A request that explicitly
@@ -104,8 +105,8 @@ with whatever logic it wants:
   handler consumes.
 
 A per-capability target is the same `AIGatewayRouteTarget` shape used by
-`allowList` entries: a `"provider/model"` string, or an object with `main` and
-optional `backup`, `fallbackTimeoutSeconds`, and `quotaFallback`.
+`allowList` entries: a `"providerName/model"` string, or an object with `main`
+and optional `backup`, `fallbackTimeoutSeconds`, and `quotaFallback`.
 
 ```typescript
 import {
@@ -120,7 +121,9 @@ export default async function routeModel(
   context: ZuploContext
 ) {
   const providers = await AIGatewayModels.load(context);
-  const openAI = providers.find((provider) => provider.name === "openai");
+  const openAI = providers.find(
+    (provider) => provider.providerName === "openai"
+  );
   const model = openAI?.models.find(
     (candidate) =>
       candidate.capability === "completions" && candidate.status === "active"

package/docs/policies/ai-gateway-model-routing-v2-inbound/intro.md

@@ -1,18 +1,17 @@
 The AI Gateway Model Routing (v2) policy selects models with either a curated
 `allowList` or an open-but-filtered `blockList`. Allow-list entries accept the
-string shorthand `"provider/model"` or an object with `main`, `backup`,
+string shorthand `"providerName/model"` or an object with `main`, `backup`,
 `fallbackTimeoutSeconds`, and `quotaFallback`; entry zero is the default when a
 curated request omits `model`, while block-list mode requires every request to
 name a model.
 
-Request model references split on the first slash, match provider and model
-case-insensitively, and preserve configured casing upstream. Clients may send a
-bare model name: curated rules resolve a unique allow-list match, while open
-rules default to OpenAI except on Anthropic-native Messages routes. Bodyless
-Responses management operations need curated or custom routing because
-block-list mode has no default. Retry backups apply to translated Chat
-Completions and Embeddings, not native pass-through routes; quota fallbacks
-remain independent and fallbacks do not chain.
+Request model references use `providerName/model`, split on the first slash,
+match provider and model case-insensitively, and preserve configured casing
+upstream. A non-empty request model without a Provider Name is rejected with an
+actionable 400. Bodyless Responses management operations need curated or custom
+routing because block-list mode has no default. Retry backups apply to
+translated Chat Completions and Embeddings, not native pass-through routes;
+quota fallbacks remain independent and fallbacks do not chain.
 
 Custom inbound policies can inspect `AIGatewayModels.load(context)` and call
 `AIGatewayModelRouting.set(context, routing)` to select the same target without

package/docs/policies/ai-gateway-model-routing-v2-inbound/schema.json

@@ -31,7 +31,7 @@
         "options": {
           "type": "object",
           "title": "AIGatewayModelRoutingV2InboundPolicyOptions",
-          "description": "Options for allowing or blocking provider/model routes for each AI Gateway capability.",
+          "description": "Options for allowing or blocking providerName/model routes for each AI Gateway capability.",
           "additionalProperties": false,
           "required": ["models"],
           "properties": {
@@ -67,12 +67,12 @@
                               "minItems": 1,
                               "items": {
                                 "title": "Route Target",
-                                "description": "A provider/model string shorthand or a full model route target.",
+                                "description": "A providerName/model string shorthand or a full model route target.",
                                 "oneOf": [
                                   {
                                     "type": "string",
                                     "title": "Provider and Model",
-                                    "description": "A model reference in provider/model form, split on the first slash.",
+                                    "description": "A model reference in providerName/model form, split on the first slash.",
                                     "pattern": "^[^/\\s]+/.+$"
                                   },
                                   {
@@ -85,13 +85,13 @@
                                       "main": {
                                         "type": "string",
                                         "title": "Provider and Model",
-                                        "description": "A model reference in provider/model form, split on the first slash.",
+                                        "description": "A model reference in providerName/model form, split on the first slash.",
                                         "pattern": "^[^/\\s]+/.+$"
                                       },
                                       "backup": {
                                         "type": "string",
                                         "title": "Provider and Model",
-                                        "description": "A model reference in provider/model form, split on the first slash.",
+                                        "description": "A model reference in providerName/model form, split on the first slash.",
                                         "pattern": "^[^/\\s]+/.+$"
                                       },
                                       "fallbackTimeoutSeconds": {
@@ -105,7 +105,7 @@
                                       "quotaFallback": {
                                         "type": "string",
                                         "title": "Provider and Model",
-                                        "description": "A model reference in provider/model form, split on the first slash.",
+                                        "description": "A model reference in providerName/model form, split on the first slash.",
                                         "pattern": "^[^/\\s]+/.+$"
                                       }
                                     }
@@ -128,12 +128,12 @@
                             "blockList": {
                               "type": "array",
                               "title": "Blocked Models",
-                              "description": "Configured provider/model targets rejected in open-but-filtered mode; requests may use a bare model name or provider/model.",
+                              "description": "Configured providerName/model targets rejected in open-but-filtered mode.",
                               "minItems": 1,
                               "items": {
                                 "type": "string",
                                 "title": "Provider and Model",
-                                "description": "A model reference in provider/model form, split on the first slash.",
+                                "description": "A model reference in providerName/model form, split on the first slash.",
                                 "pattern": "^[^/\\s]+/.+$"
                               }
                             }
@@ -168,12 +168,12 @@
                               "minItems": 1,
                               "items": {
                                 "title": "Route Target",
-                                "description": "A provider/model string shorthand or a full model route target.",
+                                "description": "A providerName/model string shorthand or a full model route target.",
                                 "oneOf": [
                                   {
                                     "type": "string",
                                     "title": "Provider and Model",
-                                    "description": "A model reference in provider/model form, split on the first slash.",
+                                    "description": "A model reference in providerName/model form, split on the first slash.",
                                     "pattern": "^[^/\\s]+/.+$"
                                   },
                                   {
@@ -186,13 +186,13 @@
                                       "main": {
                                         "type": "string",
                                         "title": "Provider and Model",
-                                        "description": "A model reference in provider/model form, split on the first slash.",
+                                        "description": "A model reference in providerName/model form, split on the first slash.",
                                         "pattern": "^[^/\\s]+/.+$"
                                       },
                                       "backup": {
                                         "type": "string",
                                         "title": "Provider and Model",
-                                        "description": "A model reference in provider/model form, split on the first slash.",
+                                        "description": "A model reference in providerName/model form, split on the first slash.",
                                         "pattern": "^[^/\\s]+/.+$"
                                       },
                                       "fallbackTimeoutSeconds": {
@@ -206,7 +206,7 @@
                                       "quotaFallback": {
                                         "type": "string",
                                         "title": "Provider and Model",
-                                        "description": "A model reference in provider/model form, split on the first slash.",
+                                        "description": "A model reference in providerName/model form, split on the first slash.",
                                         "pattern": "^[^/\\s]+/.+$"
                                       }
                                     }
@@ -229,12 +229,12 @@
                             "blockList": {
                               "type": "array",
                               "title": "Blocked Models",
-                              "description": "Configured provider/model targets rejected in open-but-filtered mode; requests may use a bare model name or provider/model.",
+                              "description": "Configured providerName/model targets rejected in open-but-filtered mode.",
                               "minItems": 1,
                               "items": {
                                 "type": "string",
                                 "title": "Provider and Model",
-                                "description": "A model reference in provider/model form, split on the first slash.",
+                                "description": "A model reference in providerName/model form, split on the first slash.",
                                 "pattern": "^[^/\\s]+/.+$"
                               }
                             }

package/docs/policies/graphql-cache-inbound/doc.md

@@ -1,6 +1,6 @@
 The GraphQL Cache policy stores successful GraphQL query responses in a
-[ZoneCache](https://zuplo.com/docs/programmable-api/zone-cache) and serves later,
-identical queries directly from the edge.
+[ZoneCache](https://zuplo.com/docs/programmable-api/zone-cache) and serves
+later, identical queries directly from the edge.
 
 ### How caching works
 

package/docs/policies/mcp-token-exchange-inbound/doc.md

@@ -124,12 +124,12 @@ in two server-to-server steps:
    Resource Authorization Server's token endpoint using the `jwt-bearer` grant
    and receives the upstream access token it attaches to the forwarded request.
 
-Use this mode in enterprise deployments where the gateway and the upstream
-trust the same identity provider (for example, Okta Cross-App Access), so
-upstream access follows the caller's identity without a per-user upstream
-consent flow. The `user-oauth`/`shared-oauth` options — `scopes`,
-`scopeDelimiter`, `prompt`, and `clientRegistration` — do not apply; the
-`id-jag` mode is configured entirely through the `idJag` option.
+Use this mode in enterprise deployments where the gateway and the upstream trust
+the same identity provider (for example, Okta Cross-App Access), so upstream
+access follows the caller's identity without a per-user upstream consent flow.
+The `user-oauth`/`shared-oauth` options — `scopes`, `scopeDelimiter`, `prompt`,
+and `clientRegistration` — do not apply; the `id-jag` mode is configured
+entirely through the `idJag` option.
 
 ```json
 {
@@ -168,9 +168,9 @@ consent flow. The `user-oauth`/`shared-oauth` options — `scopes`,
 ```
 
 Both `clientAuth` blocks also accept `client_secret_basic` and
-`private_key_jwt`. Use `private_key_jwt` for providers such as Okta that
-require a signed client assertion for token exchange; it takes `privateKeyPem`,
-an optional `keyId`, and an `algorithm` (default `RS256`). Source secrets and
+`private_key_jwt`. Use `private_key_jwt` for providers such as Okta that require
+a signed client assertion for token exchange; it takes `privateKeyPem`, an
+optional `keyId`, and an `algorithm` (default `RS256`). Source secrets and
 private keys from environment variables with `$env(VAR_NAME)`. When `resource`
 is omitted, the gateway defaults it to the upstream MCP server URL from the
 route handler's `rewritePattern`.

package/docs/policies/require-user-claims-inbound/doc.md

@@ -1,10 +1,10 @@
 ## Overview
 
 The `require-user-claims-inbound` policy authorizes requests by evaluating a
-rule against the claims of the authenticated user (`request.user`). It
-separates authentication from authorization: an authentication policy — a JWT
-policy such as `open-id-jwt-auth-inbound`, API key auth, mTLS, or any other —
-proves _who_ the caller is; this policy then decides _what_ they may call.
+rule against the claims of the authenticated user (`request.user`). It separates
+authentication from authorization: an authentication policy — a JWT policy such
+as `open-id-jwt-auth-inbound`, API key auth, mTLS, or any other — proves _who_
+the caller is; this policy then decides _what_ they may call.
 
 Typical uses:
 
@@ -86,8 +86,8 @@ metadata.
   `['https://example.com/roles']`, or nested:
   `['https://sts.amazonaws.com/']['lambda_source_function_arn']`. Single or
   double quotes both work; single quotes avoid backslash-escaping when the
-  selector is written in a JSON `policies.json`. The two notations may be
-  mixed, e.g. `realm_access['some.key']`.
+  selector is written in a JSON `policies.json`. The two notations may be mixed,
+  e.g. `realm_access['some.key']`.
 - `sub` falls back to `request.user.sub` when the user data has no `sub`
   property, so subject checks also work with authentication policies that only
   set the subject (for example API key authentication).
@@ -102,8 +102,8 @@ Every check fails closed:
   the number `42`. Note that Google-issued tokens carry `sub` as a string of
   digits, and `$env(...)` substitution always produces strings — quote numeric
   values accordingly.
-- `startsWith` only matches string claim values, and an empty prefix is
-  rejected as a configuration error.
+- `startsWith` only matches string claim values, and an empty prefix is rejected
+  as a configuration error.
 - When a claim value is an **array** (for example `groups` or `roles`), a check
   passes if **any element** satisfies the operator.
 
@@ -113,8 +113,7 @@ checks and the caller's `sub` are written to the request log instead.
 ## Related policies
 
 - [Open ID JWT Auth](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound) —
-  verifies token signature, issuer, and audience, and populates
-  `request.user`.
+  verifies token signature, issuer, and audience, and populates `request.user`.
 - [JWT Scope Validation](https://zuplo.com/docs/policies/jwt-scopes-inbound) —
   requires that the space-delimited `scope` claim contains **all** configured
   scopes; use it for OAuth scope enforcement.

package/docs/policies/require-user-claims-inbound/intro.md

@@ -2,8 +2,8 @@ Authorize requests by validating claims on the authenticated user against a
 configurable rule — allowlists (`in`), exact values (`eq`), and prefixes
 (`startsWith`), combined with `and`/`or`.
 
-Run this policy after any authentication policy (for example Open ID JWT Auth
-or one of its provider-specific variants): the authentication policy proves
-_who_ the caller is, and this policy decides _what_ they may call — for
-example, pinning a route to specific service accounts, OAuth clients, tenants,
-or groups without writing custom code.
+Run this policy after any authentication policy (for example Open ID JWT Auth or
+one of its provider-specific variants): the authentication policy proves _who_
+the caller is, and this policy decides _what_ they may call — for example,
+pinning a route to specific service accounts, OAuth clients, tenants, or groups
+without writing custom code.

package/docs/policies/upstream-aws-federated-auth-inbound/doc.md

@@ -2,9 +2,8 @@
 
 The Upstream AWS Federated Auth policy obtains AWS credentials **without storing
 any AWS keys**. It exchanges Zuplo's ambient OIDC identity token for an IAM
-role's short-lived temporary credentials using STS
-`AssumeRoleWithWebIdentity`, then registers those credentials on the request
-context.
+role's short-lived temporary credentials using STS `AssumeRoleWithWebIdentity`,
+then registers those credentials on the request context.
 
 Like the `upstream-aws-service-auth` policy, it does **not** add an
 `Authorization` header itself — AWS Signature Version 4 signs the exact final

package/docs/policies/upstream-aws-service-auth-inbound/doc.md

@@ -9,8 +9,8 @@ resolved credentials and sign the requests they build.
 
 There are two modes:
 
-- **Static credentials** — the configured `accessKeyId` / `secretAccessKey`
-  (and optional `sessionToken`) are used directly.
+- **Static credentials** — the configured `accessKeyId` / `secretAccessKey` (and
+  optional `sessionToken`) are used directly.
 - **Assumed role** — when `roleArn` is set, the policy calls STS `AssumeRole`
   (signed with the configured keys) and uses the role's short-lived temporary
   credentials. These are cached in memory and refreshed before they expire.

package/docs/rate-limiting/how-it-works.md

@@ -99,6 +99,58 @@ Applies a single shared counter across all requests to the route, regardless of
 who makes them. Use this for global rate limits on endpoints that call
 resource-constrained backends.
 
+## Sub-minute time windows
+
+Time windows don't have to be whole minutes. The `timeWindowMinutes` option
+accepts fractional values, so you can define windows measured in seconds:
+
+```json
+{
+  "name": "burst-protection",
+  "policyType": "rate-limit-inbound",
+  "handler": {
+    "export": "RateLimitInboundPolicy",
+    "module": "$import(@zuplo/runtime)",
+    "options": {
+      "rateLimitBy": "user",
+      "requestsAllowed": 10,
+      "timeWindowMinutes": 0.5
+    }
+  }
+}
+```
+
+This policy allows each user 10 requests in any 30-second sliding window. Some
+useful values:
+
+| `timeWindowMinutes` | Window length |
+| ------------------- | ------------- |
+| `0.5`               | 30 seconds    |
+| `0.25`              | 15 seconds    |
+| `0.1`               | 6 seconds     |
+
+Fractional values work anywhere `timeWindowMinutes` appears — including the
+[Complex Rate Limiting policy](#complex-rate-limiting-policy) and the values
+returned by a [custom rate limit function](#custom-rate-limit-functions).
+
+Short windows pair well with a longer sustained limit on the same route: the
+tight window absorbs bursts while the longer one enforces overall usage. See
+[Combining Policies](./combining-policies.mdx) for how to stack rate limits.
+
+### Short windows and accuracy
+
+The rate limiter is globally distributed: counters synchronize across edge
+locations worldwide, so a limit applies consistently regardless of which region
+serves a request. That synchronization can't outrun the speed of light (Zuplo is
+working on bending physics). As a window shrinks toward a few seconds,
+synchronization takes up a bigger fraction of the window, so counts from
+different regions can fall out of step before the window elapses — and a small
+number of requests that should exceed the limit can slip through.
+
+Windows of roughly 5 seconds or longer give the most consistent enforcement.
+Shorter windows still work; they just carry a slightly higher chance of a missed
+limit application.
+
 ## Custom rate limit functions
 
 When `rateLimitBy` is set to `"function"`, Zuplo calls a TypeScript function you

package/package.json

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