@hunt-labs/bytekit-sdk 0.11.3 → 0.11.5

package/CHANGELOG.md

@@ -10,6 +10,23 @@ today, see [README.md](./README.md), which remains the authoritative usage guide
 
 ## [Unreleased]
 
+## [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
+
+- Regenerated `src/generated/api.d.ts` (#4732): the `422` responses of `GET /v1/fetch` and
+  `POST /v1/fetch` declare the optional `X-Fetch-ID` header, present when the failed request was
+  recorded and naming its row in Logs (`sc_<hex>` for the header's `ft_<hex>`). Doc comments
+  only; no SDK signature moves.
+
 ## [0.11.3] - 2026-09-21
 
 ### Changed

package/dist/generated/api.d.ts

@@ -720,7 +720,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 +1160,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 +2727,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;
         };
@@ -4129,6 +4154,12 @@ export interface operations {
              */
             422: {
                 headers: {
+                    /**
+                     * @description Optional; present only when the failed request was recorded. Names the failed
+                     *     row: it appears in Logs under the same hex, rendered `sc_<hex>` (`ft_` in this
+                     *     header, `sc_` in Logs).
+                     */
+                    "X-Fetch-ID": components["headers"]["XFetchID"];
                     [name: string]: unknown;
                 };
                 content: {
@@ -4273,6 +4304,12 @@ export interface operations {
              */
             422: {
                 headers: {
+                    /**
+                     * @description Optional; present only when the failed request was recorded. Names the failed
+                     *     row: it appears in Logs under the same hex, rendered `sc_<hex>` (`ft_` in this
+                     *     header, `sc_` in Logs).
+                     */
+                    "X-Fetch-ID": components["headers"]["XFetchID"];
                     [name: string]: unknown;
                 };
                 content: {
@@ -4462,7 +4499,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;
@@ -4535,11 +4572,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.
@@ -4553,7 +4591,7 @@ export interface operations {
                         /** @example bulk_01j9abc123 */
                         id: string;
                         /** @enum {string} */
-                        status: "processing" | "cancelled";
+                        status: "processing";
                         total: number;
                         completed: number;
                         failed: number;
@@ -6094,7 +6132,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. */
@@ -6120,13 +6158,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. */
@@ -6137,17 +6175,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;
@@ -6155,7 +6193,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;
@@ -7130,6 +7168,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.3";
+export declare const SDK_VERSION = "0.11.5";

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.3';
+export const SDK_VERSION = '0.11.5';

package/package.json

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