zuplo 6.69.6 → 6.69.8

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

@@ -60,6 +60,136 @@ curl \
   --header "Authorization: Bearer $ZAPI_KEY"
 ```
 
+## Bucket monetization configuration
+
+Each bucket has an optional `MonetizationConfiguration` record that holds
+bucket-wide defaults. The configuration is read by the runtime and the Developer
+Portal — it is not stored in OpenMeter.
+
+| Method   | Path                                                 |
+| -------- | ---------------------------------------------------- |
+| `GET`    | `/v3/metering/{bucketId}/monetization-configuration` |
+| `PUT`    | `/v3/metering/{bucketId}/monetization-configuration` |
+| `DELETE` | `/v3/metering/{bucketId}/monetization-configuration` |
+
+The `PUT` endpoint upserts the record. At least one of the four fields below
+must be present. Pass any combination — fields that are omitted retain their
+previous value.
+
+| Field                          | Type               | Description                                                                                                                                                                                                                                                                                                                                                    |
+| ------------------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `multipleSubscriptionsEnabled` | `boolean`          | Stored on the bucket. Reserved for future enforcement of multi-subscription rules; today the Developer Portal create-subscription path enforces a single active subscription per customer regardless of this flag.                                                                                                                                             |
+| `planOrder`                    | `string[]`         | Plan keys in display order. Drives the pricing page sort and is used by [plan changes](./subscription-lifecycle.md#plan-changes-upgrades-and-downgrades) to decide upgrade vs downgrade — moving to a plan with a higher (or equal) index is treated as an upgrade with `"immediate"` timing; a lower index is a downgrade with `"next_billing_cycle"` timing. |
+| `planSettings`                 | `object`           | Per-plan overrides keyed by plan key. The supported sub-key today is `visiblePhases` — an array of phase keys that should appear on the pricing page. Omitted means no filtering; `[]` hides all phases for that plan.                                                                                                                                         |
+| `maxPaymentOverdueDays`        | `integer` (`>= 0`) | Bucket-level grace period for overdue payments. Used as the lowest-priority value in the resolution chain: customer metadata → plan metadata → this bucket value → built-in default of `3` days. See [Subscription and payment validation](./monetization-policy.md#subscription-and-payment-validation).                                                      |
+
+```bash
+curl -X PUT "https://dev.zuplo.com/v3/metering/$BUCKET_ID/monetization-configuration" \
+  --header "Authorization: Bearer $ZAPI_KEY" \
+  --header "Content-Type: application/json" \
+  --data '{
+    "planOrder": ["free", "developer", "pro"],
+    "planSettings": {
+      "pro": { "visiblePhases": ["default"] }
+    },
+    "maxPaymentOverdueDays": 7
+  }'
+```
+
+`DELETE` removes the record entirely; `GET` on a bucket with no record returns
+the schema defaults (`multipleSubscriptionsEnabled: false`, `planOrder: []`,
+`planSettings: {}`, `maxPaymentOverdueDays: 3`).
+
+## Stripe setup and billing readiness
+
+These endpoints script the Stripe integration that the
+[Monetization Service UI](./stripe-integration.md#connecting-your-stripe-account)
+runs interactively. They live on the Zuplo developer API (not OpenMeter), so the
+request shape is documented here.
+
+### Connect a Stripe app
+
+```http
+POST /v3/metering/{bucketId}/setup/stripe
+```
+
+Installs a Stripe app on the bucket and creates the default billing profile
+linked to that app.
+
+| Field         | Type      | Description                                                                                      |
+| ------------- | --------- | ------------------------------------------------------------------------------------------------ |
+| `apiKey`      | `string`  | Stripe secret or restricted key. Required.                                                       |
+| `name`        | `string`  | Display name for the app. Required.                                                              |
+| `taxEnabled`  | `boolean` | Initial value for `workflow.tax.enabled` on the billing profile. Optional; defaults to `false`.  |
+| `taxEnforced` | `boolean` | Initial value for `workflow.tax.enforced` on the billing profile. Optional; defaults to `false`. |
+| `country`     | `string`  | ISO 3166-1 alpha-2 supplier country for the billing profile. Optional; defaults to `"US"`.       |
+
+The request fails if the key prefix does not match the bucket environment:
+
+- Working-copy or preview buckets accept `sk_test_*` or `rk_test_*`.
+- Production buckets accept `sk_live_*` or `rk_live_*`.
+
+```bash
+curl -X POST "https://dev.zuplo.com/v3/metering/$BUCKET_ID/setup/stripe" \
+  --header "Authorization: Bearer $ZAPI_KEY" \
+  --header "Content-Type: application/json" \
+  --data '{
+    "apiKey": "rk_test_...",
+    "name": "Zuplo Monetization (test)",
+    "taxEnabled": false,
+    "country": "US"
+  }'
+```
+
+### Read the connected Stripe app
+
+```http
+GET /v3/metering/{bucketId}/setup/stripe
+```
+
+Returns a summary of the connected Stripe app, the matched billing profile, and
+connection-test status. Use this to confirm the integration is wired up before
+continuing.
+
+### Add a billing profile to a Stripe app
+
+```http
+POST /v3/metering/{bucketId}/setup/stripe/{stripeAppId}/billing-profile
+```
+
+Creates an additional billing profile against an already-installed Stripe app.
+This is rarely needed — the default profile is created during initial setup. Use
+this endpoint to create per-supplier-country profiles.
+
+### Check billing readiness
+
+```http
+GET /v3/metering/{bucketId}/billing-readiness
+```
+
+Returns:
+
+```json
+{
+  "hasStripeApp": true,
+  "stripeAppId": "app_01H...",
+  "hasDefaultBillingProfile": true,
+  "defaultBillingProfileId": "bp_01H..."
+}
+```
+
+Use this in setup wizards to gate the UI on whether Stripe is connected.
+
+### Update an app
+
+```http
+PUT /v3/metering/{bucketId}/apps/{appId}
+```
+
+Replaces an app's configuration (name, description, metadata, and — for Stripe
+apps — `secretAPIKey`). The same key-prefix validation as `POST /setup/stripe`
+applies: a Stripe key must match the bucket environment.
+
 ## API Reference
 
 For complete API operations, see the API Reference documentation:

package/docs/articles/monetization/features.mdx

@@ -44,7 +44,8 @@ feature structure carefully before creating them.
 
 ## Creating a Feature
 
-Create a metered feature linked to an API requests meter:
+Create a metered feature linked to the `api_requests` meter. The feature's `key`
+must match the meter's `slug`:
 
 ```shell
 curl \
