@leaflow/sdk 0.179.0 → 0.181.0

package/dist/notification/v1/generated/validators/realtimeAuthResource.zod.js

@@ -1,67 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Notification API
- * Read the notifications this platform has sent you, and choose where each kind of notification
- * is delivered.
- *
- * Every service on the platform reports events here rather than contacting you directly. This
- * API is the single place where those events are read, and the single place where delivery is
- * configured.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `bearerAuth` security scheme.
- *
- * **Neither the path nor the headers carry a `project_id`**: the current project is determined by
- * the token. Listing operations return everything addressed to you across every project by
- * default, because a notification is addressed to a person rather than to a project; pass
- * `scope=current_project` to narrow the result to the project in the token.
- *
- * ## Conventions
- *
- * - **Notifications are typed, and the type determines who receives it.** A type such as
- *   `compute.instance.provisioned` is addressed to whoever created the instance, while
- *   `monitoring.alert.raised` is addressed to every member of the project. The full catalogue is
- *   available from `GET /api/v1/notification-types` and is stable: a type identifier is never
- *   reused for a different event.
- * - **Text is rendered at read time from the language on your preferences.** Changing the
- *   language changes the text of everything already in the inbox. Messages already delivered by
- *   email or to an outbound channel are not rewritten, because they have already been sent.
- * - **Times inside rendered text are stated in UTC and say so.** There is no time zone setting.
- *   Clients that can determine the reader's time zone should present `created_at`, `occurred_at`
- *   and the timestamps in `params` — all of which are RFC 3339 — in local time instead. Email
- *   cannot do this, which is why the text it carries is explicit about being UTC.
- * - **Some types must reach you, and those cannot be muted or removed from email.** They are
- *   marked `mandatory` in the catalogue: types you would only find out about by signing in, when
- *   not finding out costs you something — a suspension, a deletion, a credential that expires.
- *   Everything else about them is still configurable, including adding channels of your own.
- * - **Deleting a preference restores the default; it does not turn the type off.** To stop
- *   receiving a type, set `muted` on it.
- * - **Outbound channels deliver nothing until they are verified.** Registering a channel does not
- *   contact it. Verification is a separate operation that sends one message, and only a channel
- *   that has acknowledged it receives anything afterwards.
- * - **Channel endpoints are never returned.** No operation, including the one that registers
- *   them, returns the address that was submitted. A channel entered incorrectly must be deleted
- *   and registered again.
- *
- * ## Rate and volume
- *
- * Delivery to outbound channels is limited per channel, and bursts of alerts about one server are
- * summarised rather than sent individually. Nothing is summarised in the inbox: it always holds
- * every notification. A notification that was summarised or suppressed is still readable here.
- *
- * ## One-time credentials
- *
- * Some notifications carry a reference to a credential rather than the credential itself — the
- * initial password of a newly created instance, for example. That credential is readable exactly
- * once, expires on its own, and is destroyed as soon as it has been read. Requesting it a second
- * time returns `CREDENTIAL_TICKET_CONSUMED`.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export const RealtimeAuthResource = zod.strictObject({
-    auth: zod
-        .string()
-        .describe("The authorization token for this subscription, passed back to the realtime server by the client library"),
-});

package/dist/notification/v1/generated/validators/realtimeConnectionResource.zod.d.ts

@@ -1,76 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Notification API
- * Read the notifications this platform has sent you, and choose where each kind of notification
- * is delivered.
- *
- * Every service on the platform reports events here rather than contacting you directly. This
- * API is the single place where those events are read, and the single place where delivery is
- * configured.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `bearerAuth` security scheme.
- *
- * **Neither the path nor the headers carry a `project_id`**: the current project is determined by
- * the token. Listing operations return everything addressed to you across every project by
- * default, because a notification is addressed to a person rather than to a project; pass
- * `scope=current_project` to narrow the result to the project in the token.
- *
- * ## Conventions
- *
- * - **Notifications are typed, and the type determines who receives it.** A type such as
- *   `compute.instance.provisioned` is addressed to whoever created the instance, while
- *   `monitoring.alert.raised` is addressed to every member of the project. The full catalogue is
- *   available from `GET /api/v1/notification-types` and is stable: a type identifier is never
- *   reused for a different event.
- * - **Text is rendered at read time from the language on your preferences.** Changing the
- *   language changes the text of everything already in the inbox. Messages already delivered by
- *   email or to an outbound channel are not rewritten, because they have already been sent.
- * - **Times inside rendered text are stated in UTC and say so.** There is no time zone setting.
- *   Clients that can determine the reader's time zone should present `created_at`, `occurred_at`
- *   and the timestamps in `params` — all of which are RFC 3339 — in local time instead. Email
- *   cannot do this, which is why the text it carries is explicit about being UTC.
- * - **Some types must reach you, and those cannot be muted or removed from email.** They are
- *   marked `mandatory` in the catalogue: types you would only find out about by signing in, when
- *   not finding out costs you something — a suspension, a deletion, a credential that expires.
- *   Everything else about them is still configurable, including adding channels of your own.
- * - **Deleting a preference restores the default; it does not turn the type off.** To stop
- *   receiving a type, set `muted` on it.
- * - **Outbound channels deliver nothing until they are verified.** Registering a channel does not
- *   contact it. Verification is a separate operation that sends one message, and only a channel
- *   that has acknowledged it receives anything afterwards.
- * - **Channel endpoints are never returned.** No operation, including the one that registers
- *   them, returns the address that was submitted. A channel entered incorrectly must be deleted
- *   and registered again.
- *
- * ## Rate and volume
- *
- * Delivery to outbound channels is limited per channel, and bursts of alerts about one server are
- * summarised rather than sent individually. Nothing is summarised in the inbox: it always holds
- * every notification. A notification that was summarised or suppressed is still readable here.
- *
- * ## One-time credentials
- *
- * Some notifications carry a reference to a credential rather than the credential itself — the
- * initial password of a newly created instance, for example. That credential is readable exactly
- * once, expires on its own, and is destroyed as soon as it has been read. Requesting it a second
- * time returns `CREDENTIAL_TICKET_CONSUMED`.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const RealtimeConnectionResource: zod.ZodObject<{
-    auth_path: zod.ZodString;
-    cluster: zod.ZodString;
-    enabled: zod.ZodBoolean;
-    host: zod.ZodString;
-    key: zod.ZodString;
-    port: zod.ZodInt;
-    announcements_channel: zod.ZodString;
-    project_channel: zod.ZodString;
-    secure: zod.ZodBoolean;
-    user_channel: zod.ZodString;
-}, zod.z.core.$strict>;
-export type RealtimeConnectionResource = zod.input<typeof RealtimeConnectionResource>;
-export type RealtimeConnectionResourceOutput = zod.output<typeof RealtimeConnectionResource>;

