zuplo 6.69.1 → 6.69.3

package/docs/articles/monetization/meters.mdx

@@ -35,9 +35,9 @@ Track the total number of API requests:
 
 ```json
 {
-  "slug": "requests",
+  "slug": "api_requests",
   "name": "API Requests",
-  "eventType": "requests",
+  "eventType": "api_requests",
   "aggregation": "SUM",
   "valueProperty": "$.total"
 }
@@ -50,7 +50,7 @@ Each event contains the `subscription` ID linking it to a subscription and a
 {
   "id": "5c10fade-1c9e-4d6c-8275-c52c36731d3c",
   "specversion": "1.0",
-  "type": "requests",
+  "type": "api_requests",
   "source": "monetization-policy",
   "subject": "customer-id",
   "subscription": "01KNVXHQG356VA7T7W0V9N21GH",
@@ -142,9 +142,9 @@ curl \
   --header "Content-Type: application/json" \
   --data @- << EOF
 {
-  "slug": "requests",
+  "slug": "api_requests",
   "name": "API Requests",
-  "eventType": "requests",
+  "eventType": "api_requests",
   "aggregation": "SUM",
   "valueProperty": "$.total"
 }

package/docs/articles/monetization/quickstart.md

@@ -84,7 +84,8 @@ Add the monetization plugin to your Developer Portal configuration.
 ## Step 3: Configure the Monetization Service
 
 1. Navigate to the **Services** tab in your project.
-2. Select the environment you want to configure (e.g., **Working Copy**).
+2. Select the environment you want to configure. We will use **Working Copy**
+   for this quickstart.
 3. Click **Configure** on the **Monetization Service** card.
 
 ## Step 4: Create a meter
@@ -93,11 +94,11 @@ Meters track what you want to measure — API calls, tokens processed, data
 transferred, etc.
 
 1. In the Monetization Service, click the **Meters** tab.
-2. Click **Add Meter** and select **Blank Meter**.
-3. Fill in the meter details:
-   - **Name**: `Requests`
-   - **Event**: `requests` — the type of event this meter listens for.
-   - **Description**: `API Requests`
+2. Click **Add Meter** and select **API Requests** from the template list.
+3. Verify the pre-filled meter details:
+   - **Name**: `API Requests`
+   - **Event**: `api_requests` — the type of event this meter listens for.
+   - **Description**: `Counts all incoming API requests`
    - **Aggregation**: `SUM` — how values are combined (other options include
      `COUNT`, `MAX`, etc.).
    - **Value Property**: `$.total` — a JSONPath expression that extracts the
@@ -115,15 +116,18 @@ Feature** for each of the following:
 
 | Name             | Key                | Linked Meter | Purpose                       |
 | ---------------- | ------------------ | ------------ | ----------------------------- |
-| API Requests     | `requests`         | Requests     | Usage-based (linked to meter) |
+| API Requests     | `api_requests`     | API Requests | Usage-based (linked to meter) |
 | Monthly Fee      | `monthly_fee`      | —            | Flat-rate billing             |
 | Metadata Support | `metadata_support` | —            | Boolean on/off feature        |
 
 :::tip{title="Key Naming Conventions"}
 
-When creating features that are metered, the key must match the key you set for
-the associated meter. For example, if your Requests meter key is `requests`,
-then your Requests feature key must also be `requests`.
+The meter key, the feature key, and the key in the monetization policy's
+`meters` configuration must all match. For example, the API Requests meter key
+is `api_requests`, the feature key must also be `api_requests`, and the policy
+must use `"meters": { "api_requests": 1 }`.
+
+See [Naming Consistency](./meters.mdx#naming-consistency) for the full rule.
 
 :::
 
@@ -243,10 +247,13 @@ charges.
 
 :::warning
 
-Always use your Stripe **test** key (`sk_test_...`) while following this guide.
-This creates a sandbox environment where you can safely test subscriptions and
-payments without processing real transactions. When you're ready for production,
-update to your live key (`sk_live_...`).
+Always use your Stripe **test** key (`sk_test_...`) in the **Working Copy**
+environment while following this guide. Stripe test keys run in a sandbox
+environment where you can safely test subscriptions and payments without
+processing real transactions. When you're ready for production, configure the
+**Production** environment with a live key (`sk_live_...`). Do not replace a
+test key with a live key in the same environment — use one key type per
+environment.
 
 :::
 
@@ -265,9 +272,9 @@ directory.
 
 ![Monetization policy in the policy picker list](../../../public/media/monetization/monetization-policy.png)
 
-3. In the **Meters** configuration field, you can keep the default value of
-   `requests` set `1` to match the meter you created in _Step 4_. This field
-   maps the meter slug to the number of units each request consumes.
+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.
 
 ```json
 {
@@ -276,7 +283,7 @@ directory.
   "options": {
     "cacheTtlSeconds": 60,
     "meters": {
-      "requests": 1
+      "api_requests": 1
     }
   }
 }

package/docs/articles/monetization/stripe-integration.md

@@ -54,13 +54,15 @@ Connect with a Stripe **test** key (`sk_test_...`) first to validate your
 configuration end-to-end. Test mode uses Stripe's test card numbers (e.g.,
 `4242 4242 4242 4242`) and never charges real money.
 
-When you're ready to go live, update to your live key (`sk_live_...`).
+When you're ready to go live, configure a separate Zuplo environment (e.g.,
+**Production**) with your live key (`sk_live_...`).
 
 :::caution
 
-Always use your Stripe **test** key while developing. Test mode and live mode
-are separate environments in Stripe. Products, customers, and subscriptions
-don't transfer between them.
+Use one Stripe key type per Zuplo environment — do not replace a test key with a
+live key in the same environment. Test mode and live mode are separate
+environments in Stripe. Products, customers, and subscriptions created in test
+mode don't transfer to live mode and vice versa.
 
 :::
 

package/docs/articles/tunnel-setup.mdx

@@ -22,6 +22,26 @@ A tunnel is a way to expose your _internal services_ to the Zuplo gateway
 without exposing it to the public internet. Your Zuplo Gateway accesses those
 services through the `service://` protocol.
 
+## Create the tunnel
+
+Before you deploy the tunnel container, create the tunnel in Zuplo using the
+CLI. This gives you the tunnel record in your account and the token that you
+will later provide to the container as `TUNNEL_TOKEN`.
+
+```bash
+zuplo tunnel create --tunnel-name <your-tunnel-name>
+zuplo tunnel list
+zuplo tunnel describe --tunnel-id <your-tunnel-id>
+```
+
+Use these commands as follows:
+
+1. Run `zuplo tunnel create` to create the tunnel.
+1. Run `zuplo tunnel list` to see the tunnels in your account and identify the
+   tunnel ID if you need it.
+1. Run `zuplo tunnel describe` with the tunnel ID to retrieve the tunnel details
+   and copy the token value you will use for `TUNNEL_TOKEN`.
+
 The easiest way to deploy your tunnel is using a Docker container. The three
 basic requirements for deploying a secure tunnel with Docker are:
 

package/package.json

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