@@ -54,8 +55,8 @@ curl \
   --header "Content-Type: application/json" \
   --data @- << EOF
 {
-  "key": "api_calls",
-  "name": "API Calls",
+  "key": "api_requests",
+  "name": "API Requests",
   "meterSlug": "api_requests"
 }
 EOF
@@ -66,17 +67,19 @@ The response includes the created feature:
 ```json
 {
   "id": "01ARZ3NDEKTSV4RRFFQ69G5FAV",
-  "key": "api_calls",
-  "name": "API Calls",
+  "key": "api_requests",
+  "name": "API Requests",
   "meterSlug": "api_requests",
-  "createdAt": "2024-01-01T01:01:01.001Z",
-  "updatedAt": "2024-01-01T01:01:01.001Z"
+  "createdAt": "2026-01-01T01:01:01.001Z",
+  "updatedAt": "2026-01-01T01:01:01.001Z"
 }
 ```
 
 ### Creating a Static Feature
 
-For features without usage tracking, omit the `meterSlug`:
+For features without usage tracking, omit the `meterSlug`. A plan's rate card
+attaches a `boolean` entitlement that determines whether the customer has access
+to the capability:
 
 ```shell
 curl \
@@ -92,6 +95,34 @@ curl \
 EOF
 ```
 
+### Creating a Billing-Only Feature
+
+Some plans charge a flat subscription fee that isn't tied to any entitlement — a
+monthly access fee, a setup fee, or a fixed retainer. Model these the same way
+as a static feature (no `meterSlug`), then attach them to a plan via a
+`flat_fee` rate card with no `entitlementTemplate` and a price whose
+`paymentTerm` is `"in_advance"`. Zuplo issues a Stripe Invoice for the fee at
+the start of each billing period.
+
+```shell
+curl \
+  https://dev.zuplo.com/v3/metering/$BUCKET_ID/features \
+  --request POST \
+  --header "Authorization: Bearer $ZAPI_KEY" \
+  --header "Content-Type: application/json" \
+  --data @- << EOF
+{
+  "key": "monthly_fee",
+  "name": "Monthly Fee"
+}
+EOF
+```
+
+Because the rate card carries no entitlement, the developer portal's
+feature-comparison matrix doesn't render a row for the feature — the price rolls
+into the plan's headline cost. See the Pro plan example in [Plans](./plans.mdx)
+for the rate-card shape.
+
 ## API Reference
 
 For complete API operations (list, get, archive), see the

package/docs/articles/monetization/index.mdx

@@ -28,8 +28,8 @@ and invoices come out wrong.
 
 Zuplo eliminates this by making the gateway the single source of truth. Every
 request that hits your API is metered, enforced, and billed through one system.
-When a customer's quota runs out, they get a `429` immediately — not five
-minutes later when a batch job catches up.
+When a customer's quota runs out, they get a `403 Forbidden` immediately — not
+five minutes later when a batch job catches up.
 
 ## Core concepts
 
@@ -73,10 +73,11 @@ with automatic conversion to paid, and multiple subscriptions per customer.
 - **Built-in metering** — Count requests, tokens, bytes, or any custom
   dimension. No external metering service required.
 - **Real-time quota enforcement** — Customers hitting their limit get a
-  `429 Too Many Requests` response instantly, not after a batch sync.
-- **Stripe billing integration** — Subscriptions, invoicing, and payment
-  collection handled by Stripe. Zuplo keeps access state synchronized
-  automatically.
+  `403 Forbidden` response instantly, not after a batch sync.
+- **Stripe billing integration** — Stripe handles checkout, payment, the billing
+  portal, and tax. Zuplo issues Stripe Invoices for fixed fees and metered usage
+  at the end of each billing period, and the gateway revokes access
+  automatically when a payment goes overdue past the configured grace period.
 - **Self-serve Developer Portal** — Pricing page, plan selection, checkout,
   subscription management, usage dashboards, and API key management built into
   the Zudoku-powered portal.
@@ -93,21 +94,21 @@ pricing, wire up Stripe, and configure your gateway to enforce quotas.
 
 ## Documentation map
 
-| Document                                                               | What it covers                                           |
-| ---------------------------------------------------------------------- | -------------------------------------------------------- |
-| [Quickstart](./monetization/quickstart.md)                             | End-to-end setup in 30 minutes                           |
-| [Meters](./monetization/meters.mdx)                                    | How meters track usage dimensions                        |
-| [Features](./monetization/features.mdx)                                | Connecting meters to your product catalog                |
-| [Plans](./monetization/plans.mdx)                                      | Plan structure, phases, lifecycle, and publishing        |
-| [Rate Cards](./monetization/rate-cards.mdx)                            | Pricing and entitlements within plans                    |
-| [Pricing Models](./monetization/pricing-models.mdx)                    | Flat, per-unit, tiered, volume, and package pricing      |
-| [Billing Models Guide](./monetization/billing-models.md)               | Choosing the right pricing strategy for your business    |
-| [Stripe Integration](./monetization/stripe-integration.md)             | Connecting Stripe and managing payments                  |
-| [Developer Portal Setup](./monetization/developer-portal.md)           | Configuring the self-serve portal for your customers     |
-| [Monetization Policy Reference](./monetization/monetization-policy.md) | Configuring the `MonetizationInboundPolicy` per-route    |
-| [API Access](./monetization/api-access.mdx)                            | Authentication, buckets, and API reference links         |
-| [Subscription Lifecycle](./monetization/subscription-lifecycle.md)     | Managing trials, upgrades, downgrades, and cancellations |
-| [Private Plans](./monetization/private-plans.md)                       | Invite-only plans for specific users                     |
-| [Tax Collection](./monetization/tax-collection.md)                     | Enabling VAT, sales tax, or GST via Stripe Tax           |
-| [Plan Examples](./monetization/plan-examples.mdx)                      | Real-world plan configurations                           |
-| [Troubleshooting](./monetization/troubleshooting.md)                   | Common issues, debugging, and FAQ                        |
+| Document                                                               | What it covers                                                                        |
+| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
+| [Quickstart](./monetization/quickstart.md)                             | End-to-end setup in 30 minutes                                                        |
+| [Meters](./monetization/meters.mdx)                                    | How meters track usage dimensions                                                     |
+| [Features](./monetization/features.mdx)                                | Connecting meters to your product catalog                                             |
+| [Plans](./monetization/plans.mdx)                                      | Plan structure, phases, lifecycle, and publishing                                     |
+| [Rate Cards](./monetization/rate-cards.mdx)                            | Pricing and entitlements within plans                                                 |
+| [Pricing Models](./monetization/pricing-models.mdx)                    | Flat, per-unit, tiered, volume, and package pricing                                   |
+| [Billing Models Guide](./monetization/billing-models.md)               | Choosing the right pricing strategy for your business                                 |
+| [Stripe Integration](./monetization/stripe-integration.md)             | Connecting Stripe and managing payments                                               |
+| [Developer Portal Setup](./monetization/developer-portal.md)           | Configuring the self-serve portal for your customers                                  |
+| [Monetization Policy Reference](./monetization/monetization-policy.md) | Configuring the `MonetizationInboundPolicy` per-route                                 |
+| [API Access](./monetization/api-access.mdx)                            | Authentication, buckets, bucket configuration, Stripe setup APIs, and reference links |
+| [Subscription Lifecycle](./monetization/subscription-lifecycle.md)     | Managing trials, upgrades, downgrades, and cancellations                              |
+| [Private Plans](./monetization/private-plans.md)                       | Invite-only plans for specific users                                                  |
+| [Tax Collection](./monetization/tax-collection.md)                     | Enabling VAT, sales tax, or GST via Stripe Tax                                        |
+| [Plan Examples](./monetization/plan-examples.mdx)                      | Real-world plan configurations                                                        |
+| [Troubleshooting](./monetization/troubleshooting.md)                   | Common issues, debugging, and FAQ                                                     |

