@hunt-labs/bytekit-sdk 0.11.4 → 0.11.6

package/CHANGELOG.md

@@ -10,6 +10,23 @@ today, see [README.md](./README.md), which remains the authoritative usage guide
 
 ## [Unreleased]
 
+## [0.11.6] - 2026-09-24
+
+### Changed
+
+- Regenerated `src/generated/api.d.ts` (#4865): a documentation-wording correction to the
+  `POST /v1/schema` billing description, which now says the page bandwidth is billed at its
+  upstream wire bytes with no endpoint factor instead of "exactly like `/v1/scrape`". No
+  behavior change: doc comments only, no SDK signature moves.
+
+## [0.11.5] - 2026-09-22
+
+### Changed
+
+- **Internal `GET /v1/logs` types list schema rows (#2373).** Both `endpoint` enums add `schema`,
+  for `/v1/schema` structured-extraction requests, whose row ids carry the new `sch_` prefix.
+  No SDK method calls it.
+
 ## [0.11.4] - 2026-09-21
 
 ### Changed

package/README.md

@@ -358,7 +358,7 @@ try {
 
 Note that `details` is populated only from the API's canonical
 `{ error: { … } }` envelope. A few endpoints answer with a flat, vendor-masked
-body instead (`/v1/search` returns `502 {"error":"search_provider_error"}`);
+body instead (`/v1/search` returns `503 {"error":"search_provider_error"}`);
 those carry no structured detail, so `err.details` stays `undefined` there —
 `err.code` is still the machine-readable reason.
 

package/dist/client.d.ts

@@ -103,7 +103,7 @@ export declare class ByteKitError extends Error {
      * The envelope's `error.details`, when it carried one — `undefined` otherwise.
      *
      * Populated ONLY from the canonical `{ error: { … } }` envelope. A flat
-     * vendor-masked body (`/v1/search` 502 `{"error":"search_provider_error"}`)
+     * vendor-masked body (`/v1/search` 503 `{"error":"search_provider_error"}`)
      * has no envelope to read a detail from, so it never grows one (#2685 E3).
      *
      * A `details` that is not a JSON object — which the untyped spec field

package/dist/client.js

@@ -470,9 +470,9 @@ export class ByteKit {
                         }
                     }
                     else if (typeof json.error === 'string' && json.error.length > 0) {
-                        // Flat vendor-masked shape, e.g. /v1/search 502
+                        // Flat vendor-masked shape, e.g. /v1/search 503
                         // {"error":"search_provider_error"} (docs/api/openapi.yaml §/v1/search
-                        // 502). The string IS the error code. `message` falls back to it only
+                        // 503). The string IS the error code. `message` falls back to it only
                         // when the response carried no statusText, so the thrown error is
                         // never message-empty.
                         code = json.error;

package/dist/generated/api.d.ts

@@ -640,7 +640,8 @@ export interface paths {
          *     `wait_for_selector`) cause a `400 unsupported_option`.
          *
          *     Dual-axis billing: a fixed per-request credit charge **plus** the
-         *     underlying page's bandwidth, billed exactly like `/v1/scrape`. The
+         *     underlying page's bandwidth, billed at its upstream wire bytes with no
+         *     endpoint factor (a 100 KiB estimate is pre-charged, then reconciled). The
          *     bandwidth is still billed when the scrape succeeds but extraction later
          *     fails; both axes are refunded only when the scrape itself never runs.
          *
@@ -720,7 +721,7 @@ export interface paths {
         };
         /**
          * Get the unified request log feed
-         * @description Returns a unified, newest-first feed of the account's requests across scrape, fetch, screenshots, recordings and search, plus webhook delivery attempts, for the dashboard /logs screen. Monitor runs are listed as the scrape and screenshots rows they produce (`source: monitor`). Cursor-paginated; default range is the last 30 days, max 366 days.
+         * @description Returns a unified, newest-first feed of the account's requests across scrape, fetch, screenshots, recordings, search and schema, plus webhook delivery attempts, for the dashboard /logs screen. Monitor runs are listed as the scrape and screenshots rows they produce (`source: monitor`). Cursor-paginated; default range is the last 30 days, max 366 days.
          */
         get: operations["getLogs"];
         put?: never;
@@ -1160,6 +1161,29 @@ export interface paths {
         patch?: never;
         trace?: never;
     };
+    "/v1/account/complete-onboarding": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        get?: never;
+        put?: never;
+        /**
+         * Mark onboarding as finished
+         * @description Records that the account left the dashboard's onboarding flow through one
+         *     of its exits, so `onboarding_completed` on GET /v1/account reads true from
+         *     then on. Idempotent: a repeat call keeps the first timestamp and still
+         *     answers 200. Requires an active membership (admin or member).
+         */
+        post: operations["completeOnboarding"];
+        delete?: never;
+        options?: never;
+        head?: never;
+        patch?: never;
+        trace?: never;
+    };
     "/v1/me": {
         parameters: {
             query?: never;
@@ -2704,8 +2728,10 @@ export interface components {
             terms_version: string;
             /** Format: date-time */
             created_at: string;
-            /** @description True once the account has SUCCESSFULLY COMPLETED at least one billable request (a scrape/screenshot/fetch/… that settled and was charged credits), regardless of whether it was authenticated with a Clerk session or an API key. All-time — never windowed. A request that failed does not flip it, even when its bandwidth was billed: the monitor terminal-preflight-failure path records bytes without credits, and only the credited settlement counts here. Powers the dashboard onboarding gate — the app shows the guided onboarding flow until this is true, then the dashboard. Lags by up to one usage rollup: the completion service writes the row after the response is returned, so a just-completed first request may still read false for a moment. Treat that as "not visible yet", never as "this account has never made a request". */
+            /** @description True once the account has SUCCESSFULLY COMPLETED at least one billable request (a scrape/screenshot/fetch/… that settled and was charged credits), regardless of whether it was authenticated with a Clerk session or an API key. All-time — never windowed. A request that failed does not flip it, even when its bandwidth was billed: the monitor terminal-preflight-failure path records bytes without credits, and only the credited settlement counts here. Powers the dashboard onboarding gate — the app shows the guided onboarding flow until this or `onboarding_completed` is true, then the dashboard. Lags by up to one usage rollup: the completion service writes the row after the response is returned, so a just-completed first request may still read false for a moment. Treat that as "not visible yet", never as "this account has never made a request". */
             has_activity: boolean;
+            /** @description True once a member of the account left onboarding through one of its exits (POST /v1/account/complete-onboarding). Never reset. With `has_activity` it gates the dashboard: the app shows the guided onboarding flow until either one is true, so a user whose first request failed can still reach the dashboard. */
+            onboarding_completed: boolean;
             /** @description True when the account has a Stripe subscription, keyed on the same `stripe_subscription_id` column that GET /v1/billing/change-plan's `no_subscription` guard tests — so a client can use it to decide whether that endpoint will answer at all. Stays TRUE while a subscription is mid-cancellation (cancelled but running to the period end): the subscription still exists and a booked plan change is still revocable. It is a boolean, not the bearer path's `subscription` object: this response has no role-dependent fields, so a non-admin member receives it too, and plan pricing does not belong there. */
             has_subscription: boolean;
         };
@@ -4150,35 +4176,20 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /**
-             * @description Content transform failed, or a non-2xx upstream response relayed as the unified
-             *     Error envelope. On an upstream relay the HTTP status equals the upstream status
-             *     (code `upstream_error`), so any 4xx/5xx the target returns surfaces here as an
-             *     Error envelope rather than a raw body (#1462).
-             *
-             *     **One divergence.** An upstream `502` is relayed at HTTP `503`, not `502` — see
-             *     the `503` response below. A fetch service that cannot be reached also answers
-             *     `503`, not `502` (#3373); this status no longer covers that condition.
-             */
-            502: {
-                headers: {
-                    [name: string]: unknown;
-                };
-                content: {
-                    "application/json": components["schemas"]["Error"];
-                };
-            };
             /**
              * @description Two distinct conditions answer `503`, and they disagree about what the body's
              *     `error.http_status` reports. Read `error.code` to tell them apart.
              *
-             *     - **`upstream_error`** — the target returned HTTP `502`, relayed here as `503`.
-             *       Cloudflare fronts this API and replaces a clean origin 502 with its own generic
-             *       `text/plain` error page, discarding the envelope before it reaches you, while a
-             *       503 is passed through unchanged. The body's `error.http_status` still reports
-             *       the **true upstream status**, `502` — not `503` — and is the only surviving
-             *       record of what the target answered, so the body rather than the HTTP status is
-             *       authoritative here (#3355).
+             *     - **`upstream_error`** — the target returned HTTP `502` or `504`, relayed here as
+             *       `503`. Cloudflare fronts this API and replaces a clean origin 502 or 504 with its
+             *       own generic `text/plain` error page, discarding the envelope before it reaches
+             *       you, while a 503 is passed through unchanged. The body's `error.http_status`
+             *       still reports the **true upstream status**, `502` or `504` — not `503` — and is
+             *       the only surviving record of what the target answered, so the body rather than
+             *       the HTTP status is authoritative here (#3355, #4891). Every other non-2xx
+             *       upstream response is relayed at its own HTTP status with the same
+             *       `upstream_error` envelope, so any other 4xx/5xx the target returns surfaces as an
+             *       Error envelope rather than a raw body (#1462).
              *     - **`internal_error`** (message `Fetch service unavailable.`) — no fetch service
              *       endpoint could be resolved on this deployment, a fault of this API and not of the
              *       target. There is no upstream status to preserve: the `503` is this API's own
@@ -4300,35 +4311,20 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /**
-             * @description Content transform failed, or a non-2xx upstream response relayed as the unified
-             *     Error envelope. On an upstream relay the HTTP status equals the upstream status
-             *     (code `upstream_error`), so any 4xx/5xx the target returns surfaces here as an
-             *     Error envelope rather than a raw body (#1462).
-             *
-             *     **One divergence.** An upstream `502` is relayed at HTTP `503`, not `502` — see
-             *     the `503` response below. A fetch service that cannot be reached also answers
-             *     `503`, not `502` (#3373); this status no longer covers that condition.
-             */
-            502: {
-                headers: {
-                    [name: string]: unknown;
-                };
-                content: {
-                    "application/json": components["schemas"]["Error"];
-                };
-            };
             /**
              * @description Two distinct conditions answer `503`, and they disagree about what the body's
              *     `error.http_status` reports. Read `error.code` to tell them apart.
              *
-             *     - **`upstream_error`** — the target returned HTTP `502`, relayed here as `503`.
-             *       Cloudflare fronts this API and replaces a clean origin 502 with its own generic
-             *       `text/plain` error page, discarding the envelope before it reaches you, while a
-             *       503 is passed through unchanged. The body's `error.http_status` still reports
-             *       the **true upstream status**, `502` — not `503` — and is the only surviving
-             *       record of what the target answered, so the body rather than the HTTP status is
-             *       authoritative here (#3355).
+             *     - **`upstream_error`** — the target returned HTTP `502` or `504`, relayed here as
+             *       `503`. Cloudflare fronts this API and replaces a clean origin 502 or 504 with its
+             *       own generic `text/plain` error page, discarding the envelope before it reaches
+             *       you, while a 503 is passed through unchanged. The body's `error.http_status`
+             *       still reports the **true upstream status**, `502` or `504` — not `503` — and is
+             *       the only surviving record of what the target answered, so the body rather than
+             *       the HTTP status is authoritative here (#3355, #4891). Every other non-2xx
+             *       upstream response is relayed at its own HTTP status with the same
+             *       `upstream_error` envelope, so any other 4xx/5xx the target returns surfaces as an
+             *       Error envelope rather than a raw body (#1462).
              *     - **`internal_error`** (message `Fetch service unavailable.`) — no fetch service
              *       endpoint could be resolved on this deployment, a fault of this API and not of the
              *       target. There is no upstream status to preserve: the `503` is this API's own
@@ -4474,7 +4470,7 @@ export interface operations {
                         /** @example bulk_01j9abc123 */
                         id: string;
                         /** @enum {string} */
-                        status: "processing" | "completed" | "failed";
+                        status: "processing" | "completed" | "failed" | "cancelled";
                         total: number;
                         completed: number;
                         failed: number;
@@ -4547,11 +4543,12 @@ export interface operations {
                 };
             };
             /**
-             * @description Bulk job still processing. `routes/fetch-bulk.ts` ends the poll handler
-             *     with `status: isTerminal ? 200 : 202` over an identical body, so this is
-             *     the SAME envelope the 200 documents — only the status code and the
-             *     reachable `status` values differ. Keep polling until you get a 200; a
-             *     **cancelled** job stays on this branch forever (issue #3533).
+             * @description Bulk job still processing. The poll answers 200 for a job in
+             *     `BULK_TERMINAL_STATUSES` (`completed`, `failed`, `cancelled`) and 202
+             *     otherwise, over an identical body, so this is the SAME envelope the 200
+             *     documents — only the status code and the reachable `status` values
+             *     differ. Keep polling until you get a 200; a **cancelled** job is served
+             *     200, not 202 (issues #3533, #4754).
              *
              *     Item `content_url` values are pre-signed exactly as on the 200 — a fresh
              *     600-second signature on every poll.
@@ -4565,7 +4562,7 @@ export interface operations {
                         /** @example bulk_01j9abc123 */
                         id: string;
                         /** @enum {string} */
-                        status: "processing" | "cancelled";
+                        status: "processing";
                         total: number;
                         completed: number;
                         failed: number;
@@ -5711,13 +5708,14 @@ export interface operations {
                 };
             };
             /**
-             * @description Upstream search provider error. The body is a fixed,
+             * @description Upstream search provider error, answered at `503` rather than `502` because
+             *     Cloudflare replaces an origin 502 body with its own page (#4891). The body is a fixed,
              *     vendor-masked shape — deliberately NOT the unified `Error`
              *     envelope. The upstream provider's identity and message are
              *     never surfaced, so the response carries only the constant
              *     `error` code `search_provider_error`.
              */
-            502: {
+            503: {
                 headers: {
                     [name: string]: unknown;
                 };
@@ -5877,16 +5875,15 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /** @description Underlying scrape failed (`scrape_failed`) or upstream provider error (`provider_error`). */
-            502: {
-                headers: {
-                    [name: string]: unknown;
-                };
-                content: {
-                    "application/json": components["schemas"]["Error"];
-                };
-            };
-            /** @description Extraction provider unconfigured (`provider_unavailable`). */
+            /**
+             * @description Read `error.code` to tell the conditions apart: underlying scrape failed or the
+             *     extraction service was unreachable (`scrape_failed`), upstream provider error
+             *     (`provider_error`), extraction provider unconfigured (`provider_unavailable`), or
+             *     upstream provider timed out (`provider_timeout`). None of these answers `502` or
+             *     `504`: Cloudflare fronts this API and replaces an origin 502 or 504 with its own
+             *     `text/plain` page, discarding the error envelope, while a 503 passes through
+             *     unchanged (#4891).
+             */
             503: {
                 headers: {
                     [name: string]: unknown;
@@ -5895,15 +5892,6 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /** @description Upstream provider timed out (`provider_timeout`). */
-            504: {
-                headers: {
-                    [name: string]: unknown;
-                };
-                content: {
-                    "application/json": components["schemas"]["Error"];
-                };
-            };
         };
     };
     getUsage: {
@@ -6106,7 +6094,7 @@ export interface operations {
                 /** @description End date (YYYY-MM-DD), inclusive. Default today. */
                 to?: string;
                 /** @description Filter to a single endpoint kind. */
-                endpoint?: "scrape" | "fetch" | "screenshots" | "recordings" | "search" | "webhook";
+                endpoint?: "scrape" | "fetch" | "screenshots" | "recordings" | "search" | "webhook" | "schema";
                 /** @description Filter by job outcome. */
                 status?: "pending" | "processing" | "completed" | "failed";
                 /** @description Case-insensitive substring match on the request URL — the search query on search rows and the target URL on webhook rows. */
@@ -6132,13 +6120,13 @@ export interface operations {
                 content: {
                     "application/json": {
                         data: {
-                            /** @description Prefixed request id (sc_/ss_/rec_/sr_/wh_). */
+                            /** @description Prefixed request id (sc_/ss_/rec_/sr_/wh_/sch_). */
                             id: string;
                             /**
-                             * @description The request kind. `webhook` rows are webhook delivery attempts ByteKit sent to your endpoint, not requests you made.
+                             * @description The request kind. `webhook` rows are webhook delivery attempts ByteKit sent to your endpoint, not requests you made. `schema` rows are /v1/schema structured-extraction requests.
                              * @enum {string}
                              */
-                            endpoint: "scrape" | "fetch" | "screenshots" | "recordings" | "search" | "webhook";
+                            endpoint: "scrape" | "fetch" | "screenshots" | "recordings" | "search" | "webhook" | "schema";
                             /** @description HTTP method. Not persisted; capture and search endpoints are POST, and webhook deliveries are sent as POST (so this is always "POST"). /v1/fetch also accepts GET, but the stored row cannot distinguish it. */
                             method: string;
                             /** @description The request URL. On a search row this is the search query (empty once the retention window has redacted it); on a webhook row it is the delivery target URL. */
@@ -6149,17 +6137,17 @@ export interface operations {
                              * @enum {string}
                              */
                             status: "pending" | "processing" | "completed" | "failed";
-                            /** @description Upstream target HTTP status on scrape/fetch rows; the HTTP status your endpoint answered on webhook rows. null on every other row. */
+                            /** @description Upstream target HTTP status on scrape/fetch rows, and the target site's HTTP status on completed schema and screenshot rows (null when none was recorded); the HTTP status your endpoint answered on webhook rows. null on every other row. */
                             status_code?: number | null;
-                            /** @description Raw upstream bytes the request carried (the billing base before the multiplier). null while pending/failed. */
+                            /** @description Raw upstream bytes the request carried (the billing base before the multiplier). null while pending/failed, and always null on search, webhook and schema rows. */
                             raw_bytes?: number | null;
-                            /** @description The bytes this request was BILLED — the same amount its own response reported in `X-Billable-Bytes`. For a scrape or fetch request this is the settled decomposition replayed as it was recorded at completion, so it already carries every factor that applied: the endpoint factor (`scrape` 1.0, `scrape_md` 1.5, `fetch` 1.0, `fetch_md` 1.5, a monitor run 1.0), the cache-hit ×0.5, and the clean-markdown ×3. Screenshots and recordings are `raw_bytes` × the fixed 1.5 Phase-1 render factor whatever capture options they carried — capture billing composes no discount factor, so that product is exact. This is the settled amount itself, never a product reconstructed from another field: `billing_multiplier` below is DERIVED from it (that field is this value over `raw_bytes`), so the dependency runs this way and not the other. One residual: a scrape or fetch row completed before the decomposition was recorded is reconstructed from its endpoint and cache-hit factors, which leaves a markdown `/v1/fetch` request of that vintage reported at 1.0 rather than 1.5 — nothing on such a row distinguishes it. That population ages out of this feed's retention window and is not backfilled. null while pending/failed (the row has no byte basis yet). */
+                            /** @description The bytes this request was BILLED — the same amount its own response reported in `X-Billable-Bytes`. For a scrape or fetch request this is the settled decomposition replayed as it was recorded at completion, so it already carries every factor that applied: the endpoint factor (`scrape` 1.0, `scrape_md` 1.5, `fetch` 1.0, `fetch_md` 1.5, a monitor run 1.0), the cache-hit ×0.5, and the clean-markdown ×3. Screenshots and recordings are `raw_bytes` × the fixed 1.5 Phase-1 render factor whatever capture options they carried — capture billing composes no discount factor, so that product is exact. This is the settled amount itself, never a product reconstructed from another field: `billing_multiplier` below is DERIVED from it (that field is this value over `raw_bytes`), so the dependency runs this way and not the other. One residual: a scrape or fetch row completed before the decomposition was recorded is reconstructed from its endpoint and cache-hit factors, which leaves a markdown `/v1/fetch` request of that vintage reported at 1.0 rather than 1.5 — nothing on such a row distinguishes it. That population ages out of this feed's retention window and is not backfilled. null while pending/failed (the row has no byte basis yet). On a schema row this is the byte amount the request settled at, recorded when it ended: 0 where the charge was refunded, null where it is unknown. */
                             billable_bytes?: number | null;
-                            /** @description The bandwidth factor this request settled at, DERIVED from the two fields above as `billable_bytes` / `raw_bytes`, ROUNDED TO 2 DECIMAL PLACES. It carries every factor that applied to the settled amount, composed: the endpoint factor, the cache-hit ×0.5 and the clean-markdown ×3 on a scrape or fetch row, and the flat 1.5 Phase-1 render factor on every screenshot and recording row whatever capture options it carried. Every factor reachable that way is a multiple of 0.25 (0.5, 0.75, 1, 1.5, 2.25, 3, 4.5), so 2 places reports each of them exactly on any basis of 100 bytes or more. The rounding is there because `billable_bytes` is itself rounded, which on an odd basis would otherwise surface here as 1.500001943158721 rather than 1.5. `raw_bytes` × `billing_multiplier`, rounded to the nearest byte, reproduces `billable_bytes` at every basis. CHANGED: this field used to report the row's persisted `credits_charged` — an account CREDIT count on a per-endpoint scale, not a bandwidth factor. On a screenshot that count is charged per capture option (`full_page`, `mobile`), so two captures billed at the same 1.5 factor reported different multipliers. See https://bytekit.com/docs/billing/credits for the credit counts each endpoint charges, which this field no longer reports. This is a LOGS ROW field and is NOT the scrape response envelope field — the envelope carries no flat `billing_multiplier` at all; its billing surface is the `billing` node (see BillingNode). It reports the same composed value as `billing.multiplier` and the X-Billing-Multiplier response header wherever `billable_bytes` is exact, which is every row but one: the residual described above for `billable_bytes`, a markdown `/v1/fetch` request completed before the decomposition was recorded, is reconstructed at 1.0 where settlement charged 1.5, and this field reports that same 1.0. null where the row has no factor to report: while pending/failed; on a search or webhook row (neither has a byte basis); where the basis is zero because Phase 1 was skipped or failed and the request billed nothing; and on a completed screenshot or recording old enough that no Phase-1 basis was ever recorded for it, which reports null rather than claiming a real past charge was nothing. */
+                            /** @description The bandwidth factor this request settled at, DERIVED from the two fields above as `billable_bytes` / `raw_bytes`, ROUNDED TO 2 DECIMAL PLACES. It carries every factor that applied to the settled amount, composed: the endpoint factor, the cache-hit ×0.5 and the clean-markdown ×3 on a scrape or fetch row, and the flat 1.5 Phase-1 render factor on every screenshot and recording row whatever capture options it carried. Every factor reachable that way is a multiple of 0.25 (0.5, 0.75, 1, 1.5, 2.25, 3, 4.5), so 2 places reports each of them exactly on any basis of 100 bytes or more. The rounding is there because `billable_bytes` is itself rounded, which on an odd basis would otherwise surface here as 1.500001943158721 rather than 1.5. `raw_bytes` × `billing_multiplier`, rounded to the nearest byte, reproduces `billable_bytes` at every basis. CHANGED: this field used to report the row's persisted `credits_charged` — an account CREDIT count on a per-endpoint scale, not a bandwidth factor. On a screenshot that count is charged per capture option (`full_page`, `mobile`), so two captures billed at the same 1.5 factor reported different multipliers. See https://bytekit.com/docs/billing/credits for the credit counts each endpoint charges, which this field no longer reports. This is a LOGS ROW field and is NOT the scrape response envelope field — the envelope carries no flat `billing_multiplier` at all; its billing surface is the `billing` node (see BillingNode). It reports the same composed value as `billing.multiplier` and the X-Billing-Multiplier response header wherever `billable_bytes` is exact, which is every row but one: the residual described above for `billable_bytes`, a markdown `/v1/fetch` request completed before the decomposition was recorded, is reconstructed at 1.0 where settlement charged 1.5, and this field reports that same 1.0. null where the row has no factor to report: while pending/failed; on a search, webhook or schema row (none has a raw byte basis); where the basis is zero because Phase 1 was skipped or failed and the request billed nothing; and on a completed screenshot or recording old enough that no Phase-1 basis was ever recorded for it, which reports null rather than claiming a real past charge was nothing. */
                             billing_multiplier?: number | null;
                             /** @description Request duration in milliseconds; on a webhook row, how long your endpoint took to answer the latest attempt. */
                             duration_ms?: number | null;
-                            /** @description How the request originated (single/bulk/monitor). null on search and webhook rows. */
+                            /** @description How the request originated (single/bulk/monitor). null on search, webhook and schema rows. */
                             source?: string | null;
                             error_code?: string | null;
                             error_message?: string | null;
@@ -6167,7 +6155,7 @@ export interface operations {
                             api_key_id?: string | null;
                             /** @description Stored content, image or video URL. For a `completed` row with a non-empty storage key this is a **pre-signed** download URL, minted fresh on every read of this endpoint and valid for **600 seconds (10 minutes)** — the same signing lifetime as `content_url` on `GET /v1/fetch/bulk/{id}` and `image_url` on `GET /v1/bulk/{id}/screenshots`. Download inside that window, or re-poll this endpoint for a fresh signature. For every other row the stored value is returned unchanged — `null` while no object has been stored, and otherwise a private, unsigned storage URL that returns 401 on download. That covers rows that are not `completed`, completed rows with no storage key, and completed rows whose object could not be signed; this endpoint raises no `artifact_unavailable` signal for any of them. */
                             artifact_url?: string | null;
-                            /** @description The original request options. */
+                            /** @description The original request options. Empty on schema rows: the schema, prompt and extraction result are not stored. */
                             options?: {
                                 [key: string]: unknown;
                             } | null;
@@ -6375,8 +6363,8 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /** @description Stripe error creating the Checkout session. */
-            502: {
+            /** @description Stripe error creating the Checkout session (`stripe_error`). Answered at `503`, not `502`, because Cloudflare replaces an origin 502 body with its own page (#4891). */
+            503: {
                 headers: {
                     [name: string]: unknown;
                 };
@@ -6447,8 +6435,8 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /** @description The Stripe subscription schedule could not be read. */
-            502: {
+            /** @description The Stripe subscription schedule could not be read (`stripe_error`). Answered at `503`, not `502`, because Cloudflare replaces an origin 502 body with its own page (#4891). */
+            503: {
                 headers: {
                     [name: string]: unknown;
                 };
@@ -6845,8 +6833,8 @@ export interface operations {
                     "application/json": components["schemas"]["Error"];
                 };
             };
-            /** @description Stripe API error. */
-            502: {
+            /** @description Stripe API error (`stripe_error`). Answered at `503`, not `502`, because Cloudflare replaces an origin 502 body with its own page (#4891). */
+            503: {
                 headers: {
                     [name: string]: unknown;
                 };
@@ -7142,6 +7130,47 @@ export interface operations {
             };
         };
     };
+    completeOnboarding: {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        requestBody?: never;
+        responses: {
+            /** @description Onboarding marked as finished. */
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        /** @enum {boolean} */
+                        onboarding_completed: true;
+                    };
+                };
+            };
+            /** @description Missing or invalid Clerk JWT. */
+            401: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": components["schemas"]["Error"];
+                };
+            };
+            /** @description Session has no active account membership. */
+            403: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": components["schemas"]["Error"];
+                };
+            };
+        };
+    };
     getMe: {
         parameters: {
             query?: never;

package/dist/version.d.ts

@@ -5,4 +5,4 @@
  * outbound request carries — see the emit site in `client.ts`. The header name is spelled
  * only there, so issue #2905's pre-merge gate 1 counts exactly one occurrence in `src/`.
  */
-export declare const SDK_VERSION = "0.11.4";
+export declare const SDK_VERSION = "0.11.6";

package/dist/version.js

@@ -9,4 +9,4 @@
  * outbound request carries — see the emit site in `client.ts`. The header name is spelled
  * only there, so issue #2905's pre-merge gate 1 counts exactly one occurrence in `src/`.
  */
-export const SDK_VERSION = '0.11.4';
+export const SDK_VERSION = '0.11.6';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hunt-labs/bytekit-sdk",
-  "version": "0.11.4",
+  "version": "0.11.6",
   "description": "Official TypeScript SDK for the ByteKit API",
   "license": "MIT",
   "type": "module",