zuplo 6.74.14 → 6.74.15

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

@@ -13,8 +13,8 @@ environments.
 ![The API Keys → Consumers page in the Services section, with the sidebar showing API Keys, Monetization, and Audit Logs, and the environment switcher set to Dev](../../public/media/api-key-administration/services-page.png)
 
 To view the bucket for a different environment, use the **Dev / Preview / Prod**
-switcher at the top of the sidebar. The active bucket's name appears as a
-copyable pill under the **API Key Service** heading.
+switcher at the top of the sidebar. Click **Bucket Details** under the **API Key
+Service** heading to copy the active bucket's name or ID.
 
 To add a new API Key Consumer, click **Create Consumer** and complete the form.
 

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

@@ -139,12 +139,15 @@ When running API Key Authentication locally, if you
 shared by both your development (working copy) environment and local
 development.
 
-### Setting the API Key bucket name
+### Setting the API Key bucket
 
 Either locally or in CI/CD you can specify any API Key bucket on the
 [API Key Authentication](../policies/api-key-inbound.mdx) policy by setting the
-`bucketName` property. This allows using a consistent API Key bucket that is set
-up with consumers as required for testing. You can use the
+`bucketId` property. Every environment can then share a single bucket that holds
+the consumers your tests need. Find a bucket's ID under **Bucket Details** on
+the
+[**Services → API Keys → Consumers**](https://portal.zuplo.com/+/account/project/services)
+page in the Zuplo Portal. You can use the
 [Zuplo Developer API](https://dev.zuplo.com) to
 [create and manage buckets](./api-key-management.mdx), consumers, keys, and
 more.

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

@@ -23,21 +23,33 @@ For more information on how environments relate to Git branches, see
 
 ## Custom bucket configuration
 
-To use a custom bucket, specify the `bucketName` in your API Key policy options:
+To use a custom bucket, specify its `bucketId` in your API Key policy options:
 
 ```json
 {
   "export": "ApiKeyInboundPolicy",
   "module": "$import(@zuplo/runtime)",
   "options": {
-    "bucketName": "contoso-qa-env",
+    "bucketId": "bckt_2HaK3odRyJle6NJSu8mzNKBC30BYxllxL",
     "allowUnauthenticatedRequests": false
   }
 }
 ```
 
-When no `bucketName` appears in the configuration, the policy uses the default
-bucket for the current environment.
+Bucket IDs start with `bckt_`. To find one, open
+[**Services → API Keys → Consumers**](https://portal.zuplo.com/+/account/project/services)
+in the Zuplo Portal, select the environment with the **Dev / Preview / Prod**
+switcher, then click **Bucket Details**.
+
+When the configuration sets no bucket, the policy uses the default bucket for
+the current environment.
+
+:::note
+
+The policy's `bucketName` option is deprecated. Policies that set it keep
+working, but the runtime logs a warning — use `bucketId` instead.
+
+:::
 
 ## Creating custom buckets
 
@@ -46,7 +58,9 @@ Create custom buckets using the
 [create buckets endpoint](https://dev.zuplo.com/docs/routes#apikeybucketsservice_create)
 for details.
 
-The following example creates a bucket for a QA environment:
+The following example creates a bucket for a QA environment. The response
+includes the new bucket's `id`, which is the value to set as `bucketId` on the
+policy:
 
 ```bash
 curl --request POST \

package/docs/articles/api-key-consumer-bucket-portal-ui.mdx

@@ -63,19 +63,22 @@ For deeper detail, see [Buckets and Environments](./api-key-buckets.mdx).
    opens on **API Keys → Consumers** in the section sidebar.
 
 1. Use the **Dev / Preview / Prod** switcher at the top of the sidebar to select
-   the environment whose bucket you want. The active bucket's name appears as a
-   copyable pill under the **API Key Service** heading.
+   the environment whose bucket you want.
+
+1. Click **Bucket Details** under the **API Key Service** heading to see the
+   active bucket's name and ID, each with a copy button.
 
 </Stepper>
 
 <ModalScreenshot size="md">
 
-![The API Keys → Consumers page with the environment switcher set to Dev and the active bucket name shown as a pill under the API Key Service heading](../../public/media/api-key-consumer-bucket-portal-ui/services-page-dropdown.png)
+![The API Keys → Consumers page with the environment switcher set to Dev and the Bucket Details button under the API Key Service heading](../../public/media/api-key-consumer-bucket-portal-ui/services-page-dropdown.png)
 
 </ModalScreenshot>
 
-The pill under the **API Key Service** heading shows the name of the bucket
-that's currently active for the selected environment.
+**Bucket Details** shows the name and ID of the bucket that's currently active
+for the selected environment. Bucket IDs start with `bckt_` — this is the value
+the API Key Authentication policy's `bucketId` option takes.
 
 ## Create a consumer in a specific bucket
 
@@ -114,8 +117,8 @@ an environment whose API Key Authentication policy resolves to that same bucket.
 ## How bucket selection affects key validation
 
 The [API Key Authentication policy](../policies/api-key-inbound.mdx) decides
-which bucket to validate keys against. With no `bucketName` set, the policy
-defaults to the bucket that matches the current environment:
+which bucket to validate keys against. With no bucket set, the policy defaults
+to the bucket that matches the current environment:
 
 | Environment | Default bucket |
 | ----------- | -------------- |
@@ -123,20 +126,22 @@ defaults to the bucket that matches the current environment:
 | Preview     | Preview        |
 | Development | Development    |
 
-For a custom bucket, set `bucketName` (or `bucketId`) on the policy so it checks
-the right one:
+For a custom bucket, set `bucketId` on the policy so it checks the right one:
 
 ```json
 {
   "export": "ApiKeyInboundPolicy",
   "module": "$import(@zuplo/runtime)",
   "options": {
-    "bucketName": "my-custom-bucket",
+    "bucketId": "bckt_2HaK3odRyJle6NJSu8mzNKBC30BYxllxL",
     "allowUnauthenticatedRequests": false
   }
 }
 ```
 
+The policy's `bucketName` option is deprecated. Policies that set it keep
+working, but the runtime logs a warning — use `bucketId` instead.
+
 :::caution
 
 If the consumer lives in one bucket but the policy checks a different bucket,
@@ -178,11 +183,11 @@ a different one.
 
 1. In the portal, open **Services → API Keys → Consumers** and confirm which
    bucket holds the consumer.
-2. Open the route's API Key Authentication policy. If `bucketName` or `bucketId`
-   is set, verify it matches the consumer's bucket. If neither is set, the
-   policy uses the current environment's default bucket.
+2. Open the route's API Key Authentication policy. If `bucketId` (or the
+   deprecated `bucketName`) is set, verify it matches the consumer's bucket. If
+   neither is set, the policy uses the current environment's default bucket.
 3. Either recreate the consumer in the correct bucket, or update the policy's
-   `bucketName` to match.
+   `bucketId` to match.
 
 </details>
 
@@ -218,7 +223,7 @@ to the matching environment to locate it.
 - [Manage Keys in the Portal](./api-key-administration.mdx): General portal
   management walkthrough
 - [API Key Authentication policy](../policies/api-key-inbound.mdx): Policy
-  configuration reference including `bucketName`
+  configuration reference including `bucketId`
 - [Use the Developer API](./api-key-api.mdx): Programmatic consumer management
 - [Create an API Key Consumer on Login](../dev-portal/dev-portal-create-consumer-on-auth.mdx):
   Automatically create consumers when users sign in

package/docs/articles/api-key-self-serve-integration.mdx

@@ -55,8 +55,8 @@ Before you start, you need:
   environment - each project has buckets for production, preview, and
   development. Find the bucket name on your project's
   [**Services → API Keys → Consumers**](https://portal.zuplo.com/+/account/project/services)
-  page (the copyable pill under the **API Key Service** heading), and the
-  account name in
+  page (under **Bucket Details**, next to the **API Key Service** heading), and
+  the account name in
   [**Project Settings → General**](https://portal.zuplo.com/+/account/project/settings/general).
 - An application with server-side code and existing user authentication.
 

package/docs/articles/monetization/api-access.mdx

@@ -37,7 +37,7 @@ are set in your terminal:
 
 ```bash
 # Your Bucket ID (could be working-copy, preview, or production)
-# (Copy the bucket pill on Services > API Keys > Consumers — https://portal.zuplo.com/+/account/project/services)
+# (Copy it from Bucket Details on Services > API Keys > Consumers — https://portal.zuplo.com/+/account/project/services)
 export BUCKET_ID=your-bucket-id
 # Your Zuplo API Key (Found in Account Settings > Zuplo API Keys —
 # https://portal.zuplo.com/+/account/settings/api-keys)

package/docs/articles/monetization/going-to-production.mdx

@@ -459,7 +459,7 @@ To help the team resolve your issue quickly, include:
 | ------------------ | ------------------------------------------------------ |
 | Account slug       | Your Zuplo account identifier                          |
 | Project slug       | The project with monetization enabled                  |
-| Bucket ID          | The bucket pill on Services → API Keys → Consumers     |
+| Bucket ID          | Bucket Details on Services → API Keys → Consumers      |
 | Stripe account ID  | Stripe Dashboard → Settings, starts with `acct_`       |
 | Plan keys          | The plan keys involved in the issue                    |
 | Subscription ID    | If the issue is subscription-specific                  |

package/docs/cli/test.mdx

@@ -23,6 +23,14 @@ sidebar_label: test
     "deprecated": false,
     "hidden": false
   },
+  {
+    "name": "skip-filter",
+    "type": "string",
+    "description": "Skip tests whose name matches this pattern (e.g., --skip-filter '\\[deep\\]'). Applied after --filter.",
+    "required": false,
+    "deprecated": false,
+    "hidden": false
+  },
   {
     "name": "dir",
     "type": "string",
@@ -33,6 +41,14 @@ sidebar_label: test
     "hidden": true,
     "normalize": true
   },
+  {
+    "name": "only",
+    "type": "boolean",
+    "description": "Run only the tests and suites marked with .only. Without this flag Node ignores .only and runs everything.",
+    "required": false,
+    "deprecated": false,
+    "hidden": false
+  },
   {
     "name": "test-concurrency",
     "type": "number",
@@ -54,6 +70,10 @@ sidebar_label: test
     "$0 test --endpoint https://your-api-123abc.zuplo.app --filter '/api\\/v1/'",
     "Run tests matching a regex pattern"
   ],
+  [
+    "$0 test --endpoint https://your-api-123abc.zuplo.app --skip-filter '\\[slow\\]'",
+    "Run everything except tests tagged [slow] in their name"
+  ],
   [
     "MY_VAR=example $0 test --endpoint https://your-api-123abc.zuplo.app",
     "Run tests with environment variables"

package/docs/policies/_index.md

@@ -5,7 +5,7 @@
 | set-query-params-inbound | Add or Set Query Parameters | Adds or sets query parameters on the incoming request. | api-gateway |
 | set-headers-inbound | Add or Set Request Headers | Adds or sets headers on the incoming request. | api-gateway |
 | ai-gateway-fallback-model-v2-inbound | AI Gateway Fallback Model (v2) | Adds failure and quota fallbacks to an existing AI Gateway model selection.  Place this policy after AI Gateway Model Filtering (v2). It never creates a model selection, so a misplaced policy cannot bypass filtering. | ai-gateway |
-| ai-gateway-metering-v2-inbound | AI Gateway Metering (v2) | Meters AI Gateway v2 usage and enforces options-driven usage limits.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
+| ai-gateway-metering-v2-inbound | AI Gateway Metering (v2) | Meters AI Gateway v2 usage and enforces app and ancestor usage limits.  Limits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
 | ai-gateway-model-filtering-v2-inbound | AI Gateway Model Filtering (v2) | Matches AI Gateway requests against curated allow lists or open block lists, then stores the winning model reference for the route handler. | ai-gateway |
 | akamai-ai-firewall | Akamai AI Firewall | Akamai AI Firewall Inbound Policy | ai-gateway |
 | akamai-firewall-for-ai-outbound | Akamai Firewall for AI | Inspects each upstream response with Akamai's Firewall for AI detect API and replaces the response with a `403 Forbidden` if Akamai returns a `deny` rule. Useful behind AI-powered APIs to filter unsafe completions, sensitive data exposure, and toxic content before they reach the client.  The body, headers, URL, and query string sent to Akamai are configurable; by default only the response body is captured. Bodies are read from a clone so the client still receives the original. | api-gateway |
@@ -21,6 +21,7 @@
 | bot-detection-inbound | Bot Detection | Detect known and suspected bots based on sophisticated traffic analysis. | api-gateway |
 | brownout-inbound | Brown Out | The brownout policy allows performing scheduled downtime on your API | api-gateway |
 | caching-inbound | Caching | Respond to matched incoming requests with cached content | api-gateway |
+| cdn-cache-control-outbound | CDN Cache Control | Sets the response headers that tell a CDN how long it may cache a response and which purge tags it belongs to, separately from what the browser is told. | api-gateway |
 | change-method-inbound | Change Method | Changes the HTTP method of the incoming request. | api-gateway |
 | clear-headers-inbound | Clear Request Headers | Removes all headers from the incoming request except for those in the exclude list. | api-gateway |
 | clear-headers-outbound | Clear Response Headers | Removes all headers from the response except for those in the exclude list. | api-gateway |
@@ -44,6 +45,7 @@
 | graphql-disable-introspection-inbound | GraphQL Disable Introspection | Policy that disables GraphQL introspection queries in production. Introspection allows clients to discover the schema, which can be a security risk as it exposes your entire API structure. | api-gateway |
 | graphql-introspection-filter-outbound | GraphQL Introspection Filter | Filters GraphQL introspection responses to exclude specific types and fields.  This policy intercepts GraphQL introspection query responses and removes configured types and fields from the schema. Useful for hiding internal types or sensitive fields from the public schema. | api-gateway |
 | http-deprecation-outbound | HTTP Deprecation | Sets HTTP deprecation headers on the outgoing response following the IETF HTTP Deprecation Header standard. Supports the Deprecation, Sunset, and Link headers. | api-gateway |
+| ip-address-restriction-inbound | IP Address Restriction | Restricts which client IP addresses can call a route using an allow list, a deny list, or both. Entries are individual IP addresses or CIDR ranges, in IPv4 or IPv6. | api-gateway |
 | validate-json-schema-inbound | JSON Body Validation (deprecated) | Validates the body of an incoming request based on a JSON schema. | api-gateway |
 | open-id-jwt-auth-inbound | JWT Auth | The Open ID JWT Authentication policy allows you to authenticate incoming requests using an Open ID compliant bearer token. | api-gateway |
 | jwt-scopes-inbound | JWT Scope Validation | Validates that the JWT token includes specific scopes | api-gateway |

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

@@ -40,6 +40,26 @@ The supported meters are `costs`, `tokens`, and `requests`. Each meter can have
 When `throwOnFailure` is `false`, metering failures pass the request through.
 Set it to `true` to fail the request instead.
 
+## Team limits
+
+Limits configured on a parent team or the bucket root are enforced automatically
+through a server-side hierarchical check against aggregated usage. The
+`options.limits` settings govern only the app running this policy; the server
+walks the ancestor chain and reports the first exceeded limit.
+
+An exceeded team or root limit follows the same configured model-fallback or 429
+response path as an app limit. Ancestor enforcement cannot be disabled from the
+app's policy-chain entry. When the hierarchical check is unavailable,
+`throwOnFailure` controls the behavior: the default skips enforcement for that
+request while continuing to meter it, and `true` fails the request.
+
+### Known residual
+
+Grandfathered v2 apps that already store `metadata.limits` are still evaluated
+at the leaf by the server's hierarchy walk. The companion Gateway Service change
+rejects introducing or modifying app metadata limits; cleaning up stale rows is
+tracked separately.
+
 ## Set limits from custom code
 
 Use a custom inbound policy to vary limits for individual requests. For example,

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

@@ -11,7 +11,7 @@
   "isHidden": false,
   "requiresAI": true,
   "products": ["ai-gateway"],
-  "description": "Meters AI Gateway v2 usage and enforces options-driven usage limits.\n\nThe authentication policy must run before this policy so the app configuration id is available for meter storage and analytics.",
+  "description": "Meters AI Gateway v2 usage and enforces app and ancestor usage limits.\n\nLimits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.\n\nThe authentication policy must run before this policy so the app configuration id is available for meter storage and analytics.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {