@leaflow/sdk 0.0.0-dev.39.gc9098a0 → 0.0.0-dev.391.g0aed14e

package/dist/compute/v1/generated/validators/setSnapshotQuotaRequestBody.zod.d.ts

@@ -0,0 +1,55 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const SetSnapshotQuotaRequestBody: zod.ZodObject<{
+    limit: zod.ZodInt;
+    billing: zod.ZodObject<{
+        usage_type: zod.ZodEnum<{
+            licensed: "licensed";
+            metered: "metered";
+        }>;
+        period: zod.ZodOptional<zod.ZodObject<{
+            unit: zod.ZodEnum<{
+                month: "month";
+                year: "year";
+            }>;
+            count: zod.ZodInt;
+        }, zod.z.core.$strict>>;
+        termination_policy: zod.ZodOptional<zod.ZodEnum<{
+            immediate: "immediate";
+            period_end: "period_end";
+        }>>;
+    }, zod.z.core.$strict>;
+    checkout: zod.ZodOptional<zod.ZodObject<{
+        mode: zod.ZodDefault<zod.ZodEnum<{
+            automatic: "automatic";
+            deferred: "deferred";
+        }>>;
+        expected_amount: zod.ZodOptional<zod.ZodIntersection<zod.ZodString, zod.ZodString>>;
+        return_url: zod.ZodOptional<zod.ZodURL>;
+    }, zod.z.core.$strict>>;
+    proration_date: zod.ZodOptional<zod.z.ZodISODateTime>;
+}, zod.z.core.$strict>;
+export type SetSnapshotQuotaRequestBody = zod.input<typeof SetSnapshotQuotaRequestBody>;
+export type SetSnapshotQuotaRequestBodyOutput = zod.output<typeof SetSnapshotQuotaRequestBody>;

package/dist/compute/v1/generated/validators/setSnapshotQuotaRequestBody.zod.js

@@ -0,0 +1,38 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+import { BillingChoice } from "./billingChoice.zod.js";
+import { CheckoutOptions } from "./checkoutOptions.zod.js";
+export const SetSnapshotQuotaRequestBody = zod.strictObject({
+    limit: zod
+        .int()
+        .min(1)
+        .describe("Desired total concurrent snapshot count for this project and region, not additional slots."),
+    billing: BillingChoice,
+    checkout: CheckoutOptions.optional(),
+    proration_date: zod.iso
+        .datetime({ offset: true })
+        .optional()
+        .describe("The `proration_date` of Billing's quote for this change, so that the order is priced from the same instant. Only for automatic checkout; deferred checkout is priced when the customer completes it. Defaults to the time of the request; it must be a whole second, not in the future and at most 10 minutes old, otherwise the request is refused with `BILLING_CHANGE_INVALID`."),
+});

package/dist/compute/v1/generated/validators/setSnapshotQuotaResponseBody.zod.d.ts

@@ -0,0 +1,68 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const SetSnapshotQuotaResponseBody: zod.ZodObject<{
+    snapshot_quota: zod.ZodObject<{
+        region_id: zod.ZodUUID;
+        status: zod.ZodEnum<{
+            active: "active";
+            failed: "failed";
+            pending: "pending";
+            suspended: "suspended";
+            provisioning: "provisioning";
+            inactive: "inactive";
+        }>;
+        limit: zod.ZodInt;
+        used: zod.ZodInt;
+        available: zod.ZodInt;
+        order_id: zod.ZodNullable<zod.ZodUUID>;
+        subscription_id: zod.ZodNullable<zod.ZodUUID>;
+        billing: zod.ZodUnion<readonly [zod.ZodObject<{
+            usage_type: zod.ZodEnum<{
+                licensed: "licensed";
+                metered: "metered";
+            }>;
+            period: zod.ZodOptional<zod.ZodObject<{
+                unit: zod.ZodEnum<{
+                    month: "month";
+                    year: "year";
+                }>;
+                count: zod.ZodInt;
+            }, zod.z.core.$strict>>;
+            termination_policy: zod.ZodOptional<zod.ZodEnum<{
+                immediate: "immediate";
+                period_end: "period_end";
+            }>>;
+        }, zod.z.core.$strict>, zod.ZodNull]>;
+        release_subscription_ids: zod.ZodArray<zod.ZodUUID>;
+        pending_limit: zod.ZodNullable<zod.ZodInt>;
+        pending_checkout_session_id: zod.ZodNullable<zod.ZodUUID>;
+        pending_order_id: zod.ZodNullable<zod.ZodUUID>;
+        failure_reason: zod.ZodNullable<zod.ZodUnion<readonly [zod.ZodLiteral<"checkout_expired">, zod.ZodLiteral<"order_declined">, zod.ZodLiteral<"order_canceled">, zod.ZodLiteral<"order_expired">, zod.ZodLiteral<"provisioning_failed">, zod.ZodLiteral<null>]>>;
+    }, zod.z.core.$strict>;
+    checkout_session_id: zod.ZodUUID;
+    order_id: zod.ZodNullable<zod.ZodUUID>;
+}, zod.z.core.$strict>;
+export type SetSnapshotQuotaResponseBody = zod.input<typeof SetSnapshotQuotaResponseBody>;
+export type SetSnapshotQuotaResponseBodyOutput = zod.output<typeof SetSnapshotQuotaResponseBody>;