package/docs/articles/monetization/meters.mdx

@@ -25,7 +25,7 @@ A meter is configured with:
 - **Aggregation** - How to combine values (typically `SUM`)
 
 When events are ingested, the meter matches events by type, extracts the
-specified value, and aggregates it per customer over time.
+specified value, and aggregates it per customer subscription over time.
 
 ## Common Examples
 
@@ -52,7 +52,7 @@ Each event contains the `subscription` ID linking it to a subscription and a
   "specversion": "1.0",
   "type": "api_requests",
   "source": "monetization-policy",
-  "subject": "customer-id",
+  "subject": "01KNVXHQG356VA7T7W0V9N21GH",
   "subscription": "01KNVXHQG356VA7T7W0V9N21GH",
   "data": {
     "total": 1
@@ -60,6 +60,14 @@ Each event contains the `subscription` ID linking it to a subscription and a
 }
 ```
 
+:::note
+
+Events emitted by the `MonetizationInboundPolicy` always set `subject` and
+`subscription` to the same subscription ULID. See
+[Monetization Policy](./monetization-policy.md) for how usage is recorded.
+
+:::
+
 ### Token Usage
 
 Track token consumption for AI applications:
@@ -74,8 +82,13 @@ Track token consumption for AI applications:
 }
 ```
 
