@deeprelay/sdk 0.4.3 → 0.4.4

package/README.md

@@ -1,4 +1,4 @@
-# @deeprelay/sdk@0.4.3
+# @deeprelay/sdk@0.4.4
 
 A TypeScript SDK client for the api.deeprelay.ai API.
 
@@ -194,7 +194,7 @@ and is automatically generated by the
 [OpenAPI Generator](https://openapi-generator.tech) project:
 
 - API version: `1.0.0`
-- Package version: `0.4.3`
+- Package version: `0.4.4`
 - Generator version: `7.24.0`
 - Build package: `org.openapitools.codegen.languages.TypeScriptFetchClientCodegen`
 

package/dist/apis/BillingApi.d.ts

@@ -64,12 +64,12 @@ export declare class BillingApi extends runtime.BaseAPI {
      */
     createSubscriptionCheckoutRequestOpts(requestParameters: CreateSubscriptionCheckoutRequest): Promise<runtime.RequestOpts>;
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckoutRaw(requestParameters: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SubscriptionCheckoutSession>>;
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckout(requestParameters?: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SubscriptionCheckoutSession>;

package/dist/apis/BillingApi.js

@@ -116,7 +116,7 @@ class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckoutRaw(requestParameters, initOverrides) {
@@ -127,7 +127,7 @@ class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckout() {

package/dist/esm/apis/BillingApi.d.ts

@@ -64,12 +64,12 @@ export declare class BillingApi extends runtime.BaseAPI {
      */
     createSubscriptionCheckoutRequestOpts(requestParameters: CreateSubscriptionCheckoutRequest): Promise<runtime.RequestOpts>;
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckoutRaw(requestParameters: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SubscriptionCheckoutSession>>;
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckout(requestParameters?: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SubscriptionCheckoutSession>;

package/dist/esm/apis/BillingApi.js

@@ -113,7 +113,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckoutRaw(requestParameters, initOverrides) {
@@ -124,7 +124,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused.
      * Start a subscription checkout session
      */
     createSubscriptionCheckout() {

package/dist/esm/models/Problem.d.ts

@@ -94,6 +94,7 @@ export declare const ProblemCodeEnum: {
     readonly ModelNotAllowedForKey: "model_not_allowed_for_key";
     readonly CreatorCheckUnavailable: "creator_check_unavailable";
     readonly SwitchRenewalUnpaid: "switch_renewal_unpaid";
+    readonly CheckoutPaused: "checkout_paused";
     readonly InternalError: "internal_error";
     readonly OperationFailed: "operation_failed";
 };

package/dist/esm/models/Problem.js

@@ -41,6 +41,7 @@ export const ProblemCodeEnum = {
     ModelNotAllowedForKey: 'model_not_allowed_for_key',
     CreatorCheckUnavailable: 'creator_check_unavailable',
     SwitchRenewalUnpaid: 'switch_renewal_unpaid',
+    CheckoutPaused: 'checkout_paused',
     InternalError: 'internal_error',
     OperationFailed: 'operation_failed'
 };

package/dist/esm/runtime.js

@@ -61,7 +61,7 @@ export class Configuration {
         return undefined;
     }
     get headers() {
-        return Object.assign({ 'User-Agent': 'deeprelay-sdk-ts/0.4.3' }, this.configuration.headers);
+        return Object.assign({ 'User-Agent': 'deeprelay-sdk-ts/0.4.4' }, this.configuration.headers);
     }
     get credentials() {
         return this.configuration.credentials;

package/dist/models/Problem.d.ts

@@ -94,6 +94,7 @@ export declare const ProblemCodeEnum: {
     readonly ModelNotAllowedForKey: "model_not_allowed_for_key";
     readonly CreatorCheckUnavailable: "creator_check_unavailable";
     readonly SwitchRenewalUnpaid: "switch_renewal_unpaid";
+    readonly CheckoutPaused: "checkout_paused";
     readonly InternalError: "internal_error";
     readonly OperationFailed: "operation_failed";
 };

package/dist/models/Problem.js

@@ -49,6 +49,7 @@ exports.ProblemCodeEnum = {
     ModelNotAllowedForKey: 'model_not_allowed_for_key',
     CreatorCheckUnavailable: 'creator_check_unavailable',
     SwitchRenewalUnpaid: 'switch_renewal_unpaid',
+    CheckoutPaused: 'checkout_paused',
     InternalError: 'internal_error',
     OperationFailed: 'operation_failed'
 };

package/dist/runtime.js

@@ -69,7 +69,7 @@ class Configuration {
         return undefined;
     }
     get headers() {
-        return Object.assign({ 'User-Agent': 'deeprelay-sdk-ts/0.4.3' }, this.configuration.headers);
+        return Object.assign({ 'User-Agent': 'deeprelay-sdk-ts/0.4.4' }, this.configuration.headers);
     }
     get credentials() {
         return this.configuration.credentials;

package/docs/BillingApi.md

@@ -102,7 +102,7 @@ example().catch(console.error);
 
 Start a subscription checkout session
 
-Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. 
+Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused. 
 
 ### Example
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@deeprelay/sdk",
-  "version": "0.4.3",
+  "version": "0.4.4",
   "description": "TypeScript SDK for the deeprelay Public Developer API",
   "author": "deeprelay Support <support@deeprelay.ai>",
   "repository": {

package/src/apis/BillingApi.ts

@@ -201,7 +201,7 @@ export class BillingApi extends runtime.BaseAPI {
     }
 
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. 
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused. 
      * Start a subscription checkout session
      */
     async createSubscriptionCheckoutRaw(requestParameters: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SubscriptionCheckoutSession>> {
@@ -212,7 +212,7 @@ export class BillingApi extends runtime.BaseAPI {
     }
 
     /**
-     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. 
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses. While new payments are paused on the organization after several declined cards, a new checkout (a switch included) is refused with 429 `checkout_paused` and a Retry-After; renewing a plan billed through the previous payment account is never refused. 
      * Start a subscription checkout session
      */
     async createSubscriptionCheckout(requestParameters: CreateSubscriptionCheckoutRequest = {}, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SubscriptionCheckoutSession> {

package/src/models/Problem.ts

@@ -100,6 +100,7 @@ export const ProblemCodeEnum = {
     ModelNotAllowedForKey: 'model_not_allowed_for_key',
     CreatorCheckUnavailable: 'creator_check_unavailable',
     SwitchRenewalUnpaid: 'switch_renewal_unpaid',
+    CheckoutPaused: 'checkout_paused',
     InternalError: 'internal_error',
     OperationFailed: 'operation_failed'
 } as const;

package/src/runtime.ts

@@ -75,7 +75,7 @@ export class Configuration {
     }
 
     get headers(): HTTPHeaders | undefined {
-        return { 'User-Agent': 'deeprelay-sdk-ts/0.4.3', ...this.configuration.headers };
+        return { 'User-Agent': 'deeprelay-sdk-ts/0.4.4', ...this.configuration.headers };
     }
 
     get credentials(): RequestCredentials | undefined {