@widgetic/api-sdk 1.0.31 → 1.0.33

package/dist/esm/apis/AdminApi.js

@@ -21,58 +21,13 @@ var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, ge
     });
 };
 import * as runtime from '../runtime.js';
-import { AdjustPartnerCredits200ResponseFromJSON, AdjustPartnerCreditsRequestToJSON, AdjustUserCredits200ResponseFromJSON, AdjustUserCreditsRequestToJSON, AdminHealthStatusFromJSON, CleanupOrphanedInvitations200ResponseFromJSON, CleanupOrphanedInvitationsRequestToJSON, CreatePartnerRequestToJSON, PartnerActivationFromJSON, PartnerBillingProfileSavedFromJSON, PartnerBillingProfileViewFromJSON, PartnerBillingReportFromJSON, PartnerDetailsFromJSON, PartnerEditorSessionSettingsFromJSON, PartnerListFromJSON, PartnerUpdateResultFromJSON, PartnerWithWarningsFromJSON, RecordPartnerInvoicePaymentRequestToJSON, RecordedPartnerPaymentFromJSON, RefundPartnerCreditsRequestToJSON, UpdatePartnerBillingProfileRequestToJSON, UpdatePartnerEditorSessionSettingsRequestToJSON, UpdatePartnerRequestToJSON, UpdatePartnerStatusRequestToJSON, } from '../models/index.js';
+import { AdjustUserCredits200ResponseFromJSON, AdjustUserCreditsRequestToJSON, AdminHealthStatusFromJSON, CleanupOrphanedInvitations200ResponseFromJSON, CleanupOrphanedInvitationsRequestToJSON, CreatePartnerRequestToJSON, PartnerActivationFromJSON, PartnerBillingProfileSavedFromJSON, PartnerBillingProfileViewFromJSON, PartnerBillingReportFromJSON, PartnerDetailsFromJSON, PartnerEditorSessionSettingsFromJSON, PartnerInvoiceScheduleFromJSON, PartnerListFromJSON, PartnerUpdateResultFromJSON, PartnerWithWarningsFromJSON, RecordPartnerInvoicePaymentRequestToJSON, RecordedPartnerPaymentFromJSON, UpdatePartnerBillingProfileRequestToJSON, UpdatePartnerEditorSessionSettingsRequestToJSON, UpdatePartnerRequestToJSON, UpdatePartnerStatusRequestToJSON, } from '../models/index.js';
 /**
  *
  */
 export class AdminApi extends runtime.BaseAPI {
     /**
-     * Admin only. A positive `amount` adds credits to the partner wallet; a negative `amount` removes them (the wallet must hold them). An `amount` of 0, or one that is not a finite number, is refused with 400. **One top-up may not exceed $100,000** (`BILLING_CONFIG.PARTNER_WALLET`), which is 1,000,000 credits at the list price of $0.10 per credit. A larger amount is refused with 400 and nothing is credited. The same ceiling applies to `POST /admin/billing/refund` and to the `creditBalance` field of `PUT /admin/partners/{partnerId}`. Removing credits is not limited by it. The `Idempotency-Key` header is required and names the adjustment: a retry with the same key replays the first result (`replayed: true`) instead of moving the balance twice, and a request without one is refused with 400. This moves a PARTNER\'s wallet. A user\'s balance is moved by `POST /admin/billing/credits/adjust`.
-     * Add credits to, or remove credits from, a partner\'s wallet
-     */
-    adjustPartnerCreditsRaw(requestParameters, initOverrides) {
-        return __awaiter(this, void 0, void 0, function* () {
-            if (requestParameters['partnerId'] == null) {
-                throw new runtime.RequiredError('partnerId', 'Required parameter "partnerId" was null or undefined when calling adjustPartnerCredits().');
-            }
-            if (requestParameters['adjustPartnerCreditsRequest'] == null) {
-                throw new runtime.RequiredError('adjustPartnerCreditsRequest', 'Required parameter "adjustPartnerCreditsRequest" was null or undefined when calling adjustPartnerCredits().');
-            }
-            const queryParameters = {};
-            const headerParameters = {};
-            headerParameters['Content-Type'] = 'application/json';
-            if (requestParameters['idempotencyKey'] != null) {
-                headerParameters['Idempotency-Key'] = String(requestParameters['idempotencyKey']);
-            }
-            if (this.configuration && this.configuration.accessToken) {
-                const token = this.configuration.accessToken;
-                const tokenString = yield token("apiKeyAuth", []);
-                if (tokenString) {
-                    headerParameters["Authorization"] = `Bearer ${tokenString}`;
-                }
-            }
-            const response = yield this.request({
-                path: `/admin/partners/{partnerId}/credits`.replace(`{${"partnerId"}}`, encodeURIComponent(String(requestParameters['partnerId']))),
-                method: 'POST',
-                headers: headerParameters,
-                query: queryParameters,
-                body: AdjustPartnerCreditsRequestToJSON(requestParameters['adjustPartnerCreditsRequest']),
-            }, initOverrides);
-            return new runtime.JSONApiResponse(response, (jsonValue) => AdjustPartnerCredits200ResponseFromJSON(jsonValue));
-        });
-    }
-    /**
-     * Admin only. A positive `amount` adds credits to the partner wallet; a negative `amount` removes them (the wallet must hold them). An `amount` of 0, or one that is not a finite number, is refused with 400. **One top-up may not exceed $100,000** (`BILLING_CONFIG.PARTNER_WALLET`), which is 1,000,000 credits at the list price of $0.10 per credit. A larger amount is refused with 400 and nothing is credited. The same ceiling applies to `POST /admin/billing/refund` and to the `creditBalance` field of `PUT /admin/partners/{partnerId}`. Removing credits is not limited by it. The `Idempotency-Key` header is required and names the adjustment: a retry with the same key replays the first result (`replayed: true`) instead of moving the balance twice, and a request without one is refused with 400. This moves a PARTNER\'s wallet. A user\'s balance is moved by `POST /admin/billing/credits/adjust`.
-     * Add credits to, or remove credits from, a partner\'s wallet
-     */
-    adjustPartnerCredits(requestParameters, initOverrides) {
-        return __awaiter(this, void 0, void 0, function* () {
-            const response = yield this.adjustPartnerCreditsRaw(requestParameters, initOverrides);
-            return yield response.value();
-        });
-    }
-    /**
-     * Admin only. A positive `amount` grants free credits; a negative `amount` takes credits away (the balance must hold them). An `amount` of 0, or one that is not a finite number, is refused with 400. The `Idempotency-Key` header is required and names the adjustment: a retry with the same key replays the first result (`replayed: true`) instead of moving the balance twice, and a request without one is refused with 400. Free credits are limited per admin: one request may grant at most `ADMIN_GRANT_MAX_PER_REQUEST` credits (default 5000) and one admin may grant at most `ADMIN_GRANT_DAILY_LIMIT` credits alone per UTC day (default 10000), counted across this route, `POST /credits/add` and the grants route (`POST /admin-billing/grants`). Removing credits is not counted. A request over the per-request limit is refused with 400; one that would pass the daily limit is refused with 429 and `ADMIN_GRANT_LIMIT_REACHED` (`error.details` has the limit, what was used, what is left and when the day resets). This moves a USER\'s balance. A partner\'s wallet is moved by `POST /admin/partners/{partnerId}/credits`.
+     * Admin only. A positive `amount` grants free credits; a negative `amount` takes credits away (the balance must hold them). An `amount` of 0, or one that is not a finite number, is refused with 400. The `Idempotency-Key` header is required and names the adjustment: a retry with the same key replays the first result (`replayed: true`) instead of moving the balance twice, and a request without one is refused with 400. Free credits are limited per admin: one request may grant at most `ADMIN_GRANT_MAX_PER_REQUEST` credits (default 5000) and one admin may grant at most `ADMIN_GRANT_DAILY_LIMIT` credits alone per UTC day (default 10000), counted across this route, `POST /credits/add` and the grants route (`POST /admin-billing/grants`). Removing credits is not counted. A request over the per-request limit is refused with 400; one that would pass the daily limit is refused with 429 and `ADMIN_GRANT_LIMIT_REACHED` (`error.details` has the limit, what was used, what is left and when the day resets). This moves a USER\'s balance, which includes the account a partner\'s builds are charged to (its administrator\'s): the credits of a paid partner invoice are added there, and a clawback of them is made here. No route writes to a partner\'s own wallet any more, so this is the one place a partner\'s credits are taken back.
      * Add credits to, or remove credits from, a user\'s balance
      */
     adjustUserCreditsRaw(requestParameters, initOverrides) {
@@ -104,7 +59,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. A positive `amount` grants free credits; a negative `amount` takes credits away (the balance must hold them). An `amount` of 0, or one that is not a finite number, is refused with 400. The `Idempotency-Key` header is required and names the adjustment: a retry with the same key replays the first result (`replayed: true`) instead of moving the balance twice, and a request without one is refused with 400. Free credits are limited per admin: one request may grant at most `ADMIN_GRANT_MAX_PER_REQUEST` credits (default 5000) and one admin may grant at most `ADMIN_GRANT_DAILY_LIMIT` credits alone per UTC day (default 10000), counted across this route, `POST /credits/add` and the grants route (`POST /admin-billing/grants`). Removing credits is not counted. A request over the per-request limit is refused with 400; one that would pass the daily limit is refused with 429 and `ADMIN_GRANT_LIMIT_REACHED` (`error.details` has the limit, what was used, what is left and when the day resets). This moves a USER\'s balance. A partner\'s wallet is moved by `POST /admin/partners/{partnerId}/credits`.
+     * Admin only. A positive `amount` grants free credits; a negative `amount` takes credits away (the balance must hold them). An `amount` of 0, or one that is not a finite number, is refused with 400. The `Idempotency-Key` header is required and names the adjustment: a retry with the same key replays the first result (`replayed: true`) instead of moving the balance twice, and a request without one is refused with 400. Free credits are limited per admin: one request may grant at most `ADMIN_GRANT_MAX_PER_REQUEST` credits (default 5000) and one admin may grant at most `ADMIN_GRANT_DAILY_LIMIT` credits alone per UTC day (default 10000), counted across this route, `POST /credits/add` and the grants route (`POST /admin-billing/grants`). Removing credits is not counted. A request over the per-request limit is refused with 400; one that would pass the daily limit is refused with 429 and `ADMIN_GRANT_LIMIT_REACHED` (`error.details` has the limit, what was used, what is left and when the day resets). This moves a USER\'s balance, which includes the account a partner\'s builds are charged to (its administrator\'s): the credits of a paid partner invoice are added there, and a clawback of them is made here. No route writes to a partner\'s own wallet any more, so this is the one place a partner\'s credits are taken back.
      * Add credits to, or remove credits from, a user\'s balance
      */
     adjustUserCredits(requestParameters, initOverrides) {
@@ -193,7 +148,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. This is how a partner comes to exist; there is no self-serve sign-up for one. **Before calling it**, the user who will administer the partner must exist and have the `partner` role (`PUT /admin/users/{userId}/role`). Every partner route belongs to that role, so a partner administered by an ordinary user would be created and then be unusable; such a request is refused with 400 and says so. A user with the `admin` role is accepted too. **A partner has no API key of its own, and none is issued.** The administrator calls the API with the `wgt_prt_` key of their own account: they make it themselves (`POST /users/{id}/keys`, or the dashboard\'s key screen), or Widgetic staff make it for them (the same route, called by an admin). **The new partner starts inactive, and is unusable until an administrator activates it.** A partner has no trial and pays from day one, so nothing it or its customers do works yet: its embeds are not served, its editor sessions are refused and its API key can only read and manage its billing. Activate it with `PUT /admin/partners/{partnerId}/status` (`active`) once the contract and a verified storage destination are in place (`GET /admin/partners/{partnerId}/activation` lists what is missing). Sending `isActive: true` here is refused, because it would skip that check. The new partner starts with an empty wallet and no contract. Fund the wallet with `POST /admin/partners/{partnerId}/credits` and record the contract terms with `POST /partner-customizations/{partnerId}`. Neither is a field of this request, and a field this request does not name is refused with 400 rather than ignored. Creating the partner also records the partner plan on its administrator\'s own account (`plan.partner`). A partner is not bought, so the administrator\'s account holds no subscription of its own. If that record could not be written the partner is still created (a refusal would hide that it exists, and a retry would be a 409) and `warnings` says so; sending the status `active` for the partner again (`PUT /admin/partners/{partnerId}/status`) records it. Pausing or deactivating the partner stops what it published from being served. A partner `name` is unique: one already in use is refused with 409 and nothing is created. This route takes no `Idempotency-Key`: the unique name makes a retry safe on its own. A retry after a dropped response gets 409 for the partner the first attempt created; find it with `GET /admin/partners` (`searchTerm`).
+     * Admin only. This is how a partner comes to exist; there is no self-serve sign-up for one. **Before calling it**, the user who will administer the partner must exist and have the `partner` role (`PUT /admin/users/{userId}/role`). Every partner route belongs to that role, so a partner administered by an ordinary user would be created and then be unusable; such a request is refused with 400 and says so. A user with the `admin` role is accepted too. **A partner has no API key of its own, and none is issued.** The administrator calls the API with the `wgt_prt_` key of their own account: they make it themselves (`POST /users/{id}/keys`, or the dashboard\'s key screen), or Widgetic staff make it for them (the same route, called by an admin). **The new partner starts inactive, and is unusable until an administrator activates it.** A partner has no trial and pays from day one, so nothing it or its customers do works yet: its embeds are not served, its editor sessions are refused and its API key can only read and manage its billing. Activate it with `PUT /admin/partners/{partnerId}/status` (`active`) once the contract and a verified storage destination are in place (`GET /admin/partners/{partnerId}/activation` lists what is missing). Sending `isActive: true` here is refused, because it would skip that check. The new partner starts with no credits and no contract. It is credited by a paid invoice that carries credits (`POST /admin-billing/partner/{partnerId}/invoice`), and the contract terms are recorded with `POST /partner-customizations/{partnerId}`. Neither is a field of this request, and a field this request does not name is refused with 400 rather than ignored. Creating the partner also records the partner plan on its administrator\'s own account (`plan.partner`). A partner is not bought, so the administrator\'s account holds no subscription of its own. If that record could not be written the partner is still created (a refusal would hide that it exists, and a retry would be a 409) and `warnings` says so; sending the status `active` for the partner again (`PUT /admin/partners/{partnerId}/status`) records it. Pausing or deactivating the partner stops what it published from being served. A partner `name` is unique: one already in use is refused with 409 and nothing is created. This route takes no `Idempotency-Key`: the unique name makes a retry safe on its own. A retry after a dropped response gets 409 for the partner the first attempt created; find it with `GET /admin/partners` (`searchTerm`).
      * Create a partner
      */
     createPartnerRaw(requestParameters, initOverrides) {
@@ -222,7 +177,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. This is how a partner comes to exist; there is no self-serve sign-up for one. **Before calling it**, the user who will administer the partner must exist and have the `partner` role (`PUT /admin/users/{userId}/role`). Every partner route belongs to that role, so a partner administered by an ordinary user would be created and then be unusable; such a request is refused with 400 and says so. A user with the `admin` role is accepted too. **A partner has no API key of its own, and none is issued.** The administrator calls the API with the `wgt_prt_` key of their own account: they make it themselves (`POST /users/{id}/keys`, or the dashboard\'s key screen), or Widgetic staff make it for them (the same route, called by an admin). **The new partner starts inactive, and is unusable until an administrator activates it.** A partner has no trial and pays from day one, so nothing it or its customers do works yet: its embeds are not served, its editor sessions are refused and its API key can only read and manage its billing. Activate it with `PUT /admin/partners/{partnerId}/status` (`active`) once the contract and a verified storage destination are in place (`GET /admin/partners/{partnerId}/activation` lists what is missing). Sending `isActive: true` here is refused, because it would skip that check. The new partner starts with an empty wallet and no contract. Fund the wallet with `POST /admin/partners/{partnerId}/credits` and record the contract terms with `POST /partner-customizations/{partnerId}`. Neither is a field of this request, and a field this request does not name is refused with 400 rather than ignored. Creating the partner also records the partner plan on its administrator\'s own account (`plan.partner`). A partner is not bought, so the administrator\'s account holds no subscription of its own. If that record could not be written the partner is still created (a refusal would hide that it exists, and a retry would be a 409) and `warnings` says so; sending the status `active` for the partner again (`PUT /admin/partners/{partnerId}/status`) records it. Pausing or deactivating the partner stops what it published from being served. A partner `name` is unique: one already in use is refused with 409 and nothing is created. This route takes no `Idempotency-Key`: the unique name makes a retry safe on its own. A retry after a dropped response gets 409 for the partner the first attempt created; find it with `GET /admin/partners` (`searchTerm`).
+     * Admin only. This is how a partner comes to exist; there is no self-serve sign-up for one. **Before calling it**, the user who will administer the partner must exist and have the `partner` role (`PUT /admin/users/{userId}/role`). Every partner route belongs to that role, so a partner administered by an ordinary user would be created and then be unusable; such a request is refused with 400 and says so. A user with the `admin` role is accepted too. **A partner has no API key of its own, and none is issued.** The administrator calls the API with the `wgt_prt_` key of their own account: they make it themselves (`POST /users/{id}/keys`, or the dashboard\'s key screen), or Widgetic staff make it for them (the same route, called by an admin). **The new partner starts inactive, and is unusable until an administrator activates it.** A partner has no trial and pays from day one, so nothing it or its customers do works yet: its embeds are not served, its editor sessions are refused and its API key can only read and manage its billing. Activate it with `PUT /admin/partners/{partnerId}/status` (`active`) once the contract and a verified storage destination are in place (`GET /admin/partners/{partnerId}/activation` lists what is missing). Sending `isActive: true` here is refused, because it would skip that check. The new partner starts with no credits and no contract. It is credited by a paid invoice that carries credits (`POST /admin-billing/partner/{partnerId}/invoice`), and the contract terms are recorded with `POST /partner-customizations/{partnerId}`. Neither is a field of this request, and a field this request does not name is refused with 400 rather than ignored. Creating the partner also records the partner plan on its administrator\'s own account (`plan.partner`). A partner is not bought, so the administrator\'s account holds no subscription of its own. If that record could not be written the partner is still created (a refusal would hide that it exists, and a retry would be a 409) and `warnings` says so; sending the status `active` for the partner again (`PUT /admin/partners/{partnerId}/status`) records it. Pausing or deactivating the partner stops what it published from being served. A partner `name` is unique: one already in use is refused with 409 and nothing is created. This route takes no `Idempotency-Key`: the unique name makes a retry safe on its own. A retry after a dropped response gets 409 for the partner the first attempt created; find it with `GET /admin/partners` (`searchTerm`).
      * Create a partner
      */
     createPartner(requestParameters, initOverrides) {
@@ -303,7 +258,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Reads the billing profile of a partner: the legal name, the billing emails, the billing address, the tax number and the payment terms, and what the invoices will say with them. A partner that has none saved has the defaults (the partner\'s own name, its contact email, 30 days, no address), and `gaps` says what is missing for an invoice to carry the right tax. Nothing is changed by reading it.
+     * Admin only. Reads the billing profile of a partner: the legal name, the billing emails, the billing address, the tax number and the payment terms, and what the invoices will say with them. A partner that has none saved has the defaults (the partner\'s own name, its contact email, 7 days, no address), and `gaps` says what is missing for an invoice to carry the right tax. Nothing is changed by reading it.
      * What a partner\'s invoices are addressed with
      */
     getPartnerBillingProfileRaw(requestParameters, initOverrides) {
@@ -330,7 +285,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Reads the billing profile of a partner: the legal name, the billing emails, the billing address, the tax number and the payment terms, and what the invoices will say with them. A partner that has none saved has the defaults (the partner\'s own name, its contact email, 30 days, no address), and `gaps` says what is missing for an invoice to carry the right tax. Nothing is changed by reading it.
+     * Admin only. Reads the billing profile of a partner: the legal name, the billing emails, the billing address, the tax number and the payment terms, and what the invoices will say with them. A partner that has none saved has the defaults (the partner\'s own name, its contact email, 7 days, no address), and `gaps` says what is missing for an invoice to carry the right tax. Nothing is changed by reading it.
      * What a partner\'s invoices are addressed with
      */
     getPartnerBillingProfile(requestParameters, initOverrides) {
@@ -386,7 +341,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. The partner, with three things an administrator needs beside it: the billing overview (wallet, auto-reload settings, the ten newest ledger rows, the contract if one is recorded), the statistics of the last month\'s wallet activity, and a little metadata. The overview and the statistics are read at request time and are `null` when they could not be assembled: the partner itself is still returned. `monthlyStats.userCount` is `null` while the partner\'s member list cannot be read.
+     * Admin only. The partner, with three things an administrator needs beside it: the billing overview (wallet, the ten newest ledger rows, the contract if one is recorded), the statistics of the last month\'s wallet activity, and a little metadata. The overview and the statistics are read at request time and are `null` when they could not be assembled: the partner itself is still returned. `monthlyStats.userCount` is `null` while the partner\'s member list cannot be read.
      * Get a partner with its billing overview and last month\'s statistics
      */
     getPartnerDetailsRaw(requestParameters, initOverrides) {
@@ -413,7 +368,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. The partner, with three things an administrator needs beside it: the billing overview (wallet, auto-reload settings, the ten newest ledger rows, the contract if one is recorded), the statistics of the last month\'s wallet activity, and a little metadata. The overview and the statistics are read at request time and are `null` when they could not be assembled: the partner itself is still returned. `monthlyStats.userCount` is `null` while the partner\'s member list cannot be read.
+     * Admin only. The partner, with three things an administrator needs beside it: the billing overview (wallet, the ten newest ledger rows, the contract if one is recorded), the statistics of the last month\'s wallet activity, and a little metadata. The overview and the statistics are read at request time and are `null` when they could not be assembled: the partner itself is still returned. `monthlyStats.userCount` is `null` while the partner\'s member list cannot be read.
      * Get a partner with its billing overview and last month\'s statistics
      */
     getPartnerDetails(requestParameters, initOverrides) {
@@ -459,6 +414,43 @@ export class AdminApi extends runtime.BaseAPI {
             return yield response.value();
         });
     }
+    /**
+     * Admin only. Shows what the daily invoicing run does with a partner\'s contract: the terms it runs on, the invoice that goes out next (the period, the day, the credits, the price of a credit and the amount before tax), the periods the run has taken so far with where each invoice stands, and the contract invoices the partner owes past their due day. The first invoice goes out on the contract\'s start date, the others 7 days before their period starts, for the credits of the period at the contract\'s price of a credit; the credits are added when the invoice is paid and expire when the period ends. `next` is worked out with the rules the run uses, so it is what the next run will do, including why it will not issue anything (`blocked`). Nothing is changed by reading it.
+     * When a partner\'s contract is invoiced next, and what it owes
+     */
+    getPartnerInvoiceScheduleRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['partnerId'] == null) {
+                throw new runtime.RequiredError('partnerId', 'Required parameter "partnerId" was null or undefined when calling getPartnerInvoiceSchedule().');
+            }
+            const queryParameters = {};
+            const headerParameters = {};
+            if (this.configuration && this.configuration.accessToken) {
+                const token = this.configuration.accessToken;
+                const tokenString = yield token("apiKeyAuth", []);
+                if (tokenString) {
+                    headerParameters["Authorization"] = `Bearer ${tokenString}`;
+                }
+            }
+            const response = yield this.request({
+                path: `/admin/partners/{partnerId}/invoice-schedule`.replace(`{${"partnerId"}}`, encodeURIComponent(String(requestParameters['partnerId']))),
+                method: 'GET',
+                headers: headerParameters,
+                query: queryParameters,
+            }, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => PartnerInvoiceScheduleFromJSON(jsonValue));
+        });
+    }
+    /**
+     * Admin only. Shows what the daily invoicing run does with a partner\'s contract: the terms it runs on, the invoice that goes out next (the period, the day, the credits, the price of a credit and the amount before tax), the periods the run has taken so far with where each invoice stands, and the contract invoices the partner owes past their due day. The first invoice goes out on the contract\'s start date, the others 7 days before their period starts, for the credits of the period at the contract\'s price of a credit; the credits are added when the invoice is paid and expire when the period ends. `next` is worked out with the rules the run uses, so it is what the next run will do, including why it will not issue anything (`blocked`). Nothing is changed by reading it.
+     * When a partner\'s contract is invoiced next, and what it owes
+     */
+    getPartnerInvoiceSchedule(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.getPartnerInvoiceScheduleRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
     /**
      * Admin only. `scope=mine` is the signed-in admin\'s widgets. `scope=others` is every other account. `scope=all` is every account. `preset=true` keeps widgets marked for signup copy. A normal account cannot call this route.
      * List widgets for the admin console
@@ -557,7 +549,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. For an invoice that was paid by bank transfer, cheque or any other way outside Stripe. It marks the invoice paid in Stripe (`paid_out_of_band`), and Stripe then reports the payment exactly as it reports a card payment: the partner\'s invoice list is brought up to date (status and paid date), the reminders stop, the partner receives its receipt, and the administrators are told the payment arrived. Nothing is written to the partner\'s invoice list here, so the list changes a moment after the answer, when Stripe\'s report arrives; an administrator never updates a status by hand. The invoice is named by its id in the partner\'s invoice list and must belong to this partner. An invoice Stripe already holds as paid is answered (`recorded: false`) and nothing happens again, so a double click or a retry is safe. An invoice Stripe holds as void, uncollectible or still a draft cannot be marked paid (409 `INVOICE_NOT_PAYABLE`), and one that was never issued through Stripe has nothing to mark (409 `INVOICE_HAS_NO_STRIPE_INVOICE`). The audit trail records who recorded it, with the optional `note` (a bank reference, say).
+     * Admin only. For an invoice that was paid by bank transfer, cheque or any other way outside Stripe. It marks the invoice paid in Stripe (`paid_out_of_band`), and Stripe then reports the payment exactly as it reports a card payment: the partner\'s invoice list is brought up to date (status and paid date), the reminders stop, the partner receives its receipt, and the administrators are told the payment arrived. An invoice that was issued for credits (`credits` on `issuePartnerInvoice`) also adds them to the partner administrator\'s account at that moment, once. Nothing is written to the partner\'s invoice list here, so the list changes a moment after the answer, when Stripe\'s report arrives; an administrator never updates a status by hand. The invoice is named by its id in the partner\'s invoice list and must belong to this partner. An invoice Stripe already holds as paid is answered (`recorded: false`) and nothing happens again, so a double click or a retry is safe. An invoice Stripe holds as void, uncollectible or still a draft cannot be marked paid (409 `INVOICE_NOT_PAYABLE`), and one that was never issued through Stripe has nothing to mark (409 `INVOICE_HAS_NO_STRIPE_INVOICE`). The audit trail records who recorded it, with the optional `note` (a bank reference, say).
      * Record a payment that arrived outside Stripe
      */
     recordPartnerInvoicePaymentRaw(requestParameters, initOverrides) {
@@ -592,7 +584,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. For an invoice that was paid by bank transfer, cheque or any other way outside Stripe. It marks the invoice paid in Stripe (`paid_out_of_band`), and Stripe then reports the payment exactly as it reports a card payment: the partner\'s invoice list is brought up to date (status and paid date), the reminders stop, the partner receives its receipt, and the administrators are told the payment arrived. Nothing is written to the partner\'s invoice list here, so the list changes a moment after the answer, when Stripe\'s report arrives; an administrator never updates a status by hand. The invoice is named by its id in the partner\'s invoice list and must belong to this partner. An invoice Stripe already holds as paid is answered (`recorded: false`) and nothing happens again, so a double click or a retry is safe. An invoice Stripe holds as void, uncollectible or still a draft cannot be marked paid (409 `INVOICE_NOT_PAYABLE`), and one that was never issued through Stripe has nothing to mark (409 `INVOICE_HAS_NO_STRIPE_INVOICE`). The audit trail records who recorded it, with the optional `note` (a bank reference, say).
+     * Admin only. For an invoice that was paid by bank transfer, cheque or any other way outside Stripe. It marks the invoice paid in Stripe (`paid_out_of_band`), and Stripe then reports the payment exactly as it reports a card payment: the partner\'s invoice list is brought up to date (status and paid date), the reminders stop, the partner receives its receipt, and the administrators are told the payment arrived. An invoice that was issued for credits (`credits` on `issuePartnerInvoice`) also adds them to the partner administrator\'s account at that moment, once. Nothing is written to the partner\'s invoice list here, so the list changes a moment after the answer, when Stripe\'s report arrives; an administrator never updates a status by hand. The invoice is named by its id in the partner\'s invoice list and must belong to this partner. An invoice Stripe already holds as paid is answered (`recorded: false`) and nothing happens again, so a double click or a retry is safe. An invoice Stripe holds as void, uncollectible or still a draft cannot be marked paid (409 `INVOICE_NOT_PAYABLE`), and one that was never issued through Stripe has nothing to mark (409 `INVOICE_HAS_NO_STRIPE_INVOICE`). The audit trail records who recorded it, with the optional `note` (a bank reference, say).
      * Record a payment that arrived outside Stripe
      */
     recordPartnerInvoicePayment(requestParameters, initOverrides) {
@@ -602,49 +594,8 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Adds `amount` credits to the partner wallet as a refund. The `Idempotency-Key` header is required: a retry with the same key replays the first refund instead of issuing a second one. A refund is held to the same ceiling as a top-up: **at most $100,000 per operation** (1,000,000 credits at $0.10 per credit). A larger amount is refused with 400 and nothing is credited.
-     * Credit a partner\'s wallet back with a refund
-     */
-    refundPartnerCreditsRaw(requestParameters, initOverrides) {
-        return __awaiter(this, void 0, void 0, function* () {
-            if (requestParameters['refundPartnerCreditsRequest'] == null) {
-                throw new runtime.RequiredError('refundPartnerCreditsRequest', 'Required parameter "refundPartnerCreditsRequest" was null or undefined when calling refundPartnerCredits().');
-            }
-            const queryParameters = {};
-            const headerParameters = {};
-            headerParameters['Content-Type'] = 'application/json';
-            if (requestParameters['idempotencyKey'] != null) {
-                headerParameters['Idempotency-Key'] = String(requestParameters['idempotencyKey']);
-            }
-            if (this.configuration && this.configuration.accessToken) {
-                const token = this.configuration.accessToken;
-                const tokenString = yield token("apiKeyAuth", []);
-                if (tokenString) {
-                    headerParameters["Authorization"] = `Bearer ${tokenString}`;
-                }
-            }
-            const response = yield this.request({
-                path: `/admin/billing/refund`,
-                method: 'POST',
-                headers: headerParameters,
-                query: queryParameters,
-                body: RefundPartnerCreditsRequestToJSON(requestParameters['refundPartnerCreditsRequest']),
-            }, initOverrides);
-            return new runtime.VoidApiResponse(response);
-        });
-    }
-    /**
-     * Admin only. Adds `amount` credits to the partner wallet as a refund. The `Idempotency-Key` header is required: a retry with the same key replays the first refund instead of issuing a second one. A refund is held to the same ceiling as a top-up: **at most $100,000 per operation** (1,000,000 credits at $0.10 per credit). A larger amount is refused with 400 and nothing is credited.
-     * Credit a partner\'s wallet back with a refund
-     */
-    refundPartnerCredits(requestParameters, initOverrides) {
-        return __awaiter(this, void 0, void 0, function* () {
-            yield this.refundPartnerCreditsRaw(requestParameters, initOverrides);
-        });
-    }
-    /**
-     * Admin only. Every field is optional; send the ones to change. The profile fields (`name`, `email`, `webhookUrl`, `allowedDomains`, `billingSettings`) are stored on the partner. `autoReloadAmount` and `autoReloadThreshold` are stored with the partner\'s auto-reload settings, which are a different record: an edit to one of them keeps the other and the rest of the configuration. `creditBalance` is a **target balance**, not a stored value. The wallet is moved by the difference between it and the balance the ledger holds now, as a ledger row, by the same keyed path `POST /admin/partners/{partnerId}/credits` uses. So a request that sets it **must** carry an `Idempotency-Key` (a request without one is refused with 400 and changes nothing, not even the fields beside it), a top-up is held to the same ceiling of $100,000 per operation, and a retry with the same key replays the first result instead of moving the wallet twice. `notes` becomes the reason on that ledger row. A request that sets no balance needs no key. `isActive` only flips the switch, and goes through the same check as `PUT /admin/partners/{partnerId}/status`: activating a partner that was never activated is refused with 409 `PARTNER_NOT_READY` until its contract and storage destination are in place, and the fields beside it are not written when it is refused. To pause a partner with a recorded reason, or to resume one so that everything the pause turned off is restored, use `PUT /admin/partners/{partnerId}/status`. The response is the partner as it is after the edit; `creditAdjustment` and `autoReload` report what was done to the wallet and the settings, when the request touched them.
-     * Edit a partner\'s profile, wallet balance or auto-reload settings
+     * Admin only. Every field is optional; send the ones to change. The profile fields (`name`, `email`, `webhookUrl`, `allowedDomains`, `platformDomain`, `billingSettings`) are stored on the partner. This route no longer touches the partner\'s wallet, and four fields it used to accept are retired: `autoReloadAmount` and `autoReloadThreshold` (a wallet is not reloaded automatically), `creditBalance` (a wallet is not set to a balance by hand) and `notes` (the reason that went with a balance change). A request that carries any of them is refused with 400 that names it, and nothing in the request is written, not even the fields beside it. Credits come with a paid partner invoice (`POST /admin-billing/partner/{partnerId}/invoice` with `credits`), and they are added to the partner\'s administrator\'s account; a clawback of them is made on that account, with `POST /admin/billing/credits/adjust`. `isActive` only flips the switch, and goes through the same check as `PUT /admin/partners/{partnerId}/status`: activating a partner that was never activated is refused with 409 `PARTNER_NOT_READY` until its contract and storage destination are in place, and the fields beside it are not written when it is refused. To pause a partner with a recorded reason, or to resume one so that everything the pause turned off is restored, use `PUT /admin/partners/{partnerId}/status`. The response is the partner as it is after the edit.
+     * Edit a partner\'s profile
      */
     updatePartnerRaw(requestParameters, initOverrides) {
         return __awaiter(this, void 0, void 0, function* () {
@@ -678,8 +629,8 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Every field is optional; send the ones to change. The profile fields (`name`, `email`, `webhookUrl`, `allowedDomains`, `billingSettings`) are stored on the partner. `autoReloadAmount` and `autoReloadThreshold` are stored with the partner\'s auto-reload settings, which are a different record: an edit to one of them keeps the other and the rest of the configuration. `creditBalance` is a **target balance**, not a stored value. The wallet is moved by the difference between it and the balance the ledger holds now, as a ledger row, by the same keyed path `POST /admin/partners/{partnerId}/credits` uses. So a request that sets it **must** carry an `Idempotency-Key` (a request without one is refused with 400 and changes nothing, not even the fields beside it), a top-up is held to the same ceiling of $100,000 per operation, and a retry with the same key replays the first result instead of moving the wallet twice. `notes` becomes the reason on that ledger row. A request that sets no balance needs no key. `isActive` only flips the switch, and goes through the same check as `PUT /admin/partners/{partnerId}/status`: activating a partner that was never activated is refused with 409 `PARTNER_NOT_READY` until its contract and storage destination are in place, and the fields beside it are not written when it is refused. To pause a partner with a recorded reason, or to resume one so that everything the pause turned off is restored, use `PUT /admin/partners/{partnerId}/status`. The response is the partner as it is after the edit; `creditAdjustment` and `autoReload` report what was done to the wallet and the settings, when the request touched them.
-     * Edit a partner\'s profile, wallet balance or auto-reload settings
+     * Admin only. Every field is optional; send the ones to change. The profile fields (`name`, `email`, `webhookUrl`, `allowedDomains`, `platformDomain`, `billingSettings`) are stored on the partner. This route no longer touches the partner\'s wallet, and four fields it used to accept are retired: `autoReloadAmount` and `autoReloadThreshold` (a wallet is not reloaded automatically), `creditBalance` (a wallet is not set to a balance by hand) and `notes` (the reason that went with a balance change). A request that carries any of them is refused with 400 that names it, and nothing in the request is written, not even the fields beside it. Credits come with a paid partner invoice (`POST /admin-billing/partner/{partnerId}/invoice` with `credits`), and they are added to the partner\'s administrator\'s account; a clawback of them is made on that account, with `POST /admin/billing/credits/adjust`. `isActive` only flips the switch, and goes through the same check as `PUT /admin/partners/{partnerId}/status`: activating a partner that was never activated is refused with 409 `PARTNER_NOT_READY` until its contract and storage destination are in place, and the fields beside it are not written when it is refused. To pause a partner with a recorded reason, or to resume one so that everything the pause turned off is restored, use `PUT /admin/partners/{partnerId}/status`. The response is the partner as it is after the edit.
+     * Edit a partner\'s profile
      */
     updatePartner(requestParameters, initOverrides) {
         return __awaiter(this, void 0, void 0, function* () {
@@ -772,7 +723,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` activates a new partner, or resumes a paused one: it is switched on, and a suspension\'s reason   and time are cleared. **Activating a partner that was never activated (or was deactivated) is refused with   409 `PARTNER_NOT_READY` until a contract is in force and a verified storage destination is set**   (`error.details.requirements` lists each, and `GET /admin/partners/{partnerId}/activation` reads them   without changing anything). Resuming a paused partner is never held up by that. It also records the   partner plan on the partner\'s administrator again if that was missing (a partner created before the plan   was recorded, or whose write failed); if that could not be done the partner is still reinstated and   `warnings` says so. - `inactive` switches the partner off without a reason; a suspension\'s reason and time are cleared, so   a partner moved from suspended to inactive is no longer reported as suspended. - `suspended` is the pause: it switches the partner off and records `reason` (default `Suspended by   admin`) and the time. It is manual only. An unpaid invoice is chased and reported to the administrators,   but never pauses a partner by itself.  While a partner is not `active` it is unusable, and what it published is not served: its embeds answer as if they did not exist, editor sessions are refused, its customers cannot create or generate anything, and every write or generation by its API key is refused with 403 `PARTNER_SUSPENDED` (or `PARTNER_INACTIVE`). This takes hold within 15 seconds at most, on every instance. The partner\'s own administrator can still sign in and use billing, invoices, credits, the contract and notifications. Resuming the partner restores everything, with no new token for a customer. A person who administers two partners is served while either is active, and an administrator account that also holds a subscription of its own is served on that. Sending the standing the partner already has is accepted; for `suspended` it replaces the recorded reason and time.
+     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` activates a new partner, or resumes a paused one: it is switched on, and a suspension\'s reason   and time are cleared. **Activating a partner that was never activated (or was deactivated) is refused with   409 `PARTNER_NOT_READY` until a contract is in force and a verified storage destination is set**   (`error.details.requirements` lists each, and `GET /admin/partners/{partnerId}/activation` reads them   without changing anything). Resuming a paused partner is never held up by that. It also records the   partner plan on the partner\'s administrator again if that was missing (a partner created before the plan   was recorded, or whose write failed); if that could not be done the partner is still reinstated and   `warnings` says so. - `inactive` switches the partner off without a reason; a suspension\'s reason and time are cleared, so   a partner moved from suspended to inactive is no longer reported as suspended. - `suspended` is the pause: it switches the partner off and records `reason` (default `Suspended by   admin`) and the time. It is manual only. An unpaid invoice is chased and reported to the administrators,   and never pauses a partner by itself: a contract invoice left unpaid past its due date STOPS the partner   on its own from the day after (standing `payment_arrears`, refused with 403 `PARTNER_PAYMENT_ARREARS`).   That records nothing on the partner and is not a status you set: it ends the moment the invoice is paid,   voided or written off, and an invoice for extra credits never causes it.  While a partner is not `active` it is unusable, and what it published is not served: its embeds answer as if they did not exist, editor sessions are refused, its customers cannot create or generate anything, and every write or generation by its API key is refused with 403 `PARTNER_SUSPENDED` (or `PARTNER_INACTIVE`). This takes hold within 15 seconds at most, on every instance. The partner\'s own administrator can still sign in and use billing, invoices, credits, the contract and notifications. Resuming the partner restores everything, with no new token for a customer. A person who administers two partners is served while either is active, and an administrator account that also holds a subscription of its own is served on that. Sending the standing the partner already has is accepted; for `suspended` it replaces the recorded reason and time.
      * Activate, deactivate or suspend a partner
      */
     updatePartnerStatusRaw(requestParameters, initOverrides) {
@@ -804,7 +755,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` activates a new partner, or resumes a paused one: it is switched on, and a suspension\'s reason   and time are cleared. **Activating a partner that was never activated (or was deactivated) is refused with   409 `PARTNER_NOT_READY` until a contract is in force and a verified storage destination is set**   (`error.details.requirements` lists each, and `GET /admin/partners/{partnerId}/activation` reads them   without changing anything). Resuming a paused partner is never held up by that. It also records the   partner plan on the partner\'s administrator again if that was missing (a partner created before the plan   was recorded, or whose write failed); if that could not be done the partner is still reinstated and   `warnings` says so. - `inactive` switches the partner off without a reason; a suspension\'s reason and time are cleared, so   a partner moved from suspended to inactive is no longer reported as suspended. - `suspended` is the pause: it switches the partner off and records `reason` (default `Suspended by   admin`) and the time. It is manual only. An unpaid invoice is chased and reported to the administrators,   but never pauses a partner by itself.  While a partner is not `active` it is unusable, and what it published is not served: its embeds answer as if they did not exist, editor sessions are refused, its customers cannot create or generate anything, and every write or generation by its API key is refused with 403 `PARTNER_SUSPENDED` (or `PARTNER_INACTIVE`). This takes hold within 15 seconds at most, on every instance. The partner\'s own administrator can still sign in and use billing, invoices, credits, the contract and notifications. Resuming the partner restores everything, with no new token for a customer. A person who administers two partners is served while either is active, and an administrator account that also holds a subscription of its own is served on that. Sending the standing the partner already has is accepted; for `suspended` it replaces the recorded reason and time.
+     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` activates a new partner, or resumes a paused one: it is switched on, and a suspension\'s reason   and time are cleared. **Activating a partner that was never activated (or was deactivated) is refused with   409 `PARTNER_NOT_READY` until a contract is in force and a verified storage destination is set**   (`error.details.requirements` lists each, and `GET /admin/partners/{partnerId}/activation` reads them   without changing anything). Resuming a paused partner is never held up by that. It also records the   partner plan on the partner\'s administrator again if that was missing (a partner created before the plan   was recorded, or whose write failed); if that could not be done the partner is still reinstated and   `warnings` says so. - `inactive` switches the partner off without a reason; a suspension\'s reason and time are cleared, so   a partner moved from suspended to inactive is no longer reported as suspended. - `suspended` is the pause: it switches the partner off and records `reason` (default `Suspended by   admin`) and the time. It is manual only. An unpaid invoice is chased and reported to the administrators,   and never pauses a partner by itself: a contract invoice left unpaid past its due date STOPS the partner   on its own from the day after (standing `payment_arrears`, refused with 403 `PARTNER_PAYMENT_ARREARS`).   That records nothing on the partner and is not a status you set: it ends the moment the invoice is paid,   voided or written off, and an invoice for extra credits never causes it.  While a partner is not `active` it is unusable, and what it published is not served: its embeds answer as if they did not exist, editor sessions are refused, its customers cannot create or generate anything, and every write or generation by its API key is refused with 403 `PARTNER_SUSPENDED` (or `PARTNER_INACTIVE`). This takes hold within 15 seconds at most, on every instance. The partner\'s own administrator can still sign in and use billing, invoices, credits, the contract and notifications. Resuming the partner restores everything, with no new token for a customer. A person who administers two partners is served while either is active, and an administrator account that also holds a subscription of its own is served on that. Sending the standing the partner already has is accepted; for `suspended` it replaces the recorded reason and time.
      * Activate, deactivate or suspend a partner
      */
     updatePartnerStatus(requestParameters, initOverrides) {

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

@@ -319,12 +319,12 @@ export declare class AdminBillingApi extends runtime.BaseAPI {
      */
     adminBillingTeamsSearchGet(requestParameters?: AdminBillingTeamsSearchGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<void>;
     /**
-     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given; the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (30 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
+     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given (or `credits`, see CREDITS below); the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (7 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  CREDITS. This is how a partner gets credits: it pays an invoice for them. Give `credits` and the invoice is for that many Widgetic credits (priced at the list price of a credit unless `amountUsd` is given). They are added to the account of the partner\'s administrator, where the partner\'s builds are charged, when the invoice is paid, whether the partner pays it or an administrator records a payment received outside Stripe, and once per invoice however often Stripe reports the payment. Nothing is added while the invoice is open, void or uncollectible. There is no cap of ours: the invoice is the limit (Stripe\'s own limits on the amount of a payment still apply). An invoice issued without `credits` adds none, whatever its price. A partner with no administrator account cannot be invoiced for credits (422 `NO_PARTNER_ADMINISTRATOR`).  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
      * Issue a contract invoice to a partner
      */
     issuePartnerInvoiceRaw(requestParameters: IssuePartnerInvoiceOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<IssuedPartnerInvoice>>;
     /**
-     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given; the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (30 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
+     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given (or `credits`, see CREDITS below); the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (7 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  CREDITS. This is how a partner gets credits: it pays an invoice for them. Give `credits` and the invoice is for that many Widgetic credits (priced at the list price of a credit unless `amountUsd` is given). They are added to the account of the partner\'s administrator, where the partner\'s builds are charged, when the invoice is paid, whether the partner pays it or an administrator records a payment received outside Stripe, and once per invoice however often Stripe reports the payment. Nothing is added while the invoice is open, void or uncollectible. There is no cap of ours: the invoice is the limit (Stripe\'s own limits on the amount of a payment still apply). An invoice issued without `credits` adds none, whatever its price. A partner with no administrator account cannot be invoiced for credits (422 `NO_PARTNER_ADMINISTRATOR`).  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
      * Issue a contract invoice to a partner
      */
     issuePartnerInvoice(requestParameters: IssuePartnerInvoiceOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<IssuedPartnerInvoice>;

package/dist/esm/apis/AdminBillingApi.js

@@ -961,7 +961,7 @@ export class AdminBillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given; the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (30 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
+     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given (or `credits`, see CREDITS below); the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (7 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  CREDITS. This is how a partner gets credits: it pays an invoice for them. Give `credits` and the invoice is for that many Widgetic credits (priced at the list price of a credit unless `amountUsd` is given). They are added to the account of the partner\'s administrator, where the partner\'s builds are charged, when the invoice is paid, whether the partner pays it or an administrator records a payment received outside Stripe, and once per invoice however often Stripe reports the payment. Nothing is added while the invoice is open, void or uncollectible. There is no cap of ours: the invoice is the limit (Stripe\'s own limits on the amount of a payment still apply). An invoice issued without `credits` adds none, whatever its price. A partner with no administrator account cannot be invoiced for credits (422 `NO_PARTNER_ADMINISTRATOR`).  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
      * Issue a contract invoice to a partner
      */
     issuePartnerInvoiceRaw(requestParameters, initOverrides) {
@@ -993,7 +993,7 @@ export class AdminBillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given; the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (30 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
+     * Issues a Stripe invoice to a partner and has Stripe email it to the partner\'s billing address (the first billing email on its billing profile, else its contact email). The price is the contract price on the partner\'s customization unless `amountUsd` is given (or `credits`, see CREDITS below); the partner must have a contract either way. The invoice is addressed to the legal name on the billing profile (else the partner\'s name) and is due after the payment terms on it (7 days until they are set) unless `daysUntilDue` says otherwise.  TAX. Stripe Tax works the tax out from the billing address on the profile, and a valid tax ID on it turns the tax of a business abroad into the reverse charge. The response says what the price, the tax and the total are. When Stripe cannot place the partner, the invoice is still issued, without tax, and `taxNote` says so. A tax ID Stripe does not accept is refused with 422 `TAX_ID_INVALID` before anything is issued.  CREDITS. This is how a partner gets credits: it pays an invoice for them. Give `credits` and the invoice is for that many Widgetic credits (priced at the list price of a credit unless `amountUsd` is given). They are added to the account of the partner\'s administrator, where the partner\'s builds are charged, when the invoice is paid, whether the partner pays it or an administrator records a payment received outside Stripe, and once per invoice however often Stripe reports the payment. Nothing is added while the invoice is open, void or uncollectible. There is no cap of ours: the invoice is the limit (Stripe\'s own limits on the amount of a payment still apply). An invoice issued without `credits` adds none, whatever its price. A partner with no administrator account cannot be invoiced for credits (422 `NO_PARTNER_ADMINISTRATOR`).  The invoice is recorded in the partner\'s invoice list (`getInvoicesByPartnerId`) as `open`, and follows what Stripe reports from then on: `failed` (with the reason) when a payment fails, `paid` when it is paid (also when an administrator records a payment received outside Stripe), `void` when it is voided and `uncollectible` when it is written off. Nobody has to update a status by hand.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per invoice you mean to send, and a new key for the next one.  Every invoice issued is written to the billing audit log under the administrator who issued it.
      * Issue a contract invoice to a partner
      */
     issuePartnerInvoice(requestParameters, initOverrides) {

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

@@ -10,7 +10,7 @@
  * Do not edit the class manually.
  */
 import * as runtime from '../runtime';
-import type { BillingPricingGet200Response, BillingUsersUserIdInvoicesGet200Response, BillingUsersUserIdPaymentMethodsPaymentMethodIdDefaultPut200Response, BillingUsersUserIdPortalPostRequest, BillingUsersUserIdSubscriptionCancelPost200Response, BillingUsersUserIdSubscriptionCancelPostRequest, BillingUsersUserIdSubscriptionGet200Response, BillingUsersUserIdSubscriptionPayPost200Response, BillingUsersUserIdSubscriptionPost200Response, BillingUsersUserIdSubscriptionPostRequest, OrganizationsOrgIdBillingPaymentMethodsGet200Response, OrganizationsOrgIdBillingPaymentMethodsPost200Response, OrganizationsOrgIdBillingPaymentMethodsPostRequest, OrganizationsOrgIdBillingPaymentMethodsSetupIntentPost200Response, OrganizationsOrgIdBillingPortalPost200Response, UploadsIdDelete200Response } from '../models/index';
+import type { BillingPricingGet200Response, BillingUsersUserIdInvoicesGet200Response, BillingUsersUserIdPaymentMethodsPaymentMethodIdDefaultPut200Response, BillingUsersUserIdPortalPostRequest, BillingUsersUserIdStorageCancelPackPostRequest, BillingUsersUserIdStorageGet200Response, BillingUsersUserIdSubscriptionCancelPost200Response, BillingUsersUserIdSubscriptionCancelPostRequest, BillingUsersUserIdSubscriptionGet200Response, BillingUsersUserIdSubscriptionPayPost200Response, BillingUsersUserIdSubscriptionPost200Response, BillingUsersUserIdSubscriptionPostRequest, OrganizationsOrgIdBillingPaymentMethodsGet200Response, OrganizationsOrgIdBillingPaymentMethodsPost200Response, OrganizationsOrgIdBillingPaymentMethodsPostRequest, OrganizationsOrgIdBillingPaymentMethodsSetupIntentPost200Response, OrganizationsOrgIdBillingPortalPost200Response, PurchaseStoragePack200Response, PurchaseStoragePackRequest, UploadsIdDelete200Response } from '../models/index';
 export interface BillingUsersUserIdInvoicesGetRequest {
     userId: string;
     limit?: number;
@@ -40,6 +40,19 @@ export interface BillingUsersUserIdPortalPostOperationRequest {
     idempotencyKey?: string;
     billingUsersUserIdPortalPostRequest?: BillingUsersUserIdPortalPostRequest;
 }
+export interface BillingUsersUserIdStorageCancelPackPostOperationRequest {
+    userId: string;
+    billingUsersUserIdStorageCancelPackPostRequest: BillingUsersUserIdStorageCancelPackPostRequest;
+    idempotencyKey?: string;
+}
+export interface BillingUsersUserIdStorageGetRequest {
+    userId: string;
+}
+export interface BillingUsersUserIdStoragePurchasePackPostRequest {
+    userId: string;
+    purchaseStoragePackRequest: PurchaseStoragePackRequest;
+    idempotencyKey?: string;
+}
 export interface BillingUsersUserIdSubscriptionCancelPostOperationRequest {
     userId: string;
     idempotencyKey?: string;
@@ -129,6 +142,36 @@ export declare class BillingApi extends runtime.BaseAPI {
      * Create a Stripe billing portal session for managing cards and invoices
      */
     billingUsersUserIdPortalPost(requestParameters: BillingUsersUserIdPortalPostOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<OrganizationsOrgIdBillingPortalPost200Response>;
+    /**
+     * Gives back extra storage: removes `pack_size_gb` GB from the person\'s storage add-on, or all of it with `remove_all`. The add-on stops billing for the GB removed; what was already paid for the rest of the current period is credited on the next invoice.  Removing storage does not delete files. A person who holds more than their limit afterwards can read and delete what they have but cannot upload until they are back under the limit.  Send either `pack_size_gb` or `remove_all: true`, not both. The `Idempotency-Key` header is required and names this change: a retry with the same key replays the first result.  Removing is allowed on an overdue subscription and on one that ends with the period, so a person is never stuck paying for storage they want to drop. Users can only change their own storage.
+     * Remove Extra Storage from Your Own Storage
+     */
+    billingUsersUserIdStorageCancelPackPostRaw(requestParameters: BillingUsersUserIdStorageCancelPackPostOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PurchaseStoragePack200Response>>;
+    /**
+     * Gives back extra storage: removes `pack_size_gb` GB from the person\'s storage add-on, or all of it with `remove_all`. The add-on stops billing for the GB removed; what was already paid for the rest of the current period is credited on the next invoice.  Removing storage does not delete files. A person who holds more than their limit afterwards can read and delete what they have but cannot upload until they are back under the limit.  Send either `pack_size_gb` or `remove_all: true`, not both. The `Idempotency-Key` header is required and names this change: a retry with the same key replays the first result.  Removing is allowed on an overdue subscription and on one that ends with the period, so a person is never stuck paying for storage they want to drop. Users can only change their own storage.
+     * Remove Extra Storage from Your Own Storage
+     */
+    billingUsersUserIdStorageCancelPackPost(requestParameters: BillingUsersUserIdStorageCancelPackPostOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PurchaseStoragePack200Response>;
+    /**
+     * Returns a person\'s own storage and the extra storage they can add to it on Solo, in one call: the limit the upload check holds their own workspace to (plan plus extra storage), what they have stored, the extra storage they hold (one row per storage item on the subscription) and what it costs per billing period, and whether storage can be added or removed right now (`extraStorage.canAdd` and `extraStorage.canRemove`) with the reason when it cannot (`extraStorage.addBlockedReason`; its codes are the ones the purchase request answers with). A partner account is never offered extra storage (`PARTNER_STORAGE_NOT_SOLD`): its files are kept in its own storage destination.  This is the person\'s OWN workspace. The storage of a team they belong to is the team\'s pool, read with `GET /organizations/{orgId}/storage/usage`; extra storage bought here does not add to it.  Users can only read their own storage; internal callers can read anyone\'s.
+     * Get Your Own Storage and Extra Storage
+     */
+    billingUsersUserIdStorageGetRaw(requestParameters: BillingUsersUserIdStorageGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<BillingUsersUserIdStorageGet200Response>>;
+    /**
+     * Returns a person\'s own storage and the extra storage they can add to it on Solo, in one call: the limit the upload check holds their own workspace to (plan plus extra storage), what they have stored, the extra storage they hold (one row per storage item on the subscription) and what it costs per billing period, and whether storage can be added or removed right now (`extraStorage.canAdd` and `extraStorage.canRemove`) with the reason when it cannot (`extraStorage.addBlockedReason`; its codes are the ones the purchase request answers with). A partner account is never offered extra storage (`PARTNER_STORAGE_NOT_SOLD`): its files are kept in its own storage destination.  This is the person\'s OWN workspace. The storage of a team they belong to is the team\'s pool, read with `GET /organizations/{orgId}/storage/usage`; extra storage bought here does not add to it.  Users can only read their own storage; internal callers can read anyone\'s.
+     * Get Your Own Storage and Extra Storage
+     */
+    billingUsersUserIdStorageGet(requestParameters: BillingUsersUserIdStorageGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<BillingUsersUserIdStorageGet200Response>;
+    /**
+     * Adds extra storage to the person\'s own Solo subscription. Extra storage is a RECURRING add-on, not a one-time purchase: it is one more item on the same subscription as the plan, billed every period (per GB per month on a monthly subscription, per GB per year on a yearly one) until it is removed or the subscription ends.  The GB are charged now, prorated for the rest of the current period, to the subscription\'s payment method, and join the person\'s own storage as soon as the charge succeeds. If the charge fails (for example a declined card) nothing is added and the request is refused with 402 `PAYMENT_FAILED`.  Storage is sold in packs (the pricing payload\'s `storage.defaultPackSizeGb`, 50 GB). Ask for as many packs as you need in one request by sending a multiple of the pack size: `pack_size_gb: 50` is one pack, `100` is two, `500` is ten. `pack_size_gb` is added to what the person already has, so buying again adds more. Remove storage with `POST /billing/users/{userId}/storage/cancel-pack`.  The extra storage adds to the person\'s OWN workspace only. It is not shared with a team the person belongs to: a team\'s storage is the team\'s pool, and its admins buy storage for it.  The `Idempotency-Key` header is required and names this change: a retry with the same key replays the first result instead of adding the storage twice. A refused request gives the key back: after a declined card (402 `PAYMENT_FAILED`), fix the payment method and send the request again with the same key. It is charged as a new attempt and is not answered with the old decline.  Only a Solo subscription that Stripe bills and that is active can have extra storage. During the free trial the request is refused with 409 `TRIAL_NOT_ENDED` (storage added then would be free until the trial ends); a person with no Solo subscription is refused with a plan restriction pointing at Solo, and the owner account of a Shopify store (whose plan Shopify bills) with 409 `BILLED_THROUGH_SHOPIFY`. Users can only change their own storage.  Extra storage is not sold to an account that administers a partner (403 `PARTNER_STORAGE_NOT_SOLD`): the files of a partner account are kept in the partner\'s own storage destination and never use Widgetic storage, so there would be nothing for the storage to add to. Giving storage back stays open to such an account.
+     * Add Extra Storage to Your Own Storage
+     */
+    billingUsersUserIdStoragePurchasePackPostRaw(requestParameters: BillingUsersUserIdStoragePurchasePackPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PurchaseStoragePack200Response>>;
+    /**
+     * Adds extra storage to the person\'s own Solo subscription. Extra storage is a RECURRING add-on, not a one-time purchase: it is one more item on the same subscription as the plan, billed every period (per GB per month on a monthly subscription, per GB per year on a yearly one) until it is removed or the subscription ends.  The GB are charged now, prorated for the rest of the current period, to the subscription\'s payment method, and join the person\'s own storage as soon as the charge succeeds. If the charge fails (for example a declined card) nothing is added and the request is refused with 402 `PAYMENT_FAILED`.  Storage is sold in packs (the pricing payload\'s `storage.defaultPackSizeGb`, 50 GB). Ask for as many packs as you need in one request by sending a multiple of the pack size: `pack_size_gb: 50` is one pack, `100` is two, `500` is ten. `pack_size_gb` is added to what the person already has, so buying again adds more. Remove storage with `POST /billing/users/{userId}/storage/cancel-pack`.  The extra storage adds to the person\'s OWN workspace only. It is not shared with a team the person belongs to: a team\'s storage is the team\'s pool, and its admins buy storage for it.  The `Idempotency-Key` header is required and names this change: a retry with the same key replays the first result instead of adding the storage twice. A refused request gives the key back: after a declined card (402 `PAYMENT_FAILED`), fix the payment method and send the request again with the same key. It is charged as a new attempt and is not answered with the old decline.  Only a Solo subscription that Stripe bills and that is active can have extra storage. During the free trial the request is refused with 409 `TRIAL_NOT_ENDED` (storage added then would be free until the trial ends); a person with no Solo subscription is refused with a plan restriction pointing at Solo, and the owner account of a Shopify store (whose plan Shopify bills) with 409 `BILLED_THROUGH_SHOPIFY`. Users can only change their own storage.  Extra storage is not sold to an account that administers a partner (403 `PARTNER_STORAGE_NOT_SOLD`): the files of a partner account are kept in the partner\'s own storage destination and never use Widgetic storage, so there would be nothing for the storage to add to. Giving storage back stays open to such an account.
+     * Add Extra Storage to Your Own Storage
+     */
+    billingUsersUserIdStoragePurchasePackPost(requestParameters: BillingUsersUserIdStoragePurchasePackPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PurchaseStoragePack200Response>;
     /**
      * Cancel the active subscription
      */