-Each event reports a fixed quantity per request. For example, if a meter is
-configured to report 50 tokens per request:
+The meter aggregates events from the gateway; the per-request quantity comes
+from the `MonetizationInboundPolicy`. Set a fixed cost per request in the
+policy's `meters` option, or call
+[`MonetizationInboundPolicy.setMeters`](./monetization-policy.md#dynamic-metering)
+from a custom outbound policy to report a value derived from the response — for
+example, the actual token count an LLM returned. An event for a request that
+consumed 50 tokens looks like this:
 
 ```json
 {
@@ -83,7 +96,7 @@ configured to report 50 tokens per request:
   "specversion": "1.0",
   "type": "tokens",
   "source": "monetization-policy",
-  "subject": "customer-id",
+  "subject": "01KNVXHQG356VA7T7W0V9N21GH",
   "subscription": "01KNVXHQG356VA7T7W0V9N21GH",
   "data": {
     "total": 50
@@ -113,7 +126,7 @@ Each event reports the number of bytes transferred:
   "specversion": "1.0",
   "type": "data_transfer",
   "source": "monetization-policy",
-  "subject": "customer-id",
+  "subject": "01KNVXHQG356VA7T7W0V9N21GH",
   "subscription": "01KNVXHQG356VA7T7W0V9N21GH",
   "data": {
     "total": 4096

package/docs/articles/monetization/monetization-policy.md

@@ -53,8 +53,8 @@ Then reference it in your route's inbound policy pipeline:
 
 The `MonetizationInboundPolicy` handles API key authentication internally. It
 reads the API key from the `Authorization` header, validates it, and sets
-`request.user`. You do not need a separate `api-key-auth` policy on monetized
-routes — the monetization policy replaces it.
+`request.user`. You do not need a separate API key authentication policy
+(`api-key-inbound`) on monetized routes — the monetization policy replaces it.
 
 :::
 
@@ -62,7 +62,7 @@ routes — the monetization policy replaces it.
 
 | Option               | Type               | Default           | Description                                       |
 | -------------------- | ------------------ | ----------------- | ------------------------------------------------- |
-| `meters`             | object             | (required)        | Map of meter keys to increment values             |
+| `meters`             | object             | _(none)_          | Map of meter keys to increment values             |
 | `meterOnStatusCodes` | string or number[] | `"200-299"`       | Status code range to meter                        |
 | `authHeader`         | string             | `"authorization"` | Header to read the API key from                   |
 | `authScheme`         | string             | `"Bearer"`        | Expected auth scheme prefix                       |
@@ -71,7 +71,13 @@ routes — the monetization policy replaces it.
 ### `meters`
 
 The `meters` option defines which meters to increment and by how much when a
-request is processed. Values must be positive numbers.
+request is processed. Values must be non-negative numbers.
+
+If `meters` is omitted, the policy still authenticates the API key and validates
+the subscription's payment status, but no usage is recorded. If `meters` is
+provided, it must contain at least one entry — an empty object throws a
+configuration error. To track usage at runtime instead of from static config,
+see [Dynamic metering](#dynamic-metering).
 
 ```json
 // Increment the api_requests meter by 1 per request
@@ -143,16 +149,22 @@ When payment fails, a configurable grace period (default 3 days) allows
 continued access while retries are attempted. After the grace period, access is
 blocked until payment succeeds.
 
-The grace period is configurable via metadata on the plan or customer:
+The grace period resolves in this order, with each level overriding the one
+below it:
+
+1. **Customer metadata** — `zuplo_max_payment_overdue_days` on the customer
+2. **Plan metadata** — `zuplo_max_payment_overdue_days` on the plan
+3. **Bucket configuration** — `maxPaymentOverdueDays` on the bucket's
+   monetization configuration (PUT
+   `/v3/metering/{bucketId}/monetization-configuration`)
+4. **Default** — `3` days
 
-- Plan metadata key: `zuplo_max_payment_overdue_days`
-- Customer metadata key: `zuplo_max_payment_overdue_days`
-- Default: `3` (days)
+Set the value to `0` to block requests immediately when payment is overdue.
 
 ## Multiple policies for different routes
 
 Different routes can have different metering configurations. Define multiple
-policy instances:
+policy instances in `policies.json`:
 
 ```json
 [
@@ -284,17 +296,20 @@ the RFC 7807 Problem Details format:
 
 Common error details:
 
-| Condition                 | `detail` message                                                    |
-| ------------------------- | ------------------------------------------------------------------- |
-| No auth header            | `"No Authorization Header"`                                         |
-| Wrong auth scheme         | `"Invalid Authorization Scheme"`                                    |
-| Invalid API key           | `"API Key is invalid or does not have access to the API"`           |
-| Expired API key           | `"API Key has expired."`                                            |
-| Expired subscription      | `"API Key has an expired subscription."`                            |
-| Payment not made          | `"Payment has not been made."`                                      |
-| Payment overdue           | `"Payment is overdue. Please update your payment method."`          |
-| Quota exhausted           | `"API Key has exceeded the allowed limit for \"X\" meter."`         |
-| Meter not in subscription | `"API Key does not have \"X\" meter provided by the subscription."` |
+| Condition                       | `detail` message                                                    |
+| ------------------------------- | ------------------------------------------------------------------- |
+| No auth header                  | `"No Authorization Header"`                                         |
+| Wrong auth scheme               | `"Invalid Authorization Scheme"`                                    |
+| Empty key after the auth scheme | `"No key present"`                                                  |
+| Cached invalid key or 401       | `"Authorization Failed"`                                            |
+| Invalid API key                 | `"API Key is invalid or does not have access to the API"`           |
+| Expired API key                 | `"API Key has expired."`                                            |
+| Expired subscription            | `"API Key has an expired subscription."`                            |
+| Subscription has no payment     | `"Subscription payment status is not available."`                   |
+| Payment not made                | `"Payment has not been made."`                                      |
+| Payment overdue                 | `"Payment is overdue. Please update your payment method."`          |
+| Quota exhausted                 | `"API Key has exceeded the allowed limit for \"X\" meter."`         |
+| Meter not in subscription       | `"API Key does not have \"X\" meter provided by the subscription."` |
 
 ## Pipeline ordering
 

package/docs/articles/monetization/plans.mdx

@@ -73,9 +73,11 @@ Plans move through a defined lifecycle:
 This example creates a Pro plan with:
 
 - A 1-week free trial phase with 1,000 API calls
-- A default phase with $99/month subscription and 10,000 included API calls
-- Overage pricing at $0.01 per additional call
-- Static features for premium access
+- A `monthly_fee` flat-fee rate card on the default phase that charges $99 in
+  advance at the start of each billing period
+- A `usage_based` rate card with 10,000 included API requests per billing period
+  and $0.01 per request overage in arrears
+- A `priority_support` static feature granted on both phases
 
 For step-by-step examples building plans from simple to complex, see
 [Plan Examples](./plan-examples.mdx).
@@ -132,6 +134,18 @@ curl \
       "name": "Default",
       "duration": null,
       "rateCards": [
+        {
+          "type": "flat_fee",
+          "key": "monthly_fee",
+          "name": "Monthly Fee",
+          "featureKey": "monthly_fee",
+          "billingCadence": "P1M",
+          "price": {
+            "type": "flat",
+            "amount": "99.00",
+            "paymentTerm": "in_advance"
+          }
+        },
         {
           "type": "usage_based",
           "key": "api_requests",
@@ -150,8 +164,8 @@ curl \
             "tiers": [
               {
                 "upToAmount": "10000",
-                "flatPrice": { "type": "flat", "amount": "99.00" },
-                "unitPrice": null
+                "flatPrice": null,
+                "unitPrice": { "type": "unit", "amount": "0.00" }
               },
               {
                 "flatPrice": null,
@@ -186,9 +200,12 @@ EOF
 | Trial   | 1 week   | 1,000 (hard limit) | Free      |
 | Default | Ongoing  | 10,000 included    | $99/month |
 
-After the trial ends, customers automatically move to the default phase. In the
-default phase, the first 10,000 API requests are included in the $99 monthly
-fee. Additional requests are billed at $0.01 each (soft limit allows overage).
+After the trial ends, customers automatically move to the default phase. The $99
+monthly subscription fee is charged in advance at the start of each billing
+period via the `monthly_fee` flat-fee rate card. The plan includes 10,000 API
+requests per period; additional requests are billed at $0.01 each in arrears
+(the soft limit on the metered entitlement allows overage to flow through to the
+next invoice).
 
 ## Plan Properties
 

package/docs/articles/monetization/private-plans.md

@@ -107,6 +107,15 @@ curl -X POST "https://dev.zuplo.com/v3/metering/${ZUPLO_BUCKET_ID}/plans" \
 
 Save the returned `id` — you need it to publish and invite users.
 
+:::note
+
+The plan `id` is a 26-character ULID (regex
+`^[0-7][0-9A-HJKMNP-TV-Za-hjkmnp-tv-z]{25}$`), separate from the human-friendly
+`key` you set on creation. The publish, invite, and other plan-scoped endpoints
+require the `id`, not the `key`.
+
+:::
+
 The key difference from a public plan is `metadata.zuplo_private_plan` set to
 `"true"`. Everything else (rate cards, entitlements, pricing) works the same as
 public plans.

package/docs/articles/monetization/quickstart.md

@@ -284,22 +284,27 @@ directory.
 3. In the **Meters** configuration field, set the key to `api_requests` with a
    value of `1` to match the meter you created in _Step 4_. This field maps the
    meter slug to the number of units each request consumes.
+4. Click on **Create Policy**.
+
+The Portal saves the policy to `policies.json` as a complete entry:
 
 ```json
 {
-  "export": "MonetizationInboundPolicy",
-  "module": "$import(@zuplo/runtime)",
-  "options": {
-    "cacheTtlSeconds": 60,
-    "meters": {
-      "api_requests": 1
+  "name": "monetization-inbound",
+  "policyType": "monetization-inbound",
+  "handler": {
+    "export": "MonetizationInboundPolicy",
+    "module": "$import(@zuplo/runtime)",
+    "options": {
+      "cacheTtlSeconds": 60,
+      "meters": {
+        "api_requests": 1
+      }
     }
   }
 }
 ```
 
-4. Click on **Create Policy**.
-
 ### Apply the policy to routes
 
 Next, you need to apply the Monetization policy to some or all of your routes.
@@ -317,7 +322,8 @@ Next, you need to apply the Monetization policy to some or all of your routes.
 :::note
 
 The `MonetizationInboundPolicy` handles API key authentication internally. You
-do not need a separate `api-key-auth` policy on monetized routes.
+do not need a separate API key authentication policy (`api-key-inbound`) on
+monetized routes.
 
 :::