@widgetic/api-sdk 1.0.25 → 1.0.26

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();
+        });
+    }
+    /**
+     * Retired workflow route. Live codegen is POST /agent/code/generate (Direct LLM).
+     * 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));
+        });
+    }
+    /**
+     * Retired workflow route. Live codegen is POST /agent/code/generate (Direct LLM).
+     * 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,7 +10,7 @@
  * Do not edit the class manually.
  */
 import * as runtime from '../runtime';
-import type { AdjustPartnerCredits200Response, AdjustPartnerCreditsRequest, AdjustUserCredits200Response, AdjustUserCreditsRequest, AdminHealthStatus, CleanupOrphanedInvitations200Response, CleanupOrphanedInvitationsRequest, CreatePartnerRequest, PartnerBillingReport, PartnerDetails, PartnerList, PartnerUpdateResult, PartnerWithWarnings, RefundPartnerCreditsRequest, UpdatePartnerRequest, UpdatePartnerStatusRequest } from '../models/index';
+import type { AdjustPartnerCredits200Response, AdjustPartnerCreditsRequest, AdjustUserCredits200Response, AdjustUserCreditsRequest, AdminHealthStatus, CleanupOrphanedInvitations200Response, CleanupOrphanedInvitationsRequest, CreatePartnerRequest, PartnerActivation, PartnerBillingReport, PartnerDetails, PartnerList, PartnerUpdateResult, PartnerWithWarnings, RefundPartnerCreditsRequest, UpdatePartnerRequest, UpdatePartnerStatusRequest } from '../models/index';
 export interface AdjustPartnerCreditsOperationRequest {
     partnerId: string;
     idempotencyKey: string;
@@ -31,6 +31,9 @@ export interface CleanupOrphanedInvitations0Request {
 export interface CreatePartnerOperationRequest {
     createPartnerRequest: CreatePartnerRequest;
 }
+export interface GetPartnerActivationRequest {
+    partnerId: string;
+}
 export interface GetPartnerBillingReportRequest {
     partnerId: string;
     startDate?: Date;
@@ -112,12 +115,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 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 without it the administrator\'s account looks like a free one and the pages it published stop being served after the free plan\'s seven days. 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. Suspending or deactivating the partner stops those pages 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 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`).
      * 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 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 without it the administrator\'s account looks like a free one and the pages it published stop being served after the free plan\'s seven days. 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. Suspending or deactivating the partner stops those pages 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 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`).
      * Create a partner
      */
     createPartner(requestParameters: CreatePartnerOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerWithWarnings>;
@@ -131,6 +134,16 @@ export declare class AdminApi extends runtime.BaseAPI {
      * JEV decision rollup (admin)
      */
     getJevMetrics(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<object>;
+    /**
+     * Admin only. The checklist `PUT /admin/partners/{partnerId}/status` applies when a partner that was never activated is switched on: a contract in force today (`contract`) and a storage destination that was verified and still works (`storage`). Each entry says whether it is met and, when it is not, what to do. Nothing is changed by reading it, so the Partners screen can show it beside the Activate button. `required` is false for a partner that is active or paused: resuming a paused partner is never held up by the checklist. An unpaid invoice is not a requirement.
+     * What a partner needs before it can be activated
+     */
+    getPartnerActivationRaw(requestParameters: GetPartnerActivationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<PartnerActivation>>;
+    /**
+     * Admin only. The checklist `PUT /admin/partners/{partnerId}/status` applies when a partner that was never activated is switched on: a contract in force today (`contract`) and a storage destination that was verified and still works (`storage`). Each entry says whether it is met and, when it is not, what to do. Nothing is changed by reading it, so the Partners screen can show it beside the Activate button. `required` is false for a partner that is active or paused: resuming a paused partner is never held up by the checklist. An unpaid invoice is not a requirement.
+     * What a partner needs before it can be activated
+     */
+    getPartnerActivation(requestParameters: GetPartnerActivationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerActivation>;
     /**
      * Admin only. What the partner\'s wallet did over the period, from the ledger: the totals (credits consumed and credits issued, over every row of the period however many there are), the same totals per calendar month, and, when `includeTransactions` is true, the newest ledger rows themselves. The period is the last 30 days when `startDate` and `endDate` are not given. A date that is not a date, or a start after the end, is refused with 400. The list of rows is bounded (the newest 1,000 of the period, complete); `transactionsTruncated` says when the period holds more than the list shows. The totals are never cut.
      * Get a partner\'s wallet activity for a period
@@ -182,22 +195,22 @@ export declare class AdminApi extends runtime.BaseAPI {
      */
     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. To suspend a partner with a recorded reason, or to reinstate one so that everything a suspension 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.
+     * 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
      */
     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. To suspend a partner with a recorded reason, or to reinstate one so that everything a suspension 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.
+     * 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
      */
     updatePartner(requestParameters: UpdatePartnerOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerUpdateResult>;
     /**
-     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` reinstates the partner: it is switched on, and a suspension\'s reason and time are cleared.   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` switches the partner off and records `reason` (default `Suspended by admin`) and the time. While a partner is not `active` what it published is not served: the pages and embeds published under its administrator\'s account (the account whose own API key calls the API for the partner) stop being rendered, which is what \"embeds stop if unpaid\" means. Reinstating the partner restores them. 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,   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.
      * 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` reinstates the partner: it is switched on, and a suspension\'s reason and time are cleared.   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` switches the partner off and records `reason` (default `Suspended by admin`) and the time. While a partner is not `active` what it published is not served: the pages and embeds published under its administrator\'s account (the account whose own API key calls the API for the partner) stop being rendered, which is what \"embeds stop if unpaid\" means. Reinstating the partner restores them. 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,   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.
      * Activate, deactivate or suspend a partner
      */
     updatePartnerStatus(requestParameters: UpdatePartnerStatusOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<PartnerWithWarnings>;

package/dist/esm/apis/AdminApi.js

@@ -21,7 +21,7 @@ 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, PartnerBillingReportFromJSON, PartnerDetailsFromJSON, PartnerListFromJSON, PartnerUpdateResultFromJSON, PartnerWithWarningsFromJSON, RefundPartnerCreditsRequestToJSON, UpdatePartnerRequestToJSON, UpdatePartnerStatusRequestToJSON, } from '../models/index.js';
+import { AdjustPartnerCredits200ResponseFromJSON, AdjustPartnerCreditsRequestToJSON, AdjustUserCredits200ResponseFromJSON, AdjustUserCreditsRequestToJSON, AdminHealthStatusFromJSON, CleanupOrphanedInvitations200ResponseFromJSON, CleanupOrphanedInvitationsRequestToJSON, CreatePartnerRequestToJSON, PartnerActivationFromJSON, PartnerBillingReportFromJSON, PartnerDetailsFromJSON, PartnerListFromJSON, PartnerUpdateResultFromJSON, PartnerWithWarningsFromJSON, RefundPartnerCreditsRequestToJSON, UpdatePartnerRequestToJSON, UpdatePartnerStatusRequestToJSON, } from '../models/index.js';
 /**
  *
  */
@@ -199,7 +199,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 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 without it the administrator\'s account looks like a free one and the pages it published stop being served after the free plan\'s seven days. 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. Suspending or deactivating the partner stops those pages 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 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`).
      * Create a partner
      */
     createPartnerRaw(requestParameters, initOverrides) {
@@ -228,7 +228,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 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 without it the administrator\'s account looks like a free one and the pages it published stop being served after the free plan\'s seven days. 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. Suspending or deactivating the partner stops those pages 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 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`).
      * Create a partner
      */
     createPartner(requestParameters, initOverrides) {
@@ -271,6 +271,43 @@ export class AdminApi extends runtime.BaseAPI {
             return yield response.value();
         });
     }
+    /**
+     * Admin only. The checklist `PUT /admin/partners/{partnerId}/status` applies when a partner that was never activated is switched on: a contract in force today (`contract`) and a storage destination that was verified and still works (`storage`). Each entry says whether it is met and, when it is not, what to do. Nothing is changed by reading it, so the Partners screen can show it beside the Activate button. `required` is false for a partner that is active or paused: resuming a paused partner is never held up by the checklist. An unpaid invoice is not a requirement.
+     * What a partner needs before it can be activated
+     */
+    getPartnerActivationRaw(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 getPartnerActivation().');
+            }
+            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}/activation`.replace(`{${"partnerId"}}`, encodeURIComponent(String(requestParameters['partnerId']))),
+                method: 'GET',
+                headers: headerParameters,
+                query: queryParameters,
+            }, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => PartnerActivationFromJSON(jsonValue));
+        });
+    }
+    /**
+     * Admin only. The checklist `PUT /admin/partners/{partnerId}/status` applies when a partner that was never activated is switched on: a contract in force today (`contract`) and a storage destination that was verified and still works (`storage`). Each entry says whether it is met and, when it is not, what to do. Nothing is changed by reading it, so the Partners screen can show it beside the Activate button. `required` is false for a partner that is active or paused: resuming a paused partner is never held up by the checklist. An unpaid invoice is not a requirement.
+     * What a partner needs before it can be activated
+     */
+    getPartnerActivation(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.getPartnerActivationRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
     /**
      * Admin only. What the partner\'s wallet did over the period, from the ledger: the totals (credits consumed and credits issued, over every row of the period however many there are), the same totals per calendar month, and, when `includeTransactions` is true, the newest ledger rows themselves. The period is the last 30 days when `startDate` and `endDate` are not given. A date that is not a date, or a start after the end, is refused with 400. The list of rows is bounded (the newest 1,000 of the period, complete); `transactionsTruncated` says when the period holds more than the list shows. The totals are never cut.
      * Get a partner\'s wallet activity for a period
@@ -496,7 +533,7 @@ 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. To suspend a partner with a recorded reason, or to reinstate one so that everything a suspension 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.
+     * 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
      */
     updatePartnerRaw(requestParameters, initOverrides) {
@@ -531,7 +568,7 @@ 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. To suspend a partner with a recorded reason, or to reinstate one so that everything a suspension 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.
+     * 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
      */
     updatePartner(requestParameters, initOverrides) {
@@ -541,7 +578,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` reinstates the partner: it is switched on, and a suspension\'s reason and time are cleared.   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` switches the partner off and records `reason` (default `Suspended by admin`) and the time. While a partner is not `active` what it published is not served: the pages and embeds published under its administrator\'s account (the account whose own API key calls the API for the partner) stop being rendered, which is what \"embeds stop if unpaid\" means. Reinstating the partner restores them. 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,   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.
      * Activate, deactivate or suspend a partner
      */
     updatePartnerStatusRaw(requestParameters, initOverrides) {
@@ -573,7 +610,7 @@ export class AdminApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Admin only. Sets the partner\'s standing (the `status` field every partner response carries). - `active` reinstates the partner: it is switched on, and a suspension\'s reason and time are cleared.   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` switches the partner off and records `reason` (default `Suspended by admin`) and the time. While a partner is not `active` what it published is not served: the pages and embeds published under its administrator\'s account (the account whose own API key calls the API for the partner) stop being rendered, which is what \"embeds stop if unpaid\" means. Reinstating the partner restores them. 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,   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.
      * Activate, deactivate or suspend a partner
      */
     updatePartnerStatus(requestParameters, initOverrides) {

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

@@ -0,0 +1,32 @@
+/**
+ * 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 { AgentRepositoriesRepoIdSyncPost202Response, AgentRepositoriesRepoIdSyncPostRequest } from '../models/index';
+export interface AgentRepositoriesRepoIdSyncPostOperationRequest {
+    repoId: string;
+    agentRepositoriesRepoIdSyncPostRequest: AgentRepositoriesRepoIdSyncPostRequest;
+}
+/**
+ *
+ */
+export declare class AgentRepositoryManagementApi extends runtime.BaseAPI {
+    /**
+     * Initializes a file watcher for the specified repository path, enabling debounced synchronization of local changes to GitLab.
+     * Start watching repository for changes and sync
+     */
+    agentRepositoriesRepoIdSyncPostRaw(requestParameters: AgentRepositoriesRepoIdSyncPostOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<AgentRepositoriesRepoIdSyncPost202Response>>;
+    /**
+     * Initializes a file watcher for the specified repository path, enabling debounced synchronization of local changes to GitLab.
+     * Start watching repository for changes and sync
+     */
+    agentRepositoriesRepoIdSyncPost(requestParameters: AgentRepositoriesRepoIdSyncPostOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<AgentRepositoriesRepoIdSyncPost202Response>;
+}

package/dist/esm/apis/AgentRepositoryManagementApi.js

@@ -0,0 +1,71 @@
+/* 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());
+    });
+};
+import * as runtime from '../runtime.js';
+import { AgentRepositoriesRepoIdSyncPost202ResponseFromJSON, AgentRepositoriesRepoIdSyncPostRequestToJSON, } from '../models/index.js';
+/**
+ *
+ */
+export class AgentRepositoryManagementApi extends runtime.BaseAPI {
+    /**
+     * Initializes a file watcher for the specified repository path, enabling debounced synchronization of local changes to GitLab.
+     * Start watching repository for changes and sync
+     */
+    agentRepositoriesRepoIdSyncPostRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['repoId'] == null) {
+                throw new runtime.RequiredError('repoId', 'Required parameter "repoId" was null or undefined when calling agentRepositoriesRepoIdSyncPost().');
+            }
+            if (requestParameters['agentRepositoriesRepoIdSyncPostRequest'] == null) {
+                throw new runtime.RequiredError('agentRepositoriesRepoIdSyncPostRequest', 'Required parameter "agentRepositoriesRepoIdSyncPostRequest" was null or undefined when calling agentRepositoriesRepoIdSyncPost().');
+            }
+            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: `/agent/repositories/{repoId}/sync`.replace(`{${"repoId"}}`, encodeURIComponent(String(requestParameters['repoId']))),
+                method: 'POST',
+                headers: headerParameters,
+                query: queryParameters,
+                body: AgentRepositoriesRepoIdSyncPostRequestToJSON(requestParameters['agentRepositoriesRepoIdSyncPostRequest']),
+            }, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => AgentRepositoriesRepoIdSyncPost202ResponseFromJSON(jsonValue));
+        });
+    }
+    /**
+     * Initializes a file watcher for the specified repository path, enabling debounced synchronization of local changes to GitLab.
+     * Start watching repository for changes and sync
+     */
+    agentRepositoriesRepoIdSyncPost(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.agentRepositoriesRepoIdSyncPostRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
+}

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

@@ -94,12 +94,12 @@ export declare class ManagedUsersApi extends runtime.BaseAPI {
      */
     createManagedUser(requestParameters: CreateManagedUserRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ManagedUser>;
     /**
-     * Makes a short-lived credential that lets the browser of ONE of your managed users use Widgetic\'s editor pieces, such as the File Browser and the composition editor, without your API key ever reaching that browser. Call this from your server when the page that hosts the editor opens, and hand the `token` in the answer to that page.  The token is shown once. It starts with `wgt_ses_` and the browser sends it as `Authorization: Bearer <token>`. It can do only what the `surfaces` you name allow, and only for this managed user:  - `files`: upload a file (`uploadsPost`) and list the files uploaded for this user (`uploadsGet`). Every   file is filed for this user and stored in your own storage destination, never in Widgetic\'s: a file a   customer uploads is yours to keep, and takes none of your storage allowance. So a session with `files`   can be made only after you have set a destination (`setPartnerStorageDestination`); until then it is   refused with 409 and `PARTNER_STORAGE_REQUIRED`, and when the destination cannot be used with 503 and   `STORAGE_DESTINATION_UNAVAILABLE`. A destination you remove after the session was made stops its   uploads too (the same 409; the browser is only told that the feature is not available right now).   Sessions without `files` need no destination: hand the editors your own media library instead   (`mediaLibrary`), and make them without it. - `editor`: edit one of this user\'s compositions: read it (`getCompositionById`, its content, design,   embed settings and schemas), check a content change (`validateCompositionContent`), and change its   name, content, design and embed settings (`updateComposition`, `setDynamicContent`). It can reach   only compositions you created for this managed user (tag them with `managedUserId` when you create   them); any other composition, including another of your users\', answers 404. - `creator`: use Widgetic\'s widget creator for this user, including its AI. Draw on canvases and save   them (`getAllCanvases`, `getCanvas`, `createCanvas`, `updateCanvas`, `previewDeleteCanvas`,   `deleteCanvas`); make, change, copy and delete the widgets on them (`createWidget`, `getWidgets`,   `getWidgetsBatch`, `updateWidget`, `uploadWidgetThumbnail`, `duplicateWidget`, `deleteWidget`);   list and make the compositions of a widget it built (`getAllCompositions`, `createComposition`), which   is how it shows the widget with sample values; read and add their   components (`getComponentsByWidgetId`, `createComponent`); keep the   conversation of each widget (`getConversationsByWidgetId`, `createConversationForWidget`,   `updateConversation`, `getMessages`, `createMessage`, `updateMessage`, `restoreCheckpoint`); and read a   widget\'s schemas and give it its repository (`getWidgetContentSchema`, `getWidgetDesignSchema`,   `updateWidgetRepository`). The AI that builds a widget is part of it: list the models   (`agentModelsGet`), open the widget\'s repository (`agentRepositoriesPost`,   `agentRepositoriesRepoIdGet`), start a generation and follow or cancel it (`agentCodeGeneratePost`,   `operationsStreamGet`, `operationsIdGet`, `operationsIdCancelPost`), build and preview the result   (`agentWidgetBuilderRepoHeadWidgetIdGet`, `buildWidgetFromRepo`, `previewWidgetVersion`), publish a   version of the widget and move between its versions (`agentWidgetBuilderPublishWidgetIdPost`,   `getWidgetPublishHistory`, `setWidgetPublishHistoryLive`, `renameWidgetPublishHistoryTitle`), and   turn a stroke or a sentence into a decision (`agentShapeRecognizePost`, `agentDesignResolvePost`). It can   also offer the customer your presets as starting points: read them and ask for a copy for this customer   (`listMyPresets`, `copyMyPreset`; you choose the presets with `setPartnerPreset`).   What the session makes is filed for this managed user, and the lists it reads hold only this user\'s   canvases, widgets and compositions. It can reach only canvases, widgets, compositions, repositories,   uploaded files and operations made for this managed user (tag the canvases and widgets you create   with `managedUserId`); any other canvas, widget, composition, conversation, message, repository, file   or operation, including another of your users\', answers 404. The creator also saves the composition   it is editing (`updateComposition`, from the `editor` surface) and attaches pictures to its chat   (`uploadsPost`, from the `files` surface), and the surfaces do not imply one another: to open the   whole creator for a user, ask for `creator`, `editor` and `files` together. A generation or a build   one user starts can be followed and cancelled by that user and by you, never by another of your   users. The AI is paid for by your account, as your own calls are: its credits and allowances are   yours. A session cannot make a widget public (publishing a version does not), file one under a   project or an organization, or set anything the creator does not set: a body with another field is   refused with 403 and `EDITOR_SESSION_FIELD_NOT_ALLOWED`.  Everything else is refused with 403 and `EDITOR_SESSION_ROUTE_NOT_ALLOWED`: a session cannot read your account, make more sessions, change your presets or delete a composition, and a session without the `creator` surface cannot create or list compositions. Create the composition yourself with your API key, then open the editor on it.  A session ends at `expiresAt` (at most four hours), when you end it (`revokeManagedUserEditorSession`), or when the managed user is switched off or deleted. A managed user can have at most 100 live sessions at once (`429 EDITOR_SESSION_LIMIT_REACHED`). A session that is bound to a web page (`allowed_origin`) is refused from any other origin.  The AI the session runs is paid for with your credits. Set `max_credits` to hold the session to a number of them: once its generations have taken that many (a generation that fails is refunded and does not count), the next one is refused with 402 and `EDITOR_SESSION_CREDIT_LIMIT_REACHED`, and the browser is told only that the feature is not available right now. Without it, the credits of your account are the only ceiling. What each of your users\' sessions has spent is in `getManagedUserUsage`.  Each call makes a new session. It does not take an `Idempotency-Key`: the answer holds the token, and the token is never stored where a retry could read it back. The answer is sent with `Cache-Control: no-store`.
+     * Makes a short-lived credential that lets the browser of ONE of your managed users use Widgetic\'s editor pieces, such as the File Browser and the composition editor, without your API key ever reaching that browser. Call this from your server when the page that hosts the editor opens, and hand the `token` in the answer to that page.  The token is shown once. It starts with `wgt_ses_` and the browser sends it as `Authorization: Bearer <token>`. It can do only what the `surfaces` you name allow, and only for this managed user:  - `files`: upload a file (`uploadsPost`) and list the files uploaded for this user (`uploadsGet`). Every   file is filed for this user and stored in your own storage destination, never in Widgetic\'s: a file a   customer uploads is yours to keep, and takes none of your storage allowance. Partner storage is not   optional, so no session, whatever its surfaces, can be made until you have set a destination   (`setPartnerStorageDestination`); until then it is refused with 409 and `PARTNER_STORAGE_REQUIRED`, and   when the destination cannot be used with 503 and `STORAGE_DESTINATION_UNAVAILABLE`. A destination you   remove after the session was made stops its uploads too (the same 409; the browser is only told that   the feature is not available right now). To keep a customer from uploading, leave `files` out of the   session and hand the editors your own media library instead (`mediaLibrary`). - `editor`: edit one of this user\'s compositions: read it (`getCompositionById`, its content, design,   embed settings and schemas), check a content change (`validateCompositionContent`), and change its   name, content, design and embed settings (`updateComposition`, `setDynamicContent`). It can reach   only compositions you created for this managed user (tag them with `managedUserId` when you create   them); any other composition, including another of your users\', answers 404. - `creator`: use Widgetic\'s widget creator for this user, including its AI. Draw on canvases and save   them (`getAllCanvases`, `getCanvas`, `createCanvas`, `updateCanvas`, `previewDeleteCanvas`,   `deleteCanvas`); make, change, copy and delete the widgets on them (`createWidget`, `getWidgets`,   `getWidgetsBatch`, `updateWidget`, `uploadWidgetThumbnail`, `duplicateWidget`, `deleteWidget`);   list and make the compositions of a widget it built (`getAllCompositions`, `createComposition`), which   is how it shows the widget with sample values; read and add their   components (`getComponentsByWidgetId`, `createComponent`); keep the   conversation of each widget (`getConversationsByWidgetId`, `createConversationForWidget`,   `updateConversation`, `getMessages`, `createMessage`, `updateMessage`, `restoreCheckpoint`); and read a   widget\'s schemas and give it its repository (`getWidgetContentSchema`, `getWidgetDesignSchema`,   `updateWidgetRepository`). The AI that builds a widget is part of it: list the models   (`agentModelsGet`), open the widget\'s repository (`agentRepositoriesPost`,   `agentRepositoriesRepoIdGet`), start a generation and follow or cancel it (`agentCodeGeneratePost`,   `operationsStreamGet`, `operationsIdGet`, `operationsIdCancelPost`), build and preview the result   (`agentWidgetBuilderRepoHeadWidgetIdGet`, `buildWidgetFromRepo`, `previewWidgetVersion`), publish a   version of the widget and move between its versions (`agentWidgetBuilderPublishWidgetIdPost`,   `getWidgetPublishHistory`, `setWidgetPublishHistoryLive`, `renameWidgetPublishHistoryTitle`), and   turn a stroke or a sentence into a decision (`agentShapeRecognizePost`, `agentDesignResolvePost`). It can   also offer the customer your presets as starting points: read them and ask for a copy for this customer   (`listMyPresets`, `copyMyPreset`; you choose the presets with `setPartnerPreset`).   What the session makes is filed for this managed user, and the lists it reads hold only this user\'s   canvases, widgets and compositions. It can reach only canvases, widgets, compositions, repositories,   uploaded files and operations made for this managed user (tag the canvases and widgets you create   with `managedUserId`); any other canvas, widget, composition, conversation, message, repository, file   or operation, including another of your users\', answers 404. The creator also saves the composition   it is editing (`updateComposition`, from the `editor` surface) and attaches pictures to its chat   (`uploadsPost`, from the `files` surface), and the surfaces do not imply one another: to open the   whole creator for a user, ask for `creator`, `editor` and `files` together. A generation or a build   one user starts can be followed and cancelled by that user and by you, never by another of your   users. The AI is paid for by your account, as your own calls are: its credits and allowances are   yours. A session cannot make a widget public (publishing a version does not), file one under a   project or an organization, or set anything the creator does not set: a body with another field is   refused with 403 and `EDITOR_SESSION_FIELD_NOT_ALLOWED`.  Everything else is refused with 403 and `EDITOR_SESSION_ROUTE_NOT_ALLOWED`: a session cannot read your account, make more sessions, change your presets or delete a composition, and a session without the `creator` surface cannot create or list compositions. Create the composition yourself with your API key, then open the editor on it.  A session ends at `expiresAt` (at most four hours), when you end it (`revokeManagedUserEditorSession`), or when the managed user is switched off or deleted. A managed user can have at most 100 live sessions at once (`429 EDITOR_SESSION_LIMIT_REACHED`). A session that is bound to a web page (`allowed_origin`) is refused from any other origin.  The AI the session runs is paid for with your credits. Set `max_credits` to hold the session to a number of them: once its generations have taken that many (a generation that fails is refunded and does not count), the next one is refused with 402 and `EDITOR_SESSION_CREDIT_LIMIT_REACHED`, and the browser is told only that the feature is not available right now. Without it, the credits of your account are the only ceiling. What each of your users\' sessions has spent is in `getManagedUserUsage`.  Each call makes a new session. It does not take an `Idempotency-Key`: the answer holds the token, and the token is never stored where a retry could read it back. The answer is sent with `Cache-Control: no-store`.
      * Create an editor session for a managed user
      */
     createManagedUserEditorSessionRaw(requestParameters: CreateManagedUserEditorSessionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<EditorSession>>;
     /**
-     * Makes a short-lived credential that lets the browser of ONE of your managed users use Widgetic\'s editor pieces, such as the File Browser and the composition editor, without your API key ever reaching that browser. Call this from your server when the page that hosts the editor opens, and hand the `token` in the answer to that page.  The token is shown once. It starts with `wgt_ses_` and the browser sends it as `Authorization: Bearer <token>`. It can do only what the `surfaces` you name allow, and only for this managed user:  - `files`: upload a file (`uploadsPost`) and list the files uploaded for this user (`uploadsGet`). Every   file is filed for this user and stored in your own storage destination, never in Widgetic\'s: a file a   customer uploads is yours to keep, and takes none of your storage allowance. So a session with `files`   can be made only after you have set a destination (`setPartnerStorageDestination`); until then it is   refused with 409 and `PARTNER_STORAGE_REQUIRED`, and when the destination cannot be used with 503 and   `STORAGE_DESTINATION_UNAVAILABLE`. A destination you remove after the session was made stops its   uploads too (the same 409; the browser is only told that the feature is not available right now).   Sessions without `files` need no destination: hand the editors your own media library instead   (`mediaLibrary`), and make them without it. - `editor`: edit one of this user\'s compositions: read it (`getCompositionById`, its content, design,   embed settings and schemas), check a content change (`validateCompositionContent`), and change its   name, content, design and embed settings (`updateComposition`, `setDynamicContent`). It can reach   only compositions you created for this managed user (tag them with `managedUserId` when you create   them); any other composition, including another of your users\', answers 404. - `creator`: use Widgetic\'s widget creator for this user, including its AI. Draw on canvases and save   them (`getAllCanvases`, `getCanvas`, `createCanvas`, `updateCanvas`, `previewDeleteCanvas`,   `deleteCanvas`); make, change, copy and delete the widgets on them (`createWidget`, `getWidgets`,   `getWidgetsBatch`, `updateWidget`, `uploadWidgetThumbnail`, `duplicateWidget`, `deleteWidget`);   list and make the compositions of a widget it built (`getAllCompositions`, `createComposition`), which   is how it shows the widget with sample values; read and add their   components (`getComponentsByWidgetId`, `createComponent`); keep the   conversation of each widget (`getConversationsByWidgetId`, `createConversationForWidget`,   `updateConversation`, `getMessages`, `createMessage`, `updateMessage`, `restoreCheckpoint`); and read a   widget\'s schemas and give it its repository (`getWidgetContentSchema`, `getWidgetDesignSchema`,   `updateWidgetRepository`). The AI that builds a widget is part of it: list the models   (`agentModelsGet`), open the widget\'s repository (`agentRepositoriesPost`,   `agentRepositoriesRepoIdGet`), start a generation and follow or cancel it (`agentCodeGeneratePost`,   `operationsStreamGet`, `operationsIdGet`, `operationsIdCancelPost`), build and preview the result   (`agentWidgetBuilderRepoHeadWidgetIdGet`, `buildWidgetFromRepo`, `previewWidgetVersion`), publish a   version of the widget and move between its versions (`agentWidgetBuilderPublishWidgetIdPost`,   `getWidgetPublishHistory`, `setWidgetPublishHistoryLive`, `renameWidgetPublishHistoryTitle`), and   turn a stroke or a sentence into a decision (`agentShapeRecognizePost`, `agentDesignResolvePost`). It can   also offer the customer your presets as starting points: read them and ask for a copy for this customer   (`listMyPresets`, `copyMyPreset`; you choose the presets with `setPartnerPreset`).   What the session makes is filed for this managed user, and the lists it reads hold only this user\'s   canvases, widgets and compositions. It can reach only canvases, widgets, compositions, repositories,   uploaded files and operations made for this managed user (tag the canvases and widgets you create   with `managedUserId`); any other canvas, widget, composition, conversation, message, repository, file   or operation, including another of your users\', answers 404. The creator also saves the composition   it is editing (`updateComposition`, from the `editor` surface) and attaches pictures to its chat   (`uploadsPost`, from the `files` surface), and the surfaces do not imply one another: to open the   whole creator for a user, ask for `creator`, `editor` and `files` together. A generation or a build   one user starts can be followed and cancelled by that user and by you, never by another of your   users. The AI is paid for by your account, as your own calls are: its credits and allowances are   yours. A session cannot make a widget public (publishing a version does not), file one under a   project or an organization, or set anything the creator does not set: a body with another field is   refused with 403 and `EDITOR_SESSION_FIELD_NOT_ALLOWED`.  Everything else is refused with 403 and `EDITOR_SESSION_ROUTE_NOT_ALLOWED`: a session cannot read your account, make more sessions, change your presets or delete a composition, and a session without the `creator` surface cannot create or list compositions. Create the composition yourself with your API key, then open the editor on it.  A session ends at `expiresAt` (at most four hours), when you end it (`revokeManagedUserEditorSession`), or when the managed user is switched off or deleted. A managed user can have at most 100 live sessions at once (`429 EDITOR_SESSION_LIMIT_REACHED`). A session that is bound to a web page (`allowed_origin`) is refused from any other origin.  The AI the session runs is paid for with your credits. Set `max_credits` to hold the session to a number of them: once its generations have taken that many (a generation that fails is refunded and does not count), the next one is refused with 402 and `EDITOR_SESSION_CREDIT_LIMIT_REACHED`, and the browser is told only that the feature is not available right now. Without it, the credits of your account are the only ceiling. What each of your users\' sessions has spent is in `getManagedUserUsage`.  Each call makes a new session. It does not take an `Idempotency-Key`: the answer holds the token, and the token is never stored where a retry could read it back. The answer is sent with `Cache-Control: no-store`.
+     * Makes a short-lived credential that lets the browser of ONE of your managed users use Widgetic\'s editor pieces, such as the File Browser and the composition editor, without your API key ever reaching that browser. Call this from your server when the page that hosts the editor opens, and hand the `token` in the answer to that page.  The token is shown once. It starts with `wgt_ses_` and the browser sends it as `Authorization: Bearer <token>`. It can do only what the `surfaces` you name allow, and only for this managed user:  - `files`: upload a file (`uploadsPost`) and list the files uploaded for this user (`uploadsGet`). Every   file is filed for this user and stored in your own storage destination, never in Widgetic\'s: a file a   customer uploads is yours to keep, and takes none of your storage allowance. Partner storage is not   optional, so no session, whatever its surfaces, can be made until you have set a destination   (`setPartnerStorageDestination`); until then it is refused with 409 and `PARTNER_STORAGE_REQUIRED`, and   when the destination cannot be used with 503 and `STORAGE_DESTINATION_UNAVAILABLE`. A destination you   remove after the session was made stops its uploads too (the same 409; the browser is only told that   the feature is not available right now). To keep a customer from uploading, leave `files` out of the   session and hand the editors your own media library instead (`mediaLibrary`). - `editor`: edit one of this user\'s compositions: read it (`getCompositionById`, its content, design,   embed settings and schemas), check a content change (`validateCompositionContent`), and change its   name, content, design and embed settings (`updateComposition`, `setDynamicContent`). It can reach   only compositions you created for this managed user (tag them with `managedUserId` when you create   them); any other composition, including another of your users\', answers 404. - `creator`: use Widgetic\'s widget creator for this user, including its AI. Draw on canvases and save   them (`getAllCanvases`, `getCanvas`, `createCanvas`, `updateCanvas`, `previewDeleteCanvas`,   `deleteCanvas`); make, change, copy and delete the widgets on them (`createWidget`, `getWidgets`,   `getWidgetsBatch`, `updateWidget`, `uploadWidgetThumbnail`, `duplicateWidget`, `deleteWidget`);   list and make the compositions of a widget it built (`getAllCompositions`, `createComposition`), which   is how it shows the widget with sample values; read and add their   components (`getComponentsByWidgetId`, `createComponent`); keep the   conversation of each widget (`getConversationsByWidgetId`, `createConversationForWidget`,   `updateConversation`, `getMessages`, `createMessage`, `updateMessage`, `restoreCheckpoint`); and read a   widget\'s schemas and give it its repository (`getWidgetContentSchema`, `getWidgetDesignSchema`,   `updateWidgetRepository`). The AI that builds a widget is part of it: list the models   (`agentModelsGet`), open the widget\'s repository (`agentRepositoriesPost`,   `agentRepositoriesRepoIdGet`), start a generation and follow or cancel it (`agentCodeGeneratePost`,   `operationsStreamGet`, `operationsIdGet`, `operationsIdCancelPost`), build and preview the result   (`agentWidgetBuilderRepoHeadWidgetIdGet`, `buildWidgetFromRepo`, `previewWidgetVersion`), publish a   version of the widget and move between its versions (`agentWidgetBuilderPublishWidgetIdPost`,   `getWidgetPublishHistory`, `setWidgetPublishHistoryLive`, `renameWidgetPublishHistoryTitle`), and   turn a stroke or a sentence into a decision (`agentShapeRecognizePost`, `agentDesignResolvePost`). It can   also offer the customer your presets as starting points: read them and ask for a copy for this customer   (`listMyPresets`, `copyMyPreset`; you choose the presets with `setPartnerPreset`).   What the session makes is filed for this managed user, and the lists it reads hold only this user\'s   canvases, widgets and compositions. It can reach only canvases, widgets, compositions, repositories,   uploaded files and operations made for this managed user (tag the canvases and widgets you create   with `managedUserId`); any other canvas, widget, composition, conversation, message, repository, file   or operation, including another of your users\', answers 404. The creator also saves the composition   it is editing (`updateComposition`, from the `editor` surface) and attaches pictures to its chat   (`uploadsPost`, from the `files` surface), and the surfaces do not imply one another: to open the   whole creator for a user, ask for `creator`, `editor` and `files` together. A generation or a build   one user starts can be followed and cancelled by that user and by you, never by another of your   users. The AI is paid for by your account, as your own calls are: its credits and allowances are   yours. A session cannot make a widget public (publishing a version does not), file one under a   project or an organization, or set anything the creator does not set: a body with another field is   refused with 403 and `EDITOR_SESSION_FIELD_NOT_ALLOWED`.  Everything else is refused with 403 and `EDITOR_SESSION_ROUTE_NOT_ALLOWED`: a session cannot read your account, make more sessions, change your presets or delete a composition, and a session without the `creator` surface cannot create or list compositions. Create the composition yourself with your API key, then open the editor on it.  A session ends at `expiresAt` (at most four hours), when you end it (`revokeManagedUserEditorSession`), or when the managed user is switched off or deleted. A managed user can have at most 100 live sessions at once (`429 EDITOR_SESSION_LIMIT_REACHED`). A session that is bound to a web page (`allowed_origin`) is refused from any other origin.  The AI the session runs is paid for with your credits. Set `max_credits` to hold the session to a number of them: once its generations have taken that many (a generation that fails is refunded and does not count), the next one is refused with 402 and `EDITOR_SESSION_CREDIT_LIMIT_REACHED`, and the browser is told only that the feature is not available right now. Without it, the credits of your account are the only ceiling. What each of your users\' sessions has spent is in `getManagedUserUsage`.  Each call makes a new session. It does not take an `Idempotency-Key`: the answer holds the token, and the token is never stored where a retry could read it back. The answer is sent with `Cache-Control: no-store`.
      * Create an editor session for a managed user
      */
     createManagedUserEditorSession(requestParameters: CreateManagedUserEditorSessionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<EditorSession>;