@checkbox-site/node 0.2.5 → 0.2.6

package/dist/client.d.ts

@@ -45,7 +45,7 @@ export interface Checkbox extends ResourceInstances {
  */
 export declare class Checkbox implements RequestSender {
     #private;
-    static readonly VERSION = "0.2.5";
+    static readonly VERSION = "0.2.6";
     static readonly API_VERSION = "2026-10-30";
     static readonly errors: typeof errors;
     static readonly webhooks: Webhooks;

package/dist/generated/operations.d.ts

@@ -3323,7 +3323,7 @@ export declare class TestCredentialsResource extends Resource {
     /**
      * Store a billing test-mode key.
      *
-     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked "Let your agent store a Stripe test-mode key" on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
+     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked the box “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection) (checkbox id consent-stripe-test-key) on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/test_credentials (operation `createTestCredential`, scope `test_runs:write`)

package/dist/generated/operations.js

@@ -2895,7 +2895,7 @@ export class TestCredentialsResource extends Resource {
     /**
      * Store a billing test-mode key.
      *
-     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked "Let your agent store a Stripe test-mode key" on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
+     * Stores the site's Stripe TEST-mode restricted key (rk_test_…), after checking it with Stripe the way the dashboard's Connect Stripe does. An agent may call this itself once the owner approved the setup; every store is logged on the site's setup timeline and Billing connection line, and the human can revoke it in one click. Live keys are refused (test_key_not_test_mode: a human adds live keys in the dashboard); the owner must have ticked the box “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection) (checkbox id consent-stripe-test-key) on the approval page of the agent's sign-in or connection (else test_key_declined); a key whose Stripe account looks like another site's is refused with billing_account_mismatch (with confirm_account_mismatch: true the key is connected on hold until a person confirms the account in the dashboard; only a person can confirm it); secret keys (sk_test_…) are refused (test_key_not_restricted). On a test-mode site without a Stripe connection the key also becomes the site's Stripe connection: one key for checks, fixes (only after the human approves each) and test runs. The key's checklist: Customers: Write, Products: Read, Prices: Read, Coupons: Read, Subscriptions: Write, Test clocks: Write, Customer portal: Write, Checkout Sessions: Write, Payment Links: Write, Webhook Endpoints: Write. Replaces an existing key. Next: createTestRun.
      *
      * @param site Unique identifier of the site (site_…).
      * @see POST /v1/sites/{site}/test_credentials (operation `createTestCredential`, scope `test_runs:write`)

package/dist/generated/types.d.ts

@@ -410,7 +410,7 @@ export interface SetupSession {
     }>;
     /** Stripe test mode for lifecycle test runs. */
     stripe: {
-        /** Whether the human ticked “Let your agent store a Stripe test-mode key” on the approval page (device login or OAuth connection). False: the agent may not store one (createTestCredential answers test_key_declined); the human adds it in the dashboard. Sessions started with a key the human made in the dashboard: true. */
+        /** Whether the human ticked the box “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection) (checkbox id consent-stripe-test-key) on the approval page (device login or OAuth connection). False: the agent may not store one (createTestCredential answers test_key_declined); the human adds it in the dashboard. Sessions started with a key the human made in the dashboard: true. */
         test_key_consent: boolean;
         /** Hint of the restricted test key the CLI found (never the key). */
         test_key_hint: string | null;
@@ -478,8 +478,10 @@ export interface SetupSession {
     }>;
     /** Latest verdict of the test-mode site. */
     compliance: {
-        /** When it was evaluated. Unix timestamp in seconds. */
+        /** When it was evaluated (Unix seconds; a time, not a count). Unix timestamp in seconds. */
         evaluated: number;
+        /** The same time as evaluated, in ISO 8601. */
+        evaluated_at: string;
         /**
          * Deprecated: open failing findings (per check). Read `label` (counted in tasks) and `todo` instead.
          * @deprecated
@@ -603,8 +605,8 @@ export interface SetupSessionUpdate {
         /** Where the subscribe / pay buttons are rendered. */
         pay_buttons?: Array<SetupCodeRef>;
     };
-    /** File the snippet tag was added to. */
-    snippet_installed_in?: string;
+    /** File the snippet tag was added to, or a list of files (e.g. ["app/layout.tsx", "app/account/layout.tsx"]). */
+    snippet_installed_in?: string | Array<string>;
     /** File the API keys were written to (never committed). */
     env_written?: string;
     /** Live-mode site (site_…) you created with the live key, so the checklist tracks its domain verification. */
@@ -676,6 +678,8 @@ export interface SetupVerification {
         reason: string | null;
     } | null;
     next_action: SetupNextAction;
+    /** The same as setup_session.steps, at the top level: the setup checklist, in order. */
+    steps: Array<SetupStep>;
     setup_session: SetupSession;
 }
 /** Account default retention (sites without their own setting use it). */
@@ -1790,8 +1794,10 @@ export interface CompliancePlan {
     livemode: boolean;
     /** The site. */
     site: string;
-    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). */
+    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). The value "compliant" is kept so published SDKs keep working; prefer checks_status ("checks_pass") and show status_label to people: never tell anyone the site "is compliant". */
     status: "action_required" | "verifying" | "compliant" | "blocked";
+    /** The same as status, with "checks_pass" in place of the older value "compliant" (every required check passes or only waits for a live check: an automated assessment, not a legal determination). Read this one in new code. */
+    checks_status?: "action_required" | "verifying" | "checks_pass" | "blocked";
     /** The plan status in words to show a person, from the same counts as the summary ("1 fix needed · 2 to set up", "1 decision for you"; else action_required "Fixes needed", blocked "Your call"), "Checks still running (N)" while checks are still running (verifying), compliant "Checks pass"; while an agent works the site and everything left waits for a deploy or the owner (next_action done_for_now): "Waiting on deploy and you" or "Waiting on deploy". Show this, never the machine value (`compliant` is a status name, not a legal conclusion). */
     status_label?: string;
     /** The evaluation the plan was built from (null before the first check). */
@@ -1947,8 +1953,8 @@ export interface Verification {
     task: string | null;
     /** One task or the whole site. */
     scope: "task" | "site";
-    /** pending (waiting for the confirming scan / re-evaluation), passed (Checkbox observed the expected result: every check passes or does not apply), passed_with_gaps (nothing observed fails, but some checks could not be observed: observed missing_data — not verified), passed_with_notes (nothing observed fails and the task counts as passing, but a check is still needs_review on a part that is not yours to change, such as Stripe's own page layout: see checks), not_checked (a task whose checks could only not be observed yet: nothing to change in the code; next_action says what evidence to provide), pending_live_check (an email whose content passes but that Checkbox has not seen sent for a real event yet: nothing to change; it completes on the first real send or a proof run), failed (it did not: see diff), superseded (this verification did not pass, but newer evidence, such as a test run or a later evaluation, settled the task since: see superseded and follow next_action; nothing to change for it). */
-    status: "pending" | "passed" | "passed_with_gaps" | "passed_with_notes" | "not_checked" | "pending_live_check" | "failed" | "superseded";
+    /** pending (waiting for the confirming scan / re-evaluation), passed (Checkbox observed the expected result: every check passes or does not apply), passed_with_gaps (nothing observed fails, but some checks could not be observed: observed missing_data — not verified), passed_with_notes (nothing observed fails and the task counts as passing, but a check is still needs_review on a part that is not yours to change, such as Stripe's own page layout: see checks), not_checked (a task whose checks could only not be observed yet: nothing to change in the code; next_action says what evidence to provide), pending_live_check (an email whose content passes but that Checkbox has not seen sent for a real event yet: nothing to change; it completes on the first real send or a proof run), needs_review (nothing observed fails, but a check is still undecided, e.g. a cancellation not tried yet or a styling estimate: not done; next_action says what decides it), failed (a check was observed failing: see diff), superseded (this verification did not pass, but newer evidence, such as a test run or a later evaluation, settled the task since: see superseded and follow next_action; nothing to change for it). */
+    status: "pending" | "passed" | "passed_with_gaps" | "passed_with_notes" | "not_checked" | "pending_live_check" | "needs_review" | "failed" | "superseded";
     /** Set when newer evidence settled the task after this verification finished (status superseded). */
     superseded?: {
         /** The task's status in the current plan. */
@@ -4479,7 +4485,7 @@ export interface TestRun {
     type: "stripe" | "generic";
     /** Stripe runs: mirror (Checkbox mirrors your checkout into test mode and moves a test clock through trial and renewal) or real_checkout (the shopper buys through YOUR checkout on your test deployment, so your own webhook handlers and email code fire: the proof that your real system works). null for generic runs. */
     mode: "mirror" | "real_checkout" | null;
-    /** succeeded means the run finished every step and no step failed (steps may still have warnings to review); incomplete means no step failed, but a step could not finish what it set out to observe (for example the online cancellation could not be completed): not a pass; failed means it stopped early, or finished with a failed step (see failure and steps[].fix). */
+    /** succeeded means the run finished every step and no step failed (steps may still have warnings to review); incomplete means no step failed, but a step could not finish what it set out to observe (for example the online cancellation could not be completed, or a required email never arrived): not a pass; failed means it stopped early, or finished with a failed step (see failure and steps[].fix). */
     status: "queued" | "running" | "succeeded" | "incomplete" | "failed" | "canceled";
     /** The status in plain words, counting steps: "Finished with 6 warnings to review", "Finished with 1 failed step", "Finished: every observed step passed". succeeded with warnings is not a clean pass. */
     status_label: string;
@@ -4512,6 +4518,10 @@ export interface TestRun {
     started: number | null;
     /** When it finished. Unix timestamp in seconds. */
     finished: number | null;
+    /** The same as finished (the name verifications use): when the run finished; null while it runs. Unix timestamp in seconds. */
+    completed: number | null;
+    /** How long the run took, from started (or created) to finished, in seconds; null while it runs. */
+    duration_seconds: number | null;
     /** Lifecycle steps in order. */
     steps: Array<TestRunStep>;
     /** Why the run stopped (failed / canceled runs). */
@@ -4813,7 +4823,7 @@ export interface CompliancePlanSummary {
     livemode: boolean;
     /** The site. */
     site: string;
-    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). */
+    /** action_required (an agent can apply open tasks now), verifying (changes applied; waiting for confirming observations), compliant (every required check passes or only waits for a live check — an automated assessment, not a legal determination; see compliance.pending_live_checks and coverage), blocked (only human answers ("Your call") or declined critical tasks remain). The value "compliant" is kept so published SDKs keep working; prefer checks_status ("checks_pass") and show status_label to people: never tell anyone the site "is compliant". */
     status: "action_required" | "verifying" | "compliant" | "blocked";
     /** The plan status in words to show a person, from the same counts as the summary ("1 fix needed · 2 to set up", "1 decision for you"; else action_required "Fixes needed", blocked "Your call"), "Checks still running (N)" while checks are still running (verifying), compliant "Checks pass"; while an agent works the site and everything left waits for a deploy or the owner (next_action done_for_now): "Waiting on deploy and you" or "Waiting on deploy". Show this, never the machine value (`compliant` is a status name, not a legal conclusion). */
     status_label?: string;
@@ -5600,7 +5610,7 @@ export declare const ERROR_CODES: {
     readonly test_key_declined: {
         readonly status: 403;
         readonly type: "permission_error";
-        readonly description: "The owner did not tick “Let your agent store a Stripe test-mode key” on the approval page of this agent's sign-in (device login) or connection (OAuth). Nothing was stored. Ask them to allow it on the approval page (sign in again) or to add the key themselves in the dashboard.";
+        readonly description: "The owner did not tick “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in, device login) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection, OAuth) on the approval page (checkbox id consent-stripe-test-key). Nothing was stored. Ask them to allow it on the approval page (sign in again) or to add the key themselves in the dashboard.";
     };
     readonly test_key_rejected: {
         readonly status: 400;

package/dist/generated/types.js

@@ -21,7 +21,7 @@ export const ERROR_CODES = {
     test_key_missing: { status: 400, type: "invalid_request_error", description: "A Stripe test run needs a Stripe TEST-mode key stored for the site: the agent stores the restricted test key (rk_test_…) with createTestCredential, or a person adds it in the dashboard." },
     test_key_not_test_mode: { status: 400, type: "invalid_request_error", description: "The billing key is a live-mode (or malformed) key. Agents only store TEST-mode restricted keys (rk_test_…); a human adds live keys in the Checkbox dashboard." },
     test_key_not_restricted: { status: 400, type: "invalid_request_error", description: "The key is a full Stripe secret key (sk_test_… or sk_live_…), which is refused on every connect path (createTestCredential, connectBillingPlatform, the dashboard). Use a restricted key (rk_test_…) with the permissions on Checkbox's key checklist instead; `message` lists them." },
-    test_key_declined: { status: 403, type: "permission_error", description: "The owner did not tick “Let your agent store a Stripe test-mode key” on the approval page of this agent's sign-in (device login) or connection (OAuth). Nothing was stored. Ask them to allow it on the approval page (sign in again) or to add the key themselves in the dashboard." },
+    test_key_declined: { status: 403, type: "permission_error", description: "The owner did not tick “Let your agent store a Stripe test-mode restricted key for this project” (agent sign-in, device login) or “Let this app store a Stripe test-mode restricted key for your sites” (app connection, OAuth) on the approval page (checkbox id consent-stripe-test-key). Nothing was stored. Ask them to allow it on the approval page (sign in again) or to add the key themselves in the dashboard." },
     test_key_rejected: { status: 400, type: "invalid_request_error", description: "Stripe rejected the test-mode key or it lacks a permission test runs need; `message` names it." },
     authorization_pending: { status: 400, type: "invalid_request_error", description: "Device login: the human has not approved yet. Keep polling createDeviceToken every `interval` seconds." },
     slow_down: { status: 400, type: "rate_limit_error", description: "Device login: polling too fast. Add 5 seconds to the interval and keep polling." },

package/dist/version.d.ts

@@ -1,2 +1,2 @@
 /** Version of this SDK (kept equal to packages/sdk-node/package.json "version"; a test checks it). */
-export declare const SDK_VERSION = "0.2.5";
+export declare const SDK_VERSION = "0.2.6";

package/dist/version.js

@@ -1,2 +1,2 @@
 /** Version of this SDK (kept equal to packages/sdk-node/package.json "version"; a test checks it). */
-export const SDK_VERSION = '0.2.5';
+export const SDK_VERSION = '0.2.6';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkbox-site/node",
-  "version": "0.2.5",
+  "version": "0.2.6",
   "description": "Checkbox Node.js SDK: auto-renewal law and subscription compliance checks (FTC ROSCA, California ARL, New York and other state laws) for Stripe Checkout and other subscription checkouts. Zero dependencies. Published to npm as @checkbox-site/node.",
   "keywords": [
     "subscription",