package/dist/notification/v1/generated/validators/realtimeConnectionResource.zod.js

@@ -1,88 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Notification API
- * Read the notifications this platform has sent you, and choose where each kind of notification
- * is delivered.
- *
- * Every service on the platform reports events here rather than contacting you directly. This
- * API is the single place where those events are read, and the single place where delivery is
- * configured.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `bearerAuth` security scheme.
- *
- * **Neither the path nor the headers carry a `project_id`**: the current project is determined by
- * the token. Listing operations return everything addressed to you across every project by
- * default, because a notification is addressed to a person rather than to a project; pass
- * `scope=current_project` to narrow the result to the project in the token.
- *
- * ## Conventions
- *
- * - **Notifications are typed, and the type determines who receives it.** A type such as
- *   `compute.instance.provisioned` is addressed to whoever created the instance, while
- *   `monitoring.alert.raised` is addressed to every member of the project. The full catalogue is
- *   available from `GET /api/v1/notification-types` and is stable: a type identifier is never
- *   reused for a different event.
- * - **Text is rendered at read time from the language on your preferences.** Changing the
- *   language changes the text of everything already in the inbox. Messages already delivered by
- *   email or to an outbound channel are not rewritten, because they have already been sent.
- * - **Times inside rendered text are stated in UTC and say so.** There is no time zone setting.
- *   Clients that can determine the reader's time zone should present `created_at`, `occurred_at`
- *   and the timestamps in `params` — all of which are RFC 3339 — in local time instead. Email
- *   cannot do this, which is why the text it carries is explicit about being UTC.
- * - **Some types must reach you, and those cannot be muted or removed from email.** They are
- *   marked `mandatory` in the catalogue: types you would only find out about by signing in, when
- *   not finding out costs you something — a suspension, a deletion, a credential that expires.
- *   Everything else about them is still configurable, including adding channels of your own.
- * - **Deleting a preference restores the default; it does not turn the type off.** To stop
- *   receiving a type, set `muted` on it.
- * - **Outbound channels deliver nothing until they are verified.** Registering a channel does not
- *   contact it. Verification is a separate operation that sends one message, and only a channel
- *   that has acknowledged it receives anything afterwards.
- * - **Channel endpoints are never returned.** No operation, including the one that registers
- *   them, returns the address that was submitted. A channel entered incorrectly must be deleted
- *   and registered again.
- *
- * ## Rate and volume
- *
- * Delivery to outbound channels is limited per channel, and bursts of alerts about one server are
- * summarised rather than sent individually. Nothing is summarised in the inbox: it always holds
- * every notification. A notification that was summarised or suppressed is still readable here.
- *
- * ## One-time credentials
- *
- * Some notifications carry a reference to a credential rather than the credential itself — the
- * initial password of a newly created instance, for example. That credential is readable exactly
- * once, expires on its own, and is destroyed as soon as it has been read. Requesting it a second
- * time returns `CREDENTIAL_TICKET_CONSUMED`.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export const RealtimeConnectionResource = zod
-    .strictObject({
-    auth_path: zod
-        .string()
-        .describe("The path a client posts to while subscribing, relative to this API"),
-    cluster: zod
-        .string()
-        .describe("The cluster name some client libraries require; empty when the deployment does not use one"),
-    enabled: zod
-        .boolean()
-        .describe("False when realtime delivery is not configured in this deployment. Every other field is empty and clients should not attempt to connect"),
-    host: zod.string(),
-    key: zod
-        .string()
-        .describe("The application key, which is public and identifies the deployment rather than the caller"),
-    port: zod.int(),
-    announcements_channel: zod
-        .string()
-        .describe("The channel carrying announcements. It is public: subscribing to it needs no\nauthorization, because an announcement is addressed to everybody. The events on it\ncarry an identifier and nothing else, so a client fetches the list and sees the\nannouncements it is entitled to"),
-    project_channel: zod
-        .string()
-        .describe("The channel carrying events about the project in the token; empty when the token names no project"),
-    secure: zod.boolean().describe("Whether to connect over TLS"),
-    user_channel: zod.string().describe("The channel carrying events addressed to you"),
-})
-    .describe("Everything needed to open a realtime connection. The connection speaks the Pusher channels\nprotocol, so any client library for it works.");