weft-sdk 0.20.0 → 0.23.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: d6354ce719c8a0573a4da6fea705eaf7c56081a44bc5ca40e0dd653aa91e07d3
-  data.tar.gz: 90fd2107ae49569850e283306d07d5134f957720821b02a5f3c63f0bfc8dcbb7
+  metadata.gz: 496745e7229c81042ea41746e4f0c5a00bd46a4cf5e964651e79157642d755d1
+  data.tar.gz: 014f6dc6324e9c6f6120ae568c16524e4d7880b6572a2171bda52d90f728690c
 SHA512:
-  metadata.gz: ccd9f3325d4b9be29dd6039fc010973b59e3711496e2f625b435ed1d64321615e09a91d01063eceaf7e3b7baaca18439f3c9f4c26f0beba2fcdc125e8231ad61
-  data.tar.gz: f4d356e750eb05e5ac46b6f04e6a0aac993753067dffbd0765ac9055fab892f2480c5c034364476dd9b6e1d0c263a2de146e3490da8b9df3add392f1417b1005
+  metadata.gz: 5cab73a68d4cb1bad75c9d6dce873967b63f4dcc8dbd1490b8da9cea9ee89a403f1208a7d5a2bea04f87e1011d90d4adf9aba76d5b63c6909c2e9943e4da5916
+  data.tar.gz: d116db0df639eae14f5679e39f1624a1557a334eb72f4d73a56a3de26cae46f9f51b7a9f4ec85a854e095d90fb4f4322ec0f972440015782b79ea8685e518e72

data/docs/{DefaultApi.md → DocumentationApi.md}

@@ -1,10 +1,10 @@
-# Weft::DefaultApi
+# Weft::DocumentationApi
 
 All URIs are relative to *https://weft.network*
 
 | Method | HTTP request | Description |
 | ------ | ------------ | ----------- |
-| [**get_open_api_document**](DefaultApi.md#get_open_api_document) | **GET** /docs/openapi.yaml | Fetch this OpenAPI document |
+| [**get_open_api_document**](DocumentationApi.md#get_open_api_document) | **GET** /docs/openapi.yaml | Fetch this OpenAPI document |
 
 
 ## get_open_api_document
@@ -19,14 +19,14 @@ Fetch this OpenAPI document
 require 'time'
 require 'weft-sdk'
 
-api_instance = Weft::DefaultApi.new
+api_instance = Weft::DocumentationApi.new
 
 begin
   # Fetch this OpenAPI document
   result = api_instance.get_open_api_document
   p result
 rescue Weft::ApiError => e
-  puts "Error when calling DefaultApi->get_open_api_document: #{e}"
+  puts "Error when calling DocumentationApi->get_open_api_document: #{e}"
 end
 ```
 
@@ -44,7 +44,7 @@ begin
   p headers # => { ... }
   p data # => String
 rescue Weft::ApiError => e
-  puts "Error when calling DefaultApi->get_open_api_document_with_http_info: #{e}"
+  puts "Error when calling DocumentationApi->get_open_api_document_with_http_info: #{e}"
 end
 ```
 

data/docs/FetchApi.md

@@ -4,16 +4,16 @@ All URIs are relative to *https://weft.network*
 
 | Method | HTTP request | Description |
 | ------ | ------------ | ----------- |
-| [**fetch**](FetchApi.md#fetch) | **POST** /api/v1/fetch | Pay-and-fetch any URL (x402 proxy) |
+| [**fetch**](FetchApi.md#fetch) | **POST** /api/v1/fetch | Pay-and-fetch any URL (x402/MPP proxy) |
 
 
 ## fetch
 
 > <FetchResponse> fetch(fetch_request, opts)
 
-Pay-and-fetch any URL (x402 proxy)
+Pay-and-fetch any URL (x402/MPP proxy)
 
-Universal x402 fetch proxy. The caller provides a target `url`, a hard `max_cost_usd` ceiling, and optional `method` / `body` / `headers`. Weft:    1. Issues the request.   2. On `402 Payment Required`, parses the merchant's challenge.   3. Compares the asking price to `max_cost_usd` and the      buyer's policy (`max_tx_usd`, daily/weekly limits).   4. Signs an EIP-3009 transfer from the buyer's wallet.   5. Replays the request with the `X-Payment` header.   6. Streams the upstream artifact back, base64-encoded under      `body_base64`, with `paid_usd`, `held_usd`, `payment_status`,      `tx_hash`, and the merchant's reputation snapshot. `paid_usd`      is \"0.00\" until the charge is CONFIRMED settled — a signed-but-      unsettled hold (the common case for x402, which settles      asynchronously) reports its amount in `held_usd` instead, never      in `paid_usd`.  Errors are structured with a stable `error` code, and each error response carries the buyer's `policy`, `balance`, and a `dashboard_url` so a CLI can render an actionable message without a second round-trip.  Account-scoped: the bearer must be a buyer-scoped API key, an OAuth access token carrying `fetch`, or a claimed `wbt_*` bearer.  **Forwarded headers:** the caller's `headers` are passed through to the upstream, except a denylist of hop-by-hop and Weft-internal headers (`host`, `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-*`, `x-real-ip`, `x-payment`, `connection`, `upgrade`). Up to 32 headers, 4 KB of combined value bytes.
+Universal x402/MPP fetch proxy. The caller provides a target `url`, a hard `max_cost_usd` ceiling, and optional `method` / `body` / `headers`. Weft:    1. Issues the request.   2. On `402 Payment Required`, selects a supported x402 or MPP challenge.   3. Compares the asking price to `max_cost_usd` and the      buyer's policy (`max_tx_usd`, daily/weekly limits).   4. Authorizes payment from the buyer's wallet on the selected rail.   5. Replays the request with the protocol-specific payment credential.   6. Streams the upstream artifact back, base64-encoded under       `body_base64`, with `paid_usd`, `held_usd`, `payment_status`,       `tx_hash`, `protocol`, and the merchant's reputation snapshot. `paid_usd`      is \"0.00\" until the charge is CONFIRMED settled — a signed-but-      unsettled hold (the common case for x402, which settles      asynchronously) reports its amount in `held_usd` instead, never      in `paid_usd`.  Errors are structured with a stable `error` code, and each error response carries the buyer's `policy`, `balance`, and a `dashboard_url` so a CLI can render an actionable message without a second round-trip.  Account-scoped: the bearer must be a buyer-scoped API key, an OAuth access token carrying `fetch`, or a claimed `wbt_*` bearer.  **Forwarded headers:** the caller's `headers` are passed through to the upstream, except a denylist of hop-by-hop and Weft-internal headers (`host`, `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-*`, `x-real-ip`, `x-payment`, `connection`, `upgrade`). Up to 32 headers, 4 KB of combined value bytes.
 
 ### Examples
 
@@ -33,7 +33,7 @@ opts = {
 }
 
 begin
-  # Pay-and-fetch any URL (x402 proxy)
+  # Pay-and-fetch any URL (x402/MPP proxy)
   result = api_instance.fetch(fetch_request, opts)
   p result
 rescue Weft::ApiError => e
@@ -49,7 +49,7 @@ This returns an Array which contains the response data, status code and headers.
 
 ```ruby
 begin
-  # Pay-and-fetch any URL (x402 proxy)
+  # Pay-and-fetch any URL (x402/MPP proxy)
   data, status_code, headers = api_instance.fetch_with_http_info(fetch_request, opts)
   p status_code # => 2xx
   p headers # => { ... }

data/docs/FetchBalanceSnapshot.md

@@ -6,7 +6,7 @@
 | ---- | ---- | ----------- | ----- |
 | **promo_usd** | **String** |  |  |
 | **wallet_usdc** | **String** | Live Base USDC balance read server-side through Crossmint. Null when Crossmint is unavailable; never treat null as zero.  |  |
-| **total_usd** | **String** | Aggregated USD balance (Base USDC), exact to the micro-dollar. Null when the Base USDC provider is unreachable.  |  |
+| **total_usd** | **String** | Aggregated USD balance across Base USDC and Tempo dollar tokens, exact to the micro-dollar. Null when either pocket is unreachable.  |  |
 | **spent_today_usd** | **String** |  |  |
 
 ## Example

data/docs/FetchResponse.md

@@ -7,12 +7,13 @@
 | **status** | **Integer** | HTTP status returned by the upstream after the paid replay. |  |
 | **headers** | **Hash<String, String>** | Response headers from the upstream. |  |
 | **body_base64** | **String** | Base64-encoded response body. Empty string for empty bodies. |  |
-| **paid_usd** | **String** | USD amount actually settled on-chain. \"0.00\" for free upstreams AND for any charge that hasn't (yet, or ever) settled — a signed hold is not yet spend. See `held_usd` for the nominal amount in that case. Exact to the micro-dollar, minimum two decimals; parse as a decimal rather than string-comparing against a bare zero literal.  |  |
-| **held_usd** | **String** | The nominal charge amount when `paid_usd` is \"0.00\" — a hold awaiting settlement, or a charge that failed/expired without ever settling. `null` once `paid_usd` reflects the real settlement (or for a free upstream, where nothing was ever charged). Same format as `paid_usd`: exact to the micro-dollar, minimum two decimals.  |  |
+| **paid_usd** | **String** | USD amount actually settled on-chain. \"0.00\" for any charge that hasn't (yet, or ever) settled — a signed hold is not yet spend. See `held_usd` for the nominal amount in that case. Exact to the micro-dollar, minimum two decimals; parse as a decimal rather than string-comparing against a bare zero literal.  |  |
+| **held_usd** | **String** | The nominal charge amount when `paid_usd` is \"0.00\" — a hold awaiting settlement, or a charge that failed/expired without ever settling. `null` once `paid_usd` reflects the real settlement. Same format as `paid_usd`: exact to the micro-dollar, minimum two decimals.  |  |
 | **payment_status** | **String** | Agent-facing settlement status. `pending` = signed, no refusal signal yet (settlement may still land, e.g. x402's async facilitator webhook). `declined-pending` = the merchant refused but the authorization isn't provably dead yet. `declined` / `expired` / `reverted` are terminal — the money never moved (or, for `reverted`, moved and then reversed on-chain) and never will for this charge.  |  |
-| **tx_hash** | **String** | Settlement transaction hash. Null for free upstreams. |  |
+| **tx_hash** | **String** | Settlement transaction hash. Null until a settlement hash has been reported. |  |
+| **protocol** | **String** | Payment protocol selected for this fetch. |  |
 | **artifact_id** | **Integer** | Internal artifact identifier if the response was persisted; `null` otherwise. |  |
-| **merchant** | [**Merchant**](Merchant.md) | Merchant reputation snapshot. Null for free upstreams. |  |
+| **merchant** | [**Merchant**](Merchant.md) | Merchant reputation snapshot. |  |
 
 ## Example
 
@@ -27,6 +28,7 @@ instance = Weft::FetchResponse.new(
   held_usd: 0.002,
   payment_status: pending,
   tx_hash: null,
+  protocol: null,
   artifact_id: null,
   merchant: null
 )

data/docs/Wallet.md

@@ -7,7 +7,8 @@
 | **provider** | **String** | Crossmint is the only buyer-wallet provider. |  |
 | **address** | **String** | Base smart-wallet address. Null only when Crossmint is unavailable. |  |
 | **balance_usdc** | **String** | Live Base USDC balance, exact to the micro-dollar (up to 6 decimals, minimum 2). Null when Crossmint is unreachable; consumers must not interpret null as zero.  |  |
-| **total_usd** | **String** | Single aggregated USD balance (Base USDC), exact to the micro-dollar. Null when the provider is unreachable, because the surface never claims zero for a component it could not read.  |  |
+| **balance_tempo_usd** | **String** | Live aggregate Tempo dollar-token balance, exact to the micro-dollar (up to 6 decimals, minimum 2). Null when Crossmint is unreachable; consumers must not interpret null as zero.  |  |
+| **total_usd** | **String** | Single aggregated USD balance across Base USDC and Tempo dollar tokens, exact to the micro-dollar. Null when either pocket is unreachable, because the surface never claims zero for a component it could not read.  |  |
 | **network** | **String** | Selected Crossmint environment (`base_sepolia` or `base_mainnet`).  |  |
 
 ## Example
@@ -19,6 +20,7 @@ instance = Weft::Wallet.new(
   provider: null,
   address: null,
   balance_usdc: 12.34,
+  balance_tempo_usd: 2.03,
   total_usd: 12.34,
   network: null
 )

data/lib/weft/generated/api/account_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/agent_bootstrap_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/api_keys_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/auth_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/balance_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/{default_api.rb → documentation_api.rb}

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0
@@ -13,7 +13,7 @@ Generator version: 7.19.0
 require 'cgi'
 
 module Weft
-  class DefaultApi
+  class DocumentationApi
     attr_accessor :api_client
 
     def initialize(api_client = ApiClient.default)
@@ -32,7 +32,7 @@ module Weft
     # @return [Array<(String, Integer, Hash)>] String data, response status code and response headers
     def get_open_api_document_with_http_info(opts = {})
       if @api_client.config.debugging
-        @api_client.config.logger.debug 'Calling API: DefaultApi.get_open_api_document ...'
+        @api_client.config.logger.debug 'Calling API: DocumentationApi.get_open_api_document ...'
       end
       # resource path
       local_var_path = '/docs/openapi.yaml'
@@ -58,7 +58,7 @@ module Weft
       auth_names = opts[:debug_auth_names] || []
 
       new_options = opts.merge(
-        :operation => :"DefaultApi.get_open_api_document",
+        :operation => :"DocumentationApi.get_open_api_document",
         :header_params => header_params,
         :query_params => query_params,
         :form_params => form_params,
@@ -69,7 +69,7 @@ module Weft
 
       data, status_code, headers = @api_client.call_api(:GET, local_var_path, new_options)
       if @api_client.config.debugging
-        @api_client.config.logger.debug "API called: DefaultApi#get_open_api_document\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+        @api_client.config.logger.debug "API called: DocumentationApi#get_open_api_document\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
       end
       return data, status_code, headers
     end

data/lib/weft/generated/api/fetch_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0
@@ -19,8 +19,8 @@ module Weft
     def initialize(api_client = ApiClient.default)
       @api_client = api_client
     end
-    # Pay-and-fetch any URL (x402 proxy)
-    # Universal x402 fetch proxy. The caller provides a target `url`, a hard `max_cost_usd` ceiling, and optional `method` / `body` / `headers`. Weft:    1. Issues the request.   2. On `402 Payment Required`, parses the merchant's challenge.   3. Compares the asking price to `max_cost_usd` and the      buyer's policy (`max_tx_usd`, daily/weekly limits).   4. Signs an EIP-3009 transfer from the buyer's wallet.   5. Replays the request with the `X-Payment` header.   6. Streams the upstream artifact back, base64-encoded under      `body_base64`, with `paid_usd`, `held_usd`, `payment_status`,      `tx_hash`, and the merchant's reputation snapshot. `paid_usd`      is \"0.00\" until the charge is CONFIRMED settled — a signed-but-      unsettled hold (the common case for x402, which settles      asynchronously) reports its amount in `held_usd` instead, never      in `paid_usd`.  Errors are structured with a stable `error` code, and each error response carries the buyer's `policy`, `balance`, and a `dashboard_url` so a CLI can render an actionable message without a second round-trip.  Account-scoped: the bearer must be a buyer-scoped API key, an OAuth access token carrying `fetch`, or a claimed `wbt_*` bearer.  **Forwarded headers:** the caller's `headers` are passed through to the upstream, except a denylist of hop-by-hop and Weft-internal headers (`host`, `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-*`, `x-real-ip`, `x-payment`, `connection`, `upgrade`). Up to 32 headers, 4 KB of combined value bytes.
+    # Pay-and-fetch any URL (x402/MPP proxy)
+    # Universal x402/MPP fetch proxy. The caller provides a target `url`, a hard `max_cost_usd` ceiling, and optional `method` / `body` / `headers`. Weft:    1. Issues the request.   2. On `402 Payment Required`, selects a supported x402 or MPP challenge.   3. Compares the asking price to `max_cost_usd` and the      buyer's policy (`max_tx_usd`, daily/weekly limits).   4. Authorizes payment from the buyer's wallet on the selected rail.   5. Replays the request with the protocol-specific payment credential.   6. Streams the upstream artifact back, base64-encoded under       `body_base64`, with `paid_usd`, `held_usd`, `payment_status`,       `tx_hash`, `protocol`, and the merchant's reputation snapshot. `paid_usd`      is \"0.00\" until the charge is CONFIRMED settled — a signed-but-      unsettled hold (the common case for x402, which settles      asynchronously) reports its amount in `held_usd` instead, never      in `paid_usd`.  Errors are structured with a stable `error` code, and each error response carries the buyer's `policy`, `balance`, and a `dashboard_url` so a CLI can render an actionable message without a second round-trip.  Account-scoped: the bearer must be a buyer-scoped API key, an OAuth access token carrying `fetch`, or a claimed `wbt_*` bearer.  **Forwarded headers:** the caller's `headers` are passed through to the upstream, except a denylist of hop-by-hop and Weft-internal headers (`host`, `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-*`, `x-real-ip`, `x-payment`, `connection`, `upgrade`). Up to 32 headers, 4 KB of combined value bytes.
     # @param fetch_request [FetchRequest]
     # @param [Hash] opts the optional parameters
     # @option opts [String] :idempotency_key Opaque caller-generated retry key. Reusing the same key for the same buyer converges on one paid fetch; keys are hashed and namespaced by buyer before storage. Send this header for every unattended or retryable paid request.
@@ -30,8 +30,8 @@ module Weft
       data
     end
 
-    # Pay-and-fetch any URL (x402 proxy)
-    # Universal x402 fetch proxy. The caller provides a target `url`, a hard `max_cost_usd` ceiling, and optional `method` / `body` / `headers`. Weft:    1. Issues the request.   2. On `402 Payment Required`, parses the merchant's challenge.   3. Compares the asking price to `max_cost_usd` and the      buyer's policy (`max_tx_usd`, daily/weekly limits).   4. Signs an EIP-3009 transfer from the buyer's wallet.   5. Replays the request with the `X-Payment` header.   6. Streams the upstream artifact back, base64-encoded under      `body_base64`, with `paid_usd`, `held_usd`, `payment_status`,      `tx_hash`, and the merchant's reputation snapshot. `paid_usd`      is \"0.00\" until the charge is CONFIRMED settled — a signed-but-      unsettled hold (the common case for x402, which settles      asynchronously) reports its amount in `held_usd` instead, never      in `paid_usd`.  Errors are structured with a stable `error` code, and each error response carries the buyer's `policy`, `balance`, and a `dashboard_url` so a CLI can render an actionable message without a second round-trip.  Account-scoped: the bearer must be a buyer-scoped API key, an OAuth access token carrying `fetch`, or a claimed `wbt_*` bearer.  **Forwarded headers:** the caller's `headers` are passed through to the upstream, except a denylist of hop-by-hop and Weft-internal headers (`host`, `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-*`, `x-real-ip`, `x-payment`, `connection`, `upgrade`). Up to 32 headers, 4 KB of combined value bytes.
+    # Pay-and-fetch any URL (x402/MPP proxy)
+    # Universal x402/MPP fetch proxy. The caller provides a target `url`, a hard `max_cost_usd` ceiling, and optional `method` / `body` / `headers`. Weft:    1. Issues the request.   2. On `402 Payment Required`, selects a supported x402 or MPP challenge.   3. Compares the asking price to `max_cost_usd` and the      buyer's policy (`max_tx_usd`, daily/weekly limits).   4. Authorizes payment from the buyer's wallet on the selected rail.   5. Replays the request with the protocol-specific payment credential.   6. Streams the upstream artifact back, base64-encoded under       `body_base64`, with `paid_usd`, `held_usd`, `payment_status`,       `tx_hash`, `protocol`, and the merchant's reputation snapshot. `paid_usd`      is \"0.00\" until the charge is CONFIRMED settled — a signed-but-      unsettled hold (the common case for x402, which settles      asynchronously) reports its amount in `held_usd` instead, never      in `paid_usd`.  Errors are structured with a stable `error` code, and each error response carries the buyer's `policy`, `balance`, and a `dashboard_url` so a CLI can render an actionable message without a second round-trip.  Account-scoped: the bearer must be a buyer-scoped API key, an OAuth access token carrying `fetch`, or a claimed `wbt_*` bearer.  **Forwarded headers:** the caller's `headers` are passed through to the upstream, except a denylist of hop-by-hop and Weft-internal headers (`host`, `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-*`, `x-real-ip`, `x-payment`, `connection`, `upgrade`). Up to 32 headers, 4 KB of combined value bytes.
     # @param fetch_request [FetchRequest]
     # @param [Hash] opts the optional parameters
     # @option opts [String] :idempotency_key Opaque caller-generated retry key. Reusing the same key for the same buyer converges on one paid fetch; keys are hashed and namespaced by buyer before storage. Send this header for every unattended or retryable paid request.

data/lib/weft/generated/api/payments_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/purchases_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/resources_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api/search_api.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api_client.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api_error.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/api_model_base.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/configuration.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/models/account_bootstrap_approval.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/models/account_bootstrap_created.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0

data/lib/weft/generated/models/account_bootstrap_created_approval.rb

@@ -1,9 +1,9 @@
 =begin
 #Weft API
 
-#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
+#The Weft API powers the `weft` CLI, the hosted MCP server (`weft.network/mcp`), and third-party applications that discover and pay for resources on Weft. The buyer runtime covers six concerns:    1. Account creation and recovery (`/api/v1/auth/*`)   2. Credential identity (`/api/v1/me`)   3. Wallet visibility (`/api/v1/balance`)   4. Discovery (`/api/v1/search`)   5. Paid execution (`/api/v1/fetch`)   6. Purchase history (`/api/v1/purchases`)  Buyer runtime calls require a dashboard-created `wk_*` account key, an OAuth access token with the relevant scope, or a claimed `wbt_*` bearer on its fixed allowlist. The organization-scoped API key and payment operations in this document are seller administration surfaces and require an `ax_live_*` resource key. These credential types are not interchangeable.  This document is a deliberate subset of the `/api/v1` surface, not an inventory of it. The seller-side management endpoints — `/api/v1/agents`, `/api/v1/webhook_endpoints`, and `/api/v1/analytics` — are reachable with an `ax_live_*` key but are intentionally left undocumented: they are dashboard-facing and not part of the published client contract. Nothing outside this document is a supported contract, and the response-validation gate in `config/environments/test.rb` enforces only what is declared here.  Before claim, a `wbt_*` bearer is temporary and permits only search plus its own status/cancel operations for 30 minutes. Human approval binds it to the User and promotes the same secret to durable identity, search, balance, fetch, purchase-history, status, and revocation capabilities. It remains valid until revoked. Seller, organization, API-key administration, dashboard-session, transfer, withdrawal, and MCP surfaces always refuse it.  Bootstrap lifecycle successes follow the API-standard `{ \"data\": ... }` envelope. All errors share the envelope defined by `ErrorResponse`, except the buyer-runtime endpoints (`/search`, `/fetch`) which use bespoke envelopes carrying additional context — see `SearchErrorResponse` and `FetchErrorResponse`.
 
-The version of the OpenAPI document: 0.20.0
+The version of the OpenAPI document: 0.23.0
 
 Generated by: https://openapi-generator.tech
 Generator version: 7.19.0