@checkbox-site/node 0.2.6 → 0.2.7

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.6";
+    static readonly VERSION = "0.2.7";
     static readonly API_VERSION = "2026-10-30";
     static readonly errors: typeof errors;
     static readonly webhooks: Webhooks;

package/dist/generated/operations.d.ts

@@ -3098,7 +3098,7 @@ export declare class ChecksResource extends Resource {
     /**
      * Check a subscription lifecycle email.
      *
-     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the result is at most needs_review and Next is update_setup (update the site's plans first). Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
+     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the verdict is still judged with the terms you sent and a `site_plans_differ` warning says to update the site's plans (update_setup) once the change is deployed. Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
      *
      * @see POST /v1/checks/email (operation `checkEmail`, scope `checks:read`)
      */

package/dist/generated/operations.js

@@ -2622,7 +2622,7 @@ export class ChecksResource extends Resource {
     /**
      * Check a subscription lifecycle email.
      *
-     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the result is at most needs_review and Next is update_setup (update the site's plans first). Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
+     * Checks the content of an acknowledgment (welcome) email, trial-ending reminder, renewal reminder, price-change notice, yearly terms reminder or cancellation confirmation against the requirements for that notice (renewal terms, amount, frequency, how to cancel, trial cancellation). The email is modelled as sent on time, so the verdict is about content; get send dates from checkNoticeSchedule. Prices are judged against what Stripe charges: with `site` (or, without it and without a price in terms, the account's one site with Stripe connected) the plan fields come from the site's plans and the email is matched to the plan it names ("Annual") first; a price that contradicts it fails, and `warnings` say which site and plan were used. Without `site`, a price you send in terms is judged as sent; when it differs from every plan of that site, the verdict is still judged with the terms you sent and a `site_plans_differ` warning says to update the site's plans (update_setup) once the change is deployed. Returns `required_by` (requirements that make the email mandatory for this plan) and a `template` that passes the checks, with {{merge_tags}}, verified by the engine. Stateless and deterministic: nothing is stored, the same input on the same as_of date gives the same verdicts. Every verdict comes from the Checkbox rules engine over the legal catalog (federal ROSCA / EFTA plus the state automatic-renewal laws); the response carries rules_version, catalog_version and a disclaimer (not legal advice). Read `verdict`, then `next_action`: it tells you exactly what to change and to call the check again until verdict is pass.
      *
      * @see POST /v1/checks/email (operation `checkEmail`, scope `checks:read`)
      */

package/dist/generated/types.d.ts

@@ -266,7 +266,7 @@ export type GoLive = {
     /** The steps, in order. */
     steps: Array<{
         /** Stable step key. */
-        key: "verify_domain" | "stripe_terms_url" | "live_stripe_key" | "live_checkout" | "promote_site";
+        key: "verify_domain" | "stripe_terms_url" | "live_stripe_key" | "live_portal_cancel" | "live_checkout" | "deactivate_old_live_link" | "promote_site";
         /** Who takes the step: person (only the owner can: DNS, the Stripe Dashboard, live keys) or agent (a code change). */
         who: "person" | "agent";
         /** The step in plain words. */
@@ -680,6 +680,56 @@ export interface SetupVerification {
     next_action: SetupNextAction;
     /** The same as setup_session.steps, at the top level: the setup checklist, in order. */
     steps: Array<SetupStep>;
+    /** The same as setup_session.compliance, at the top level: the site's status label and to-do list after this re-check (null before the first evaluation). */
+    compliance: {
+        /** 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
+         */
+        failing: number;
+        /**
+         * Deprecated: open needs-review findings (per check). Read `label` (counted in tasks) and `todo` instead.
+         * @deprecated
+         */
+        needs_review: number;
+        /** The site roll-up label, the same everywhere (dashboard, plan, emails): "2 fixes needed · 1 your call", "Checks pass · 2 live checks pending". */
+        label: string | null;
+        /** The site roll-up status: needs_fix, your_call, incomplete, compliant or not_checked. */
+        status: string | null;
+        /**
+         * Deprecated: open findings (evidence). The to-do list is `todo` (the compliance plan's ordered open tasks).
+         * @deprecated
+         */
+        top_findings: Array<{
+            /** Unique identifier of the finding (fnd_…). */
+            id: string;
+            /** Check id. */
+            check_id: string;
+            /** fail or needs_review. */
+            status: string;
+            /** critical, high, medium or low. */
+            severity: string;
+            /** What is wrong. */
+            title: string;
+        }>;
+        /** The to-do list: the compliance plan's ordered open required tasks (same titles, order and counts as the dashboard, MCP get_site_status and the summary email). */
+        todo?: Array<{
+            /** Plan task id (task_…); its findings are the evidence. */
+            task: string;
+            /** Task key. */
+            key: string;
+            /** Task title, the same as in the plan. */
+            title: string;
+            /** The status the site roll-up counts the task under. */
+            status: "needs_fix" | "not_set_up" | "your_call" | "not_checked";
+            /** Needs a fix, Not set up yet, Your call or Not checked yet. */
+            label: string;
+        }>;
+    } | null;
     setup_session: SetupSession;
 }
 /** Account default retention (sites without their own setting use it). */
@@ -1200,8 +1250,8 @@ export interface SiteTestAccount {
     login_url: string;
     /** Test account email. */
     email: string;
-    /** Test account password (write-only; encrypted at rest). */
-    password: string;
+    /** Test account password (write-only; encrypted at rest). Leave it out for an email-only login (no password field); the stored password is kept when one was saved before. */
+    password?: string;
     /** Custom login steps. */
     login_steps?: Array<ScanStep>;
     /** Optional page on your site that RE-ACTIVATES the test subscription (a test-only route). The cancellation test really cancels the test account; the scanner opens this page after logging in, before cancelling, so every scan starts subscribed. Without it, a scan after a completed cancellation reports "not observed: the test account has no active subscription" (needs review). (Replaces reset_url, now a deprecated alias.) */
@@ -2854,13 +2904,13 @@ export interface DisclosureCheckParams {
     trial_days?: number;
     /** Intro / first-period price in major units ("$34.50 for your first box, then $69 every 2 weeks"). Or give `intro_amount` in minor units. */
     intro_price?: number | string;
-    /** Intro / first-period price in minor units. */
+    /** Intro / first-period price in minor units (999 = $9.99), like `amount`. Units never mix: price / intro_price are major units, amount / intro_amount / intro_amount_off are minor units; with `price` in major units, a value under 100 that reads like major units is refused with both ways to send it. */
     intro_amount?: number;
     /** How many billing periods the intro price lasts (default 1). */
     intro_periods?: number;
     /** Intro discount as a percentage off the recurring price (a Stripe coupon's percent_off: 20 for "20% off your first month"). Lasts `intro_periods` billing periods. Give one of intro_price / intro_amount, intro_percent_off or intro_amount_off. */
     intro_percent_off?: number;
-    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off). Lasts `intro_periods` billing periods. */
+    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off), like `amount`, even when the price is sent as `price` in major units. Lasts `intro_periods` billing periods. */
     intro_amount_off?: number;
     /** https URL where subscribers cancel online (used in generated text; a {{cancel_url}} placeholder otherwise). */
     cancel_url?: string;
@@ -2900,6 +2950,8 @@ export interface DisclosureCheckParams {
         /** The form cannot be submitted without ticking it (default true). */
         required?: boolean;
     };
+    /** Where the shopper pays: own_page (a form on this page), stripe_checkout or payment_link (a Stripe-hosted page that collects consent, so no checkbox is needed next to this text; consent is then left to that page and checked with checkStripeCheckoutSession / checkStripePaymentLink). With site, the site's checkout type is used when absent (declared, or Stripe Checkout when the site has a registered Stripe Checkout config). */
+    checkout_type?: "own_page" | "stripe_checkout" | "payment_link";
     /** Evaluate the law as of this date (YYYY-MM-DD, default today). */
     as_of?: string;
     /** Round 23: a site of yours (site_…): the disclosure is judged against the plan it states among the site's plans (the connected Stripe Prices win over plans typed in setup), with the site's merchant name, cancellation URL and jurisdictions, as verifyTask judges it. Plan fields you send are replaced by the plan's. "none" judges only what you send. */
@@ -3013,13 +3065,13 @@ export interface CheckPlanTerms {
     trial_days?: number;
     /** Intro / first-period price in major units ("$34.50 for your first box, then $69 every 2 weeks"). Or give `intro_amount` in minor units. */
     intro_price?: number | string;
-    /** Intro / first-period price in minor units. */
+    /** Intro / first-period price in minor units (999 = $9.99), like `amount`. Units never mix: price / intro_price are major units, amount / intro_amount / intro_amount_off are minor units; with `price` in major units, a value under 100 that reads like major units is refused with both ways to send it. */
     intro_amount?: number;
     /** How many billing periods the intro price lasts (default 1). */
     intro_periods?: number;
     /** Intro discount as a percentage off the recurring price (a Stripe coupon's percent_off: 20 for "20% off your first month"). Lasts `intro_periods` billing periods. Give one of intro_price / intro_amount, intro_percent_off or intro_amount_off. */
     intro_percent_off?: number;
-    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off). Lasts `intro_periods` billing periods. */
+    /** Intro discount as an amount off in minor units (a Stripe coupon's amount_off: 200 for $2.00 off), like `amount`, even when the price is sent as `price` in major units. Lasts `intro_periods` billing periods. */
     intro_amount_off?: number;
     /** https URL where subscribers cancel online (used in generated text; a {{cancel_url}} placeholder otherwise). */
     cancel_url?: string;
@@ -5610,7 +5662,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 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 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. next_action.url is a one-click allow page for this agent or app (dashboard /allow-stripe-test-key, signed in, no new sign-in); or the human adds 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 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_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. next_action.url is a one-click allow page for this agent or app (dashboard /allow-stripe-test-key, signed in, no new sign-in); or the human adds 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.6";
+export declare const SDK_VERSION = "0.2.7";

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkbox-site/node",
-  "version": "0.2.6",
+  "version": "0.2.7",
   "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",