package/dist/compute/v1/generated/validators/setSnapshotQuotaResponseBody.zod.js

@@ -0,0 +1,35 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+import { SnapshotQuota } from "./snapshotQuota.zod.js";
+export const SetSnapshotQuotaResponseBody = zod.strictObject({
+    snapshot_quota: SnapshotQuota,
+    checkout_session_id: zod
+        .uuid()
+        .describe("The Billing Checkout Session of this purchase. With deferred checkout, the customer completes it in Billing."),
+    order_id: zod
+        .uuid()
+        .nullable()
+        .describe("The order created when checkout completes, at once for automatic checkout; null until then."),
+});

package/dist/compute/v1/generated/validators/snapshotListResponseBody.zod.d.ts

@@ -0,0 +1,61 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const SnapshotListResponseBody: zod.ZodObject<{
+    items: zod.ZodNullable<zod.ZodArray<zod.ZodObject<{
+        availability_zone_id: zod.ZodUUID;
+        created_at: zod.z.ZodISODateTime;
+        disk_id: zod.ZodUUID;
+        id: zod.ZodUUID;
+        name: zod.ZodString;
+        region_id: zod.ZodUUID;
+        size_gb: zod.ZodInt;
+        status: zod.ZodEnum<{
+            deleted: "deleted";
+            available: "available";
+            error: "error";
+            failed: "failed";
+            pending: "pending";
+            provisioning: "provisioning";
+            missing: "missing";
+        }>;
+        operation: zod.ZodUnion<readonly [zod.ZodObject<{
+            type: zod.ZodEnum<{
+                delete: "delete";
+                create: "create";
+                restore: "restore";
+            }>;
+            started_at: zod.z.ZodISODateTime;
+        }, zod.z.core.$strict>, zod.ZodNull]>;
+        generation: zod.ZodInt;
+        observed_at: zod.ZodNullable<zod.z.ZodISODateTime>;
+    }, zod.z.core.$strict>>>;
+    pagination: zod.ZodObject<{
+        page: zod.ZodInt;
+        page_size: zod.ZodInt;
+        total_count: zod.ZodOptional<zod.ZodInt>;
+    }, zod.z.core.$strict>;
+}, zod.z.core.$strict>;
+export type SnapshotListResponseBody = zod.input<typeof SnapshotListResponseBody>;
+export type SnapshotListResponseBodyOutput = zod.output<typeof SnapshotListResponseBody>;

package/dist/compute/v1/generated/validators/snapshotListResponseBody.zod.js

@@ -0,0 +1,30 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+import { OffsetPagination } from "./offsetPagination.zod.js";
+import { SnapshotResource } from "./snapshotResource.zod.js";
+export const SnapshotListResponseBody = zod.strictObject({
+    items: zod.array(SnapshotResource).nullable(),
+    pagination: OffsetPagination,
+});

package/dist/compute/v1/generated/validators/snapshotOperation.zod.d.ts

@@ -0,0 +1,34 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const SnapshotOperation: zod.ZodObject<{
+    type: zod.ZodEnum<{
+        delete: "delete";
+        create: "create";
+        restore: "restore";
+    }>;
+    started_at: zod.z.ZodISODateTime;
+}, zod.z.core.$strict>;
+export type SnapshotOperation = zod.input<typeof SnapshotOperation>;
+export type SnapshotOperationOutput = zod.output<typeof SnapshotOperation>;

package/dist/compute/v1/generated/validators/snapshotOperation.zod.js

@@ -0,0 +1,32 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export const SnapshotOperation = zod
+    .strictObject({
+    type: zod
+        .enum(["create", "restore", "delete"])
+        .describe("`restore`: a disk is being reverted to this snapshot or created from it."),
+    started_at: zod.iso.datetime({ offset: true }),
+})
+    .describe("An operation still running on this snapshot. It is not a separate resource; once it finishes, the snapshot's `operation` is null again and the snapshot shows the result.");

package/dist/compute/v1/generated/validators/snapshotQuota.zod.d.ts

@@ -0,0 +1,67 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const snapshotQuotaLimitMin = 0;
+export declare const snapshotQuotaUsedMin = 0;
+export declare const snapshotQuotaAvailableMin = 0;
+export declare const SnapshotQuota: zod.ZodObject<{
+    region_id: zod.ZodUUID;
+    status: zod.ZodEnum<{
+        active: "active";
+        failed: "failed";
+        pending: "pending";
+        suspended: "suspended";
+        provisioning: "provisioning";
+        inactive: "inactive";
+    }>;
+    limit: zod.ZodInt;
+    used: zod.ZodInt;
+    available: zod.ZodInt;
+    order_id: zod.ZodNullable<zod.ZodUUID>;
+    subscription_id: zod.ZodNullable<zod.ZodUUID>;
+    billing: zod.ZodUnion<readonly [zod.ZodObject<{
+        usage_type: zod.ZodEnum<{
+            licensed: "licensed";
+            metered: "metered";
+        }>;
+        period: zod.ZodOptional<zod.ZodObject<{
+            unit: zod.ZodEnum<{
+                month: "month";
+                year: "year";
+            }>;
+            count: zod.ZodInt;
+        }, zod.z.core.$strict>>;
+        termination_policy: zod.ZodOptional<zod.ZodEnum<{
+            immediate: "immediate";
+            period_end: "period_end";
+        }>>;
+    }, zod.z.core.$strict>, zod.ZodNull]>;
+    release_subscription_ids: zod.ZodArray<zod.ZodUUID>;
+    pending_limit: zod.ZodNullable<zod.ZodInt>;
+    pending_checkout_session_id: zod.ZodNullable<zod.ZodUUID>;
+    pending_order_id: zod.ZodNullable<zod.ZodUUID>;
+    failure_reason: zod.ZodNullable<zod.ZodUnion<readonly [zod.ZodLiteral<"checkout_expired">, zod.ZodLiteral<"order_declined">, zod.ZodLiteral<"order_canceled">, zod.ZodLiteral<"order_expired">, zod.ZodLiteral<"provisioning_failed">, zod.ZodLiteral<null>]>>;
+}, zod.z.core.$strict>;
+export type SnapshotQuota = zod.input<typeof SnapshotQuota>;
+export type SnapshotQuotaOutput = zod.output<typeof SnapshotQuota>;

package/dist/compute/v1/generated/validators/snapshotQuota.zod.js

@@ -0,0 +1,86 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+import { BillingChoice } from "./billingChoice.zod.js";
+export const snapshotQuotaLimitMin = 0;
+export const snapshotQuotaUsedMin = 0;
+export const snapshotQuotaAvailableMin = 0;
+export const SnapshotQuota = zod
+    .strictObject({
+    region_id: zod.uuid(),
+    status: zod
+        .enum(["inactive", "pending", "provisioning", "active", "suspended", "failed"])
+        .describe("inactive has no purchase; pending is a first purchase whose order has not been accepted;\nprovisioning is a first purchase being activated; active permits creation within available\ncapacity; suspended refuses new creation; failed means the first purchase failed, as\nfailure_reason states. A pending change keeps the current status and limit until it is applied."),
+    limit: zod
+        .int()
+        .min(snapshotQuotaLimitMin)
+        .describe("Effective maximum concurrent snapshot count. Zero until the first purchase is activated."),
+    used: zod
+        .int()
+        .min(snapshotQuotaUsedMin)
+        .describe("Held and reserved snapshot slots, including pending creation and unconfirmed cleanup."),
+    available: zod
+        .int()
+        .min(snapshotQuotaAvailableMin)
+        .describe("max(limit - used, 0), or zero while creation is not permitted."),
+    order_id: zod
+        .uuid()
+        .nullable()
+        .describe("The order establishing the currently associated quota purchase, including an initial pending purchase once its checkout completes."),
+    subscription_id: zod
+        .uuid()
+        .nullable()
+        .describe("The quota purchase's Billing subscription, not an individual snapshot subscription.\nMay still be pending on an initial purchase; an existing subscription remains associated\nuntil a replacement quota is activated. Null when no purchase has been recorded."),
+    billing: zod
+        .union([BillingChoice, zod.null()])
+        .describe("The billing choice of the associated quota purchase, as given when it was bought. A change of an existing purchase has to give the same choice. Null when no purchase has been recorded."),
+    release_subscription_ids: zod
+        .array(zod.uuid())
+        .describe("The subscription a cancellation through Billing has to cover to release this snapshot quota. A subscription that has ended is not listed, and the list is empty when no subscription pays for the quota."),
+    pending_limit: zod
+        .int()
+        .min(1)
+        .nullable()
+        .describe("Target count awaiting checkout or activation; null when no purchase is pending."),
+    pending_checkout_session_id: zod
+        .uuid()
+        .nullable()
+        .describe("Checkout Session of the pending initial purchase or change; null when none is pending."),
+    pending_order_id: zod
+        .uuid()
+        .nullable()
+        .describe("Order for the pending initial purchase or change once its checkout completes; null otherwise."),
+    failure_reason: zod
+        .union([
+        zod.literal("checkout_expired"),
+        zod.literal("order_declined"),
+        zod.literal("order_canceled"),
+        zod.literal("order_expired"),
+        zod.literal("provisioning_failed"),
+        zod.literal(null),
+    ])
+        .nullable()
+        .describe("Why the first purchase failed; null unless status is failed. A failed change leaves the current\nlimit in force and clears pending_limit; its Checkout Session or order shows the outcome."),
+})
+    .describe("Snapshot count capacity for the authenticated project and one region, projected from its\neffective quota purchase and Compute's actual holdings. This is not a Billing Allowance:\ncreation occupies capacity and confirmed deletion releases it rather than consuming a grant.\nPending purchases never increase effective capacity before commercial acceptance and activation.");