@zeroxyz/sdk 0.2.0 → 0.3.0

package/CHANGELOG.md

@@ -4,6 +4,16 @@ All notable changes to `@zeroxyz/sdk` will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html) — with the pre-1.0 caveat that minor versions may include breaking changes.
 
+## 0.3.0
+
+### Added
+
+- `SearchResult` now carries `method` (the capability's HTTP verb) and `brandName`. Both are already returned by the search API but were previously stripped by the SDK's response schema. Surfacing `method` lets a caller tell GET from POST straight from a search result — enough to `fetch()` a no-body GET without a `capabilities.get()` round-trip. Both fields are optional, so a response that omits them still parses. (#593)
+
+### Documentation
+
+- Expanded the README with a **Wallet & funding** section (`wallet.balance()` / `wallet.fundingUrl()`), the full `FetchResult` shape, the `runId`-requires-`capabilityId` precondition, and search → get → fetch guidance. (#593)
+
 ## 0.2.0
 
 ### Changed

package/README.md

@@ -25,7 +25,7 @@ const client = new ZeroClient();
 
 const { capabilities } = await client.search("current weather in tokyo");
 for (const cap of capabilities) {
-  console.log(cap.id, cap.name, cap.url, cap.availabilityStatus);
+  console.log(cap.id, cap.name, cap.method, cap.url, cap.availabilityStatus);
 }
 ```
 
@@ -102,6 +102,8 @@ The SDK refreshes the access token automatically after a `401`, and every refres
 
 Endpoints that don't charge pass straight through: a `200` on the first request returns with `payment: null` and `outcome: "success"`. No payment is attempted.
 
+**Building the request — search → get → fetch.** A `search()` result carries the `url` and `method`, so a no-body `GET` capability can go straight to `fetch()`. For anything that takes a request body, call `capabilities.get()` first: its `bodySchema`, `method`, and `headers` are what tell you how to construct the call. Don't guess the body from the search summary.
+
 ```ts
 const result = await client.fetch(url, {
   method: "POST",
@@ -142,12 +144,65 @@ for (const warning of result.warnings ?? []) {
 }
 ```
 
+### The `FetchResult`
+
+`fetch()` always resolves to one object — it doesn't reject for expected runtime failures (those come back as an `outcome`; see [Errors](#errors)). The full shape:
+
+| Field | Type | Notes |
+| --- | --- | --- |
+| `outcome` | `FetchOutcome` | The closed enum above — branch on this first. |
+| `ok` | `boolean` | `true` iff `status` is 2xx. Convenience for the HTTP-success check; `outcome === "success"` is the same signal at the payment-and-HTTP level. |
+| `status` | `number \| null` | Upstream HTTP status; `null` if the request never reached the server. |
+| `body` | `unknown` | Parsed JSON when the response is JSON, otherwise the text (base64 for binary). |
+| `bodyRaw` | `string \| null` | The exact response text, for hashing/forwarding. `bodyEncoding: "base64"` is set when binary. |
+| `payment` | `PaymentResult \| null` | `{ protocol, chain, txHash, amount, asset, … }` when a payment settled; `null` on a free call. |
+| `runId` | `string \| null` | The recorded run, for `runs.review()`. **`null` unless you pass `capabilityId`** (and a wallet is configured). |
+| `latencyMs` | `number` | End-to-end call latency. |
+| `upstreamError` | `UpstreamError?` | Present on `server_error` — the capability's own 4xx/5xx detail. |
+| `warnings` | `string[]?` | Non-fatal notes (truncated body, MPP close failure, …) — keyed by `FETCH_WARNINGS`. |
+| `runTrackingSkipped` | `string[]?` | Why a run wasn't recorded (e.g. no `capabilityId`) — keyed by `FETCH_SKIP_REASONS`. |
+
+`capabilityId` accepts the capability's `uid` (`cap_…`) or `slug` — i.e. the `id`/`slug` from a `search()` result or the `uid`/`slug` from `capabilities.get()`.
+
 ### `maxPay`
 
 `maxPay` is your hard per-call ceiling, in USDC. The challenge amount is checked against it **before** anything is signed; an over-cap challenge aborts with `outcome: "payment_failed"` and no on-chain spend. Set it on every paid call — it's the guardrail that keeps a mispriced or hostile endpoint from draining the wallet.
 
 To put a human in the loop before any spend, read the price up front (`cost.amount` is on every search result and on `capabilities.get()`), show it to your user, and only call `fetch()` with `maxPay` once they approve.
 
+## Wallet & funding
+
+The wallet you construct the client with **is** the agent's identity — paid calls draw USDC from it, and there are no per-service API keys to provision. Keeping it funded is the only operational task. Two funding models, both first-class:
+
+- **Partner-funded shared wallet** *(the common default).* You hold one wallet on behalf of all your users, keep it topped up as a backend cost, and recoup it through your own billing. Per-user spend tracking and caps live in your app — `maxPay` is the per-call guard.
+- **End-user top-up.** Each user funds the wallet directly; you surface a funding link when their balance runs low. Pairs with a per-user wallet.
+
+The same two primitives serve both:
+
+```ts
+// The configured address (null in session mode until the first paid call resolves it).
+client.wallet.address;
+
+// Balance in USDC. Sums Base + Tempo by default; pass a chain for just one.
+const { amount } = await client.wallet.balance();          // e.g. "12.50"
+const onBase     = await client.wallet.balance({ chain: "base" });
+
+// A one-time hosted top-up link — Coinbase by default, or provider: "stripe".
+// USDC settles on Base.
+const url = await client.wallet.fundingUrl({ amount: "10" });
+```
+
+Poll `balance()` to decide when to top up. Then either open `fundingUrl()` yourself to refill the shared wallet — from an ops dashboard, a low-balance alert, or alongside a direct USDC transfer to `wallet.address` — or hand the link to the end user. Either way the link is **single-use** and burns when opened, so generate it at the moment of funding and don't pre-open one you intend to give to someone else.
+
+In **session mode** (acting for a Zero user) the wallet is Zero-managed, and a couple more methods apply:
+
+```ts
+await client.wallet.list();      // every wallet linked to the session user
+await client.wallet.provision(); // create the user's managed wallet (idempotent)
+```
+
+To move funds from a user's own (BYO) wallet into their Zero-managed wallet, sign an EIP-3009 `ReceiveWithAuthorization` and relay it with `client.wallet.migrateAuthorization(authorization)` — Zero pays the gas and sweeps the USDC to Base.
+
 ## Namespaces
 
 Beyond `search()` and `fetch()`, the client groups the rest of the API into resource namespaces:
@@ -162,10 +217,9 @@ const { capabilities } = await client.search("translate text to french", {
 // Capabilities — full detail for one capability by id
 const cap = await client.capabilities.get("cap_abc");
 
-// Wallet (account or session mode)
-const balance = await client.wallet.balance();                 // Base + Tempo
-const onBase  = await client.wallet.balance({ chain: "base" }); // a single chain
-const fundUrl = await client.wallet.fundingUrl({ amount: "10" }); // onramp link
+// Wallet — balance + one-time funding URL. See "Wallet & funding" above.
+const { amount } = await client.wallet.balance();
+const fundUrl    = await client.wallet.fundingUrl({ amount: "10" });
 
 // Runs — fetch() records these for you on paid calls; reach for them
 // directly when you want to log or review a call yourself

package/dist/{chunk-SLXRHGE4.js → chunk-FH6C6TXR.js}

@@ -1098,7 +1098,7 @@ var Payments = class {
 
 // package.json
 var package_default = {
-  version: "0.2.0"};
+  version: "0.3.0"};
 
 // src/version.ts
 var SDK_VERSION = package_default.version;
@@ -2677,8 +2677,15 @@ var searchResultSchema = z.object({
   slug: z.string(),
   name: z.string(),
   canonicalName: z.string().nullable().optional(),
+  brandName: z.string().nullable().optional(),
   description: z.string(),
   whatItDoes: z.string().nullable().optional(),
+  // HTTP verb the capability expects. Surfaced on the search row so a caller
+  // can tell GET from POST without a `capabilities.get()` round-trip — enough
+  // to `fetch()` a no-body GET directly. POST bodies still need `get()` for
+  // the `bodySchema`. Optional (not required) so a response that omits it —
+  // an older API deploy — still parses rather than failing the whole search.
+  method: z.string().optional(),
   url: z.string(),
   urlTemplate: z.string().nullable().optional(),
   cost: z.object({ amount: z.string(), asset: z.string() }),
@@ -3076,5 +3083,5 @@ var ZeroClient = class _ZeroClient {
 };
 
 export { Auth, AuthDevice, BUG_REPORT_CATEGORIES, BugReports, Capabilities, DEFAULT_BASE_URL, DEFAULT_MAX_RETRIES, DEFAULT_TIMEOUT_MS, FETCH_SKIP_REASONS, FETCH_WARNINGS, Payments, Runs, SDK_VERSION, TEMPO_CHAIN_ID, TEMPO_TESTNET_CHAIN_ID, Wallet, ZeroApiError, ZeroAuthError, ZeroClient, ZeroConfigurationError, ZeroError, ZeroPaymentError, ZeroSessionCloseFailedError, ZeroTimeoutError, ZeroValidationError, ZeroWalletError, coerceTempoChainId, createManagedAccount, paymentHasAnchor, tempoChainLabelFromId };
-//# sourceMappingURL=chunk-SLXRHGE4.js.map
-//# sourceMappingURL=chunk-SLXRHGE4.js.map
+//# sourceMappingURL=chunk-FH6C6TXR.js.map
+//# sourceMappingURL=chunk-FH6C6TXR.js.map