@widgetic/api-sdk 1.0.32 → 1.0.33

package/dist/apis/UsersApi.js

@@ -30,7 +30,7 @@ const index_1 = require("../models/index");
  */
 class UsersApi extends runtime.BaseAPI {
     /**
-     * Adds a website to an account\'s own list. Give a website name such as `example.com`, or `*.example.com` for a website and all of its subdomains. A scheme, a port, a path, capital letters and a leading `www.` are dropped, so `https://www.Example.com/shop` is kept as `example.com`, and `example.com` covers `www.example.com` too. Something that is not a website name is refused, not stored. Until the first website is added nothing is restricted, and a widget can be shown anywhere. Once the list has one, a widget of the account is shown on the listed websites (and on Widgetic\'s own) and nowhere else. A page on your own machine (`localhost`, `127.0.0.1` or `[::1]`, on any port) is always allowed, so there is nothing to add to test locally. A change can take about 15 seconds to reach every server. The list is a safeguard against other websites showing your widgets in a visitor\'s browser. It is not access control: anyone who knows a widget\'s id can still fetch its published content with a plain request that names no website. An account can list at most 50 websites. Use `*.example.com` for a website and all of its subdomains instead of listing each one.
+     * Adds a website to an account\'s own list. Give a website name such as `example.com`, or `*.example.com` for a website and all of its subdomains. A scheme, a port, a path, capital letters and a leading `www.` are dropped, so `https://www.Example.com/shop` is kept as `example.com`, and `example.com` covers `www.example.com` too. Something that is not a website name is refused, not stored. Until the first website is added nothing is restricted, and a widget can be shown anywhere. Once the list has one, a widget of the account is shown on the listed websites (and on Widgetic\'s own) and nowhere else. A page on your own machine (`localhost`, `127.0.0.1` or `[::1]`, on any port) is always allowed, so there is nothing to add to test locally. So is the website where a partner your account administers integrates Widgetic, with every subdomain of it (`platformDomain` in the answer of `GET /partners/mine`), so there is nothing to add for it either and a list can never lock it out. A change can take about 15 seconds to reach every server. The list is a safeguard against other websites showing your widgets in a visitor\'s browser. It is not access control: anyone who knows a widget\'s id can still fetch its published content with a plain request that names no website. An account can list at most 50 websites. Use `*.example.com` for a website and all of its subdomains instead of listing each one.
      * Allow a website to show your widgets
      */
     addPersonalWorkspaceDomainRaw(requestParameters, initOverrides) {
@@ -62,7 +62,7 @@ class UsersApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Adds a website to an account\'s own list. Give a website name such as `example.com`, or `*.example.com` for a website and all of its subdomains. A scheme, a port, a path, capital letters and a leading `www.` are dropped, so `https://www.Example.com/shop` is kept as `example.com`, and `example.com` covers `www.example.com` too. Something that is not a website name is refused, not stored. Until the first website is added nothing is restricted, and a widget can be shown anywhere. Once the list has one, a widget of the account is shown on the listed websites (and on Widgetic\'s own) and nowhere else. A page on your own machine (`localhost`, `127.0.0.1` or `[::1]`, on any port) is always allowed, so there is nothing to add to test locally. A change can take about 15 seconds to reach every server. The list is a safeguard against other websites showing your widgets in a visitor\'s browser. It is not access control: anyone who knows a widget\'s id can still fetch its published content with a plain request that names no website. An account can list at most 50 websites. Use `*.example.com` for a website and all of its subdomains instead of listing each one.
+     * Adds a website to an account\'s own list. Give a website name such as `example.com`, or `*.example.com` for a website and all of its subdomains. A scheme, a port, a path, capital letters and a leading `www.` are dropped, so `https://www.Example.com/shop` is kept as `example.com`, and `example.com` covers `www.example.com` too. Something that is not a website name is refused, not stored. Until the first website is added nothing is restricted, and a widget can be shown anywhere. Once the list has one, a widget of the account is shown on the listed websites (and on Widgetic\'s own) and nowhere else. A page on your own machine (`localhost`, `127.0.0.1` or `[::1]`, on any port) is always allowed, so there is nothing to add to test locally. So is the website where a partner your account administers integrates Widgetic, with every subdomain of it (`platformDomain` in the answer of `GET /partners/mine`), so there is nothing to add for it either and a list can never lock it out. A change can take about 15 seconds to reach every server. The list is a safeguard against other websites showing your widgets in a visitor\'s browser. It is not access control: anyone who knows a widget\'s id can still fetch its published content with a plain request that names no website. An account can list at most 50 websites. Use `*.example.com` for a website and all of its subdomains instead of listing each one.
      * Allow a website to show your widgets
      */
     addPersonalWorkspaceDomain(requestParameters, initOverrides) {
@@ -72,7 +72,7 @@ class UsersApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Makes a new API key for an account and returns its secret in `key`. That is the only time the secret is shown: Widgetic keeps a hash, so a key that was not stored cannot be recovered, only replaced. To rotate a key, make the new one, switch the integration over to it, then delete the old one. Only a person signed in on widgetic.com can make a key: a request made with an API key, or with an SDK token, is refused with 403. That way a leaked key cannot be used to make a second one that survives its revocation. Make keys from the dashboard; a key can still list, rename, switch off and delete keys. An `Idempotency-Key` header is required (8 to 50 characters: letters, digits, `-` and `_`). A retry with the same header and the same body returns the same answer instead of making a second key, and the same header with a different body is refused with 422. Make keys one at a time: two requests for the same account that run at the same moment can overwrite each other. A key can be limited to what it needs. Send a `preset` (`read_only`, `content` or `full_access`) or a list of `scopes`, never both. Send neither for a key that can do everything its owner can, as every key made before scopes existed. A limited key is refused with 403 and the code `API_KEY_SCOPE_MISSING` on anything outside its scopes, so a key held by a build server or by a partner\'s backend can be given only the part of the API it uses. The scopes of a key are fixed when it is made: to widen one, make a new key and delete the old one. A limited key cannot make, change or delete keys, exchange tokens or reach the administration routes. The list of scopes is in the `ApiKeyScope` schema. An account can hold at most 25 keys. An account on a plan without API access cannot make one.
+     * Makes a new API key for an account and returns its secret in `key`. That is the only time the secret is shown: Widgetic keeps a hash, so a key that was not stored cannot be recovered, only replaced. To rotate a key, make the new one, switch the integration over to it, then delete the old one. Only a person signed in on widgetic.com can make a key: a request made with an API key, or with an SDK token, is refused with 403. That way a leaked key cannot be used to make a second one that survives its revocation. Make keys from the dashboard; a key can still list, rename, switch off and delete keys. An `Idempotency-Key` header is required (8 to 50 characters: letters, digits, `-` and `_`). A retry with the same header and the same body returns the same answer instead of making a second key, and the same header with a different body is refused with 422. Make keys one at a time: two requests for the same account that run at the same moment can overwrite each other. A key can be limited to what it needs. Send a `preset` (`read_only`, `content` or `full_access`) or a list of `scopes`, never both. Send neither for a key that can do everything its owner can, as every key made before scopes existed. A limited key is refused with 403 and the code `API_KEY_SCOPE_MISSING` on anything outside its scopes, so a key held by a build server or by a partner\'s backend can be given only the part of the API it uses. The scopes of a key are fixed when it is made: to widen one, make a new key and delete the old one. A limited key cannot make, change or delete keys, exchange tokens or reach the administration routes. The list of scopes is in the `ApiKeyScope` schema. An account can hold at most 25 keys, except a partner account, which has no limit: what a partner\'s keys do is paid for from its own credits, however many integrations it runs. An account on a plan without API access cannot make one (a partner account is not asked about a plan).
      * Create an API key
      */
     createUserApiKeyRaw(requestParameters, initOverrides) {
@@ -107,7 +107,7 @@ class UsersApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Makes a new API key for an account and returns its secret in `key`. That is the only time the secret is shown: Widgetic keeps a hash, so a key that was not stored cannot be recovered, only replaced. To rotate a key, make the new one, switch the integration over to it, then delete the old one. Only a person signed in on widgetic.com can make a key: a request made with an API key, or with an SDK token, is refused with 403. That way a leaked key cannot be used to make a second one that survives its revocation. Make keys from the dashboard; a key can still list, rename, switch off and delete keys. An `Idempotency-Key` header is required (8 to 50 characters: letters, digits, `-` and `_`). A retry with the same header and the same body returns the same answer instead of making a second key, and the same header with a different body is refused with 422. Make keys one at a time: two requests for the same account that run at the same moment can overwrite each other. A key can be limited to what it needs. Send a `preset` (`read_only`, `content` or `full_access`) or a list of `scopes`, never both. Send neither for a key that can do everything its owner can, as every key made before scopes existed. A limited key is refused with 403 and the code `API_KEY_SCOPE_MISSING` on anything outside its scopes, so a key held by a build server or by a partner\'s backend can be given only the part of the API it uses. The scopes of a key are fixed when it is made: to widen one, make a new key and delete the old one. A limited key cannot make, change or delete keys, exchange tokens or reach the administration routes. The list of scopes is in the `ApiKeyScope` schema. An account can hold at most 25 keys. An account on a plan without API access cannot make one.
+     * Makes a new API key for an account and returns its secret in `key`. That is the only time the secret is shown: Widgetic keeps a hash, so a key that was not stored cannot be recovered, only replaced. To rotate a key, make the new one, switch the integration over to it, then delete the old one. Only a person signed in on widgetic.com can make a key: a request made with an API key, or with an SDK token, is refused with 403. That way a leaked key cannot be used to make a second one that survives its revocation. Make keys from the dashboard; a key can still list, rename, switch off and delete keys. An `Idempotency-Key` header is required (8 to 50 characters: letters, digits, `-` and `_`). A retry with the same header and the same body returns the same answer instead of making a second key, and the same header with a different body is refused with 422. Make keys one at a time: two requests for the same account that run at the same moment can overwrite each other. A key can be limited to what it needs. Send a `preset` (`read_only`, `content` or `full_access`) or a list of `scopes`, never both. Send neither for a key that can do everything its owner can, as every key made before scopes existed. A limited key is refused with 403 and the code `API_KEY_SCOPE_MISSING` on anything outside its scopes, so a key held by a build server or by a partner\'s backend can be given only the part of the API it uses. The scopes of a key are fixed when it is made: to widen one, make a new key and delete the old one. A limited key cannot make, change or delete keys, exchange tokens or reach the administration routes. The list of scopes is in the `ApiKeyScope` schema. An account can hold at most 25 keys, except a partner account, which has no limit: what a partner\'s keys do is paid for from its own credits, however many integrations it runs. An account on a plan without API access cannot make one (a partner account is not asked about a plan).
      * Create an API key
      */
     createUserApiKey(requestParameters, initOverrides) {

package/dist/apis/WorkflowsApi.d.ts

@@ -0,0 +1,44 @@
+/**
+ * Widgetic API Gateway
+ * API documentation for the Widgetic API Gateway
+ *
+ * The version of the OpenAPI document: 1.0.0
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import * as runtime from '../runtime';
+import type { GenerateComponentWorkflowInput, GenerateMixedComponentInput, WorkflowAcceptedResponse } from '../models/index';
+export interface WorkflowsGenerateComponentFromMixPostRequest {
+    generateMixedComponentInput: GenerateMixedComponentInput;
+}
+export interface WorkflowsGenerateComponentPostRequest {
+    generateComponentWorkflowInput: GenerateComponentWorkflowInput;
+}
+/**
+ *
+ */
+export declare class WorkflowsApi extends runtime.BaseAPI {
+    /**
+     * Initiates an asynchronous workflow to create a new component based on instructions applied to one or more source components.
+     * Generate a New Component by Mixing Existing Ones
+     */
+    workflowsGenerateComponentFromMixPostRaw(requestParameters: WorkflowsGenerateComponentFromMixPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowAcceptedResponse>>;
+    /**
+     * Initiates an asynchronous workflow to create a new component based on instructions applied to one or more source components.
+     * Generate a New Component by Mixing Existing Ones
+     */
+    workflowsGenerateComponentFromMixPost(requestParameters: WorkflowsGenerateComponentFromMixPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowAcceptedResponse>;
+    /**
+     * Starts the end-to-end workflow for generating a new component based on initial user requirements. This involves creating a development plan via Task Master, and then executing the plan\'s tasks  using Aider for code generation. The process runs asynchronously, and progress should be  monitored via WebSockets.
+     * Initiate initial component generation workflow
+     */
+    workflowsGenerateComponentPostRaw(requestParameters: WorkflowsGenerateComponentPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowAcceptedResponse>>;
+    /**
+     * Starts the end-to-end workflow for generating a new component based on initial user requirements. This involves creating a development plan via Task Master, and then executing the plan\'s tasks  using Aider for code generation. The process runs asynchronously, and progress should be  monitored via WebSockets.
+     * Initiate initial component generation workflow
+     */
+    workflowsGenerateComponentPost(requestParameters: WorkflowsGenerateComponentPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowAcceptedResponse>;
+}

package/dist/apis/WorkflowsApi.js

@@ -0,0 +1,111 @@
+"use strict";
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * Widgetic API Gateway
+ * API documentation for the Widgetic API Gateway
+ *
+ * The version of the OpenAPI document: 1.0.0
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
+    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
+    return new (P || (P = Promise))(function (resolve, reject) {
+        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
+        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
+        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
+        step((generator = generator.apply(thisArg, _arguments || [])).next());
+    });
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.WorkflowsApi = void 0;
+const runtime = require("../runtime");
+const index_1 = require("../models/index");
+/**
+ *
+ */
+class WorkflowsApi extends runtime.BaseAPI {
+    /**
+     * Initiates an asynchronous workflow to create a new component based on instructions applied to one or more source components.
+     * Generate a New Component by Mixing Existing Ones
+     */
+    workflowsGenerateComponentFromMixPostRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['generateMixedComponentInput'] == null) {
+                throw new runtime.RequiredError('generateMixedComponentInput', 'Required parameter "generateMixedComponentInput" was null or undefined when calling workflowsGenerateComponentFromMixPost().');
+            }
+            const queryParameters = {};
+            const headerParameters = {};
+            headerParameters['Content-Type'] = 'application/json';
+            if (this.configuration && this.configuration.accessToken) {
+                const token = this.configuration.accessToken;
+                const tokenString = yield token("bearerAuth", []);
+                if (tokenString) {
+                    headerParameters["Authorization"] = `Bearer ${tokenString}`;
+                }
+            }
+            const response = yield this.request({
+                path: `/workflows/generate-component-from-mix`,
+                method: 'POST',
+                headers: headerParameters,
+                query: queryParameters,
+                body: (0, index_1.GenerateMixedComponentInputToJSON)(requestParameters['generateMixedComponentInput']),
+            }, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.WorkflowAcceptedResponseFromJSON)(jsonValue));
+        });
+    }
+    /**
+     * Initiates an asynchronous workflow to create a new component based on instructions applied to one or more source components.
+     * Generate a New Component by Mixing Existing Ones
+     */
+    workflowsGenerateComponentFromMixPost(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.workflowsGenerateComponentFromMixPostRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
+    /**
+     * Starts the end-to-end workflow for generating a new component based on initial user requirements. This involves creating a development plan via Task Master, and then executing the plan\'s tasks  using Aider for code generation. The process runs asynchronously, and progress should be  monitored via WebSockets.
+     * Initiate initial component generation workflow
+     */
+    workflowsGenerateComponentPostRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['generateComponentWorkflowInput'] == null) {
+                throw new runtime.RequiredError('generateComponentWorkflowInput', 'Required parameter "generateComponentWorkflowInput" was null or undefined when calling workflowsGenerateComponentPost().');
+            }
+            const queryParameters = {};
+            const headerParameters = {};
+            headerParameters['Content-Type'] = 'application/json';
+            if (this.configuration && this.configuration.accessToken) {
+                const token = this.configuration.accessToken;
+                const tokenString = yield token("bearerAuth", []);
+                if (tokenString) {
+                    headerParameters["Authorization"] = `Bearer ${tokenString}`;
+                }
+            }
+            const response = yield this.request({
+                path: `/workflows/generate-component`,
+                method: 'POST',
+                headers: headerParameters,
+                query: queryParameters,
+                body: (0, index_1.GenerateComponentWorkflowInputToJSON)(requestParameters['generateComponentWorkflowInput']),
+            }, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.WorkflowAcceptedResponseFromJSON)(jsonValue));
+        });
+    }
+    /**
+     * Starts the end-to-end workflow for generating a new component based on initial user requirements. This involves creating a development plan via Task Master, and then executing the plan\'s tasks  using Aider for code generation. The process runs asynchronously, and progress should be  monitored via WebSockets.
+     * Initiate initial component generation workflow
+     */
+    workflowsGenerateComponentPost(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.workflowsGenerateComponentPostRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
+}
+exports.WorkflowsApi = WorkflowsApi;

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

@@ -10,12 +10,7 @@
  * Do not edit the class manually.
  */
 import * as runtime from '../runtime';
-import type { AdjustPartnerCredits200Response, AdjustPartnerCreditsRequest, AdjustUserCredits200Response, AdjustUserCreditsRequest, AdminHealthStatus, CleanupOrphanedInvitations200Response, CleanupOrphanedInvitationsRequest, CreatePartnerRequest, PartnerActivation, PartnerBillingProfileSaved, PartnerBillingProfileView, PartnerBillingReport, PartnerDetails, PartnerEditorSessionSettings, PartnerList, PartnerUpdateResult, PartnerWithWarnings, RecordPartnerInvoicePaymentRequest, RecordedPartnerPayment, RefundPartnerCreditsRequest, UpdatePartnerBillingProfileRequest, UpdatePartnerEditorSessionSettingsRequest, UpdatePartnerRequest, UpdatePartnerStatusRequest } from '../models/index';
-export interface AdjustPartnerCreditsOperationRequest {
-    partnerId: string;
-    adjustPartnerCreditsRequest: AdjustPartnerCreditsRequest;
-    idempotencyKey?: string;
-}
+import type { AdjustUserCredits200Response, AdjustUserCreditsRequest, AdminHealthStatus, CleanupOrphanedInvitations200Response, CleanupOrphanedInvitationsRequest, CreatePartnerRequest, PartnerActivation, PartnerBillingProfileSaved, PartnerBillingProfileView, PartnerBillingReport, PartnerDetails, PartnerEditorSessionSettings, PartnerInvoiceSchedule, PartnerList, PartnerUpdateResult, PartnerWithWarnings, RecordPartnerInvoicePaymentRequest, RecordedPartnerPayment, UpdatePartnerBillingProfileRequest, UpdatePartnerEditorSessionSettingsRequest, UpdatePartnerRequest, UpdatePartnerStatusRequest } from '../models/index';
 export interface AdjustUserCreditsOperationRequest {
     adjustUserCreditsRequest: AdjustUserCreditsRequest;
     idempotencyKey?: string;
@@ -49,6 +44,9 @@ export interface GetPartnerDetailsRequest {
 export interface GetPartnerEditorSessionSettingsRequest {
     partnerId: string;
 }
+export interface GetPartnerInvoiceScheduleRequest {
+    partnerId: string;
+}
 export interface ListAdminWidgetsRequest {
     scope?: ListAdminWidgetsScopeEnum;
     preset?: ListAdminWidgetsPresetEnum;
@@ -69,10 +67,6 @@ export interface RecordPartnerInvoicePaymentOperationRequest {
     idempotencyKey?: string;
     recordPartnerInvoicePaymentRequest?: RecordPartnerInvoicePaymentRequest;
 }
-export interface RefundPartnerCreditsOperationRequest {
-    refundPartnerCreditsRequest: RefundPartnerCreditsRequest;
-    idempotencyKey?: string;
-}
 export interface UpdatePartnerOperationRequest {
     partnerId: string;
     updatePartnerRequest: UpdatePartnerRequest;
@@ -95,22 +89,12 @@ export interface UpdatePartnerStatusOperationRequest {
  */
 export declare 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: AdjustPartnerCreditsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<AdjustPartnerCredits200Response>>;
-    /**
-     * 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: AdjustPartnerCreditsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<AdjustPartnerCredits200Response>;
-    /**
-     * 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: AdjustUserCreditsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<AdjustUserCredits200Response>>;
     /**
-     * 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: AdjustUserCreditsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<AdjustUserCredits200Response>;
@@ -135,12 +119,12 @@ export declare class AdminApi extends runtime.BaseAPI {
      */
     cleanupOrphanedInvitations(requestParameters?: CleanupOrphanedInvitations0Request, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<CleanupOrphanedInvitations200Response>;
     /**
-     * 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: CreatePartnerOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerWithWarnings>>;
     /**
-     * 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: CreatePartnerOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerWithWarnings>;
@@ -165,12 +149,12 @@ export declare class AdminApi extends runtime.BaseAPI {
      */
     getPartnerActivation(requestParameters: GetPartnerActivationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerActivation>;
     /**
-     * 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: GetPartnerBillingProfileRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerBillingProfileView>>;
     /**
-     * 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: GetPartnerBillingProfileRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerBillingProfileView>;
@@ -185,12 +169,12 @@ export declare class AdminApi extends runtime.BaseAPI {
      */
     getPartnerBillingReport(requestParameters: GetPartnerBillingReportRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerBillingReport>;
     /**
-     * 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: GetPartnerDetailsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerDetails>>;
     /**
-     * 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: GetPartnerDetailsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerDetails>;
@@ -204,6 +188,16 @@ export declare class AdminApi extends runtime.BaseAPI {
      * What is set for a partner\'s editor sessions
      */
     getPartnerEditorSessionSettings(requestParameters: GetPartnerEditorSessionSettingsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerEditorSessionSettings>;
+    /**
+     * 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: GetPartnerInvoiceScheduleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerInvoiceSchedule>>;
+    /**
+     * 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: GetPartnerInvoiceScheduleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerInvoiceSchedule>;
     /**
      * 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
@@ -225,33 +219,23 @@ export declare class AdminApi extends runtime.BaseAPI {
      */
     listPartners(requestParameters?: ListPartnersRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerList>;
     /**
-     * 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: RecordPartnerInvoicePaymentOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RecordedPartnerPayment>>;
     /**
-     * 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: RecordPartnerInvoicePaymentOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RecordedPartnerPayment>;
     /**
-     * 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: RefundPartnerCreditsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<void>>;
-    /**
-     * 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: RefundPartnerCreditsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<void>;
-    /**
-     * 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: UpdatePartnerOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerUpdateResult>>;
     /**
-     * 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: UpdatePartnerOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerUpdateResult>;
     /**
@@ -275,12 +259,12 @@ export declare class AdminApi extends runtime.BaseAPI {
      */
     updatePartnerEditorSessionSettings(requestParameters: UpdatePartnerEditorSessionSettingsOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerEditorSessionSettings>;
     /**
-     * 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: UpdatePartnerStatusOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerWithWarnings>>;
     /**
-     * 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: UpdatePartnerStatusOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerWithWarnings>;