@zitadel/api 0.0.0 → 0.1.0-alpha.10

package/{dist/generated/model/getFlowStep200StepGatesKind.d.ts → src/generated/model/createFlowDefinition201FlowDefinitionStepsItemGatesKind.ts}

@@ -5,14 +5,16 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+
 /**
  * The gate category. Only `captcha` is currently defined. Authenticator
 ceremonies (e.g. passkey) are modelled as credential auth_attempts via
 `x-credential` on a field, not as gates.
 
  */
-export type GetFlowStep200StepGatesKind = (typeof GetFlowStep200StepGatesKind)[keyof typeof GetFlowStep200StepGatesKind];
-export declare const GetFlowStep200StepGatesKind: {
-    readonly captcha: "captcha";
-};
-//# sourceMappingURL=getFlowStep200StepGatesKind.d.ts.map
+export type CreateFlowDefinition201FlowDefinitionStepsItemGatesKind =
+  (typeof CreateFlowDefinition201FlowDefinitionStepsItemGatesKind)[keyof typeof CreateFlowDefinition201FlowDefinitionStepsItemGatesKind];
+
+export const CreateFlowDefinition201FlowDefinitionStepsItemGatesKind = {
+  captcha: "captcha",
+} as const;

package/{dist/generated/model/updateFlowDefinitionBodyStepsItemOnSuccess.d.ts → src/generated/model/createFlowDefinition201FlowDefinitionStepsItemOnSuccess.ts}

@@ -5,6 +5,7 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+
 /**
  * Server-side mutation to execute when this step completes successfully.
 Runs after field validation passes, before the transition fires.
@@ -12,8 +13,9 @@ Runs after field validation passes, before the transition fires.
 - create_user: creates the user record (registration flows)
 
  */
-export type UpdateFlowDefinitionBodyStepsItemOnSuccess = (typeof UpdateFlowDefinitionBodyStepsItemOnSuccess)[keyof typeof UpdateFlowDefinitionBodyStepsItemOnSuccess];
-export declare const UpdateFlowDefinitionBodyStepsItemOnSuccess: {
-    readonly create_user: "create_user";
-};
-//# sourceMappingURL=updateFlowDefinitionBodyStepsItemOnSuccess.d.ts.map
+export type CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess =
+  (typeof CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess)[keyof typeof CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess];
+
+export const CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess = {
+  create_user: "create_user",
+} as const;

package/src/generated/model/createFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem.ts

@@ -0,0 +1,19 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+
+/**
+ * An available SSO identity provider.
+ */
+export type CreateFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem = {
+  /** Provider instance identifier. */
+  id: string;
+  /** Display name for the provider. */
+  name: string;
+  /** Template hint for rendering (logo, colors). */
+  template: string;
+};

package/src/generated/model/createFlowDefinition201FlowDefinitionStepsItemTransitions.ts

@@ -0,0 +1,35 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+
+/**
+ * Maps action/outcome names to their transition descriptor.
+
+Keys match action names from the `actions` array. Additional keys
+come from implicit outcomes based on schema annotations
+(e.g. `user_not_found` from `x-unique` fields) and engine
+events (e.g. `sso`, `callback`).
+
+ */
+export type CreateFlowDefinition201FlowDefinitionStepsItemTransitions = {
+  [key: string]: {
+    /** Step name within this flow (when `action` is null), or the name
+  of another flow (when `action` is `switch` or `pivot`).
+   */
+    target: string;
+    /** How to interpret `target`:
+  - null (omitted): transition to a step in the current flow.
+  - switch: replace the current flow with the target flow.
+    No return — the current flow is discarded.
+    Example: login ↔ register.
+  - pivot: push the target flow onto the stack. The current flow
+    is paused and resumes when the target flow completes (auto-pop).
+    Example: login → recovery → back to login.
+   */
+    action?: "switch" | "pivot" | null;
+  };
+};

package/src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItem.ts

@@ -5,7 +5,7 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
-import type { CreateFlowDefinitionBodyFlowDefinitionStepsItemActions } from "./createFlowDefinitionBodyFlowDefinitionStepsItemActions";
+import type { CreateFlowDefinitionBodyFlowDefinitionStepsItemActionsItem } from "./createFlowDefinitionBodyFlowDefinitionStepsItemActionsItem";
 import type { CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete } from "./createFlowDefinitionBodyFlowDefinitionStepsItemComplete";
 import type { CreateFlowDefinitionBodyFlowDefinitionStepsItemGates } from "./createFlowDefinitionBodyFlowDefinitionStepsItemGates";
 import type { CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess } from "./createFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess";
@@ -36,11 +36,11 @@ export type CreateFlowDefinitionBodyFlowDefinitionStepsItem = {
   transition outcome).
    */
   fields?: string[];
-  /** Actions the user can take. Keyed by action name.
-  The action name is what the frontend sends back in the submit request.
-  If omitted, the engine provides a default `submit` action.
+  /** Ordered list of actions the user can take. The action name is what the
+  frontend sends back in the submit request. If omitted, the engine
+  provides a default `submit` action.
    */
-  actions?: CreateFlowDefinitionBodyFlowDefinitionStepsItemActions;
+  actions?: CreateFlowDefinitionBodyFlowDefinitionStepsItemActionsItem[];
   /** Security gates that must be satisfied before submission. Keyed by gate
   name. Each gate selects a kind (e.g. "captcha") and provider-specific
   configuration. The engine may also inject gates dynamically based on
@@ -62,7 +62,7 @@ export type CreateFlowDefinitionBodyFlowDefinitionStepsItem = {
   complete?: CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete;
   /** Maps action/outcome names to their transition descriptor.
 
-  Keys match action names from the `actions` dict. Additional keys
+  Keys match action names from the `actions` array. Additional keys
   come from implicit outcomes based on schema annotations
   (e.g. `user_not_found` from `x-unique` fields) and engine
   events (e.g. `sso`, `callback`).

package/src/generated/model/{createFlowDefinitionBodyFlowDefinitionStepsItemActions.ts → createFlowDefinitionBodyFlowDefinitionStepsItemActionsItem.ts}

@@ -7,23 +7,22 @@
  */
 
 /**
- * Actions the user can take. Keyed by action name.
-The action name is what the frontend sends back in the submit request.
-If omitted, the engine provides a default `submit` action.
+ * Configuration for a user-invokable action on a step. The `name` is sent
+back in the submit request as `action`.
 
  */
-export type CreateFlowDefinitionBodyFlowDefinitionStepsItemActions = {
-  [key: string]: {
-    /** Marks this as the default/primary action. The runtime template uses
+export type CreateFlowDefinitionBodyFlowDefinitionStepsItemActionsItem = {
+  /** Action identifier. Sent back in the submit request as `action`. */
+  name: string;
+  /** Marks this as the default/primary action. The runtime template uses
   this hint to choose visual emphasis. At most one action per step
   should be primary; this is not enforced here.
    */
-    primary?: boolean;
-    /** Optional localization key override for the action's label. When
+  primary?: boolean;
+  /** Optional localization key override for the action's label. When
   omitted, the engine derives a key from the step and action names.
   Display text is resolved client-side from a locale dictionary, never
   by the engine.
    */
-    text_key?: string;
-  };
+  text_key?: string;
 };

package/src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemTransitions.ts

@@ -9,7 +9,7 @@
 /**
  * Maps action/outcome names to their transition descriptor.
 
-Keys match action names from the `actions` dict. Additional keys
+Keys match action names from the `actions` array. Additional keys
 come from implicit outcomes based on schema annotations
 (e.g. `user_not_found` from `x-unique` fields) and engine
 events (e.g. `sso`, `callback`).

package/{dist/generated/model/listUsers200Item.d.ts → src/generated/model/deleteFlowDefinitionParams.ts}

@@ -5,7 +5,11 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
-export type ListUsers200Item = {
-    [key: string]: unknown;
+
+export type DeleteFlowDefinitionParams = {
+  /**
+   * The project id to filter by.
+   * @pattern ^[a-zA-Z0-9_-]+$
+   */
+  project_id: string;
 };
-//# sourceMappingURL=listUsers200Item.d.ts.map

package/src/generated/model/getFlowDefinition200.ts

@@ -5,158 +5,25 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+import type { GetFlowDefinition200FlowDefinition } from "./getFlowDefinition200FlowDefinition";
 
 export type GetFlowDefinition200 = {
-  /**
-     * Stable identifier for this flow, used as the target of cross-flow
-  `switch` and `pivot` transitions. Renaming is not supported — the
-  `name` is part of the public contract another definition may
-  reference. Acts as the human display label as well; no separate slug.
-
-     * @pattern ^[a-z][a-z0-9-]*$
-     */
-  name: string;
-  /** User schema this flow operates on. Step `fields` reference properties
-  defined in this schema. The engine resolves field types, validation,
-  and implicit outcomes from schema annotations at runtime.
-   */
-  user_schema: string;
-  /** Maps each purpose this definition handles to its entry-point step.
-  Keys are purpose names; values must match a `name` in `steps`. A
-  definition can serve multiple purposes (e.g. a combined login/register
-  flow) by listing one entry per purpose.
-   */
-  purposes: Partial<
-    Record<"login" | "register" | "recovery" | "profiling" | "reauth" | "link_account", string>
-  >;
-  /** Scopes which teams or apps this flow definition applies to. Empty or
-  omitted fields mean "no restriction"; when both are empty the definition
-  matches every request in the project. The engine picks the most specific
-  matching definition: app > team > project-wide.
-   */
-  audience?: {
-    /** Restrict to specific teams (organizations). Empty means no team restriction. */
-    team_ids?: string[];
-    /** Restrict to specific applications. Empty means no app restriction. */
-    app_ids?: string[];
-  };
-  /**
-     * Ordered list of steps in this flow. The order is for human readability —
-  actual step sequencing is determined by transitions.
-
-     * @minItems 1
-     */
-  steps: {
-    /** Unique step identifier within this flow. Used as transition targets
-  and returned in the API response as `step.name`.
-   */
-    name: string;
-    /** Schema property names to collect from the user. Each entry references
-  a property in the flow's user schema. The engine resolves field type,
-  validation rules, and implicit outcomes from schema annotations
-  (e.g. a property with `x-unique` set implies a `user_not_found`
-  transition outcome).
-   */
-    fields?: string[];
-    /** Actions the user can take. Keyed by action name.
-  The action name is what the frontend sends back in the submit request.
-  If omitted, the engine provides a default `submit` action.
-   */
-    actions?: {
-      [key: string]: {
-        /** Marks this as the default/primary action. The runtime template uses
-  this hint to choose visual emphasis. At most one action per step
-  should be primary; this is not enforced here.
-   */
-        primary?: boolean;
-        /** Optional localization key override for the action's label. When
-  omitted, the engine derives a key from the step and action names.
-  Display text is resolved client-side from a locale dictionary, never
-  by the engine.
-   */
-        text_key?: string;
-      };
-    };
-    /** Security gates that must be satisfied before submission. Keyed by gate
-  name. Each gate selects a kind (e.g. "captcha") and provider-specific
-  configuration. The engine may also inject gates dynamically based on
-  policy.
-   */
-    gates?: {
-      [key: string]: {
-        /** The gate category. Only `captcha` is currently defined. Authenticator
-  ceremonies (e.g. passkey) are modelled as credential auth_attempts via
-  `x-credential` on a field, not as gates.
-   */
-        kind: "captcha";
-        /** Provider identifier within the gate kind — e.g. `altcha`, `turnstile`,
-  `hcaptcha`. The engine looks up an implementation in its provider
-  registry.
-   */
-        provider: string;
-        /** Provider-specific configuration consumed by the implementation when
-  issuing the per-render challenge. Opaque to the engine.
-   */
-        config?: { [key: string]: unknown };
-      };
-    };
-    /** Available SSO identity providers for this step. */
-    sso_providers?: {
-      /** Provider instance identifier. */
-      id: string;
-      /** Display name for the provider. */
-      name: string;
-      /** Template hint for rendering (logo, colors). */
-      template: string;
-    }[];
-    /** Server-side mutation to execute when this step completes successfully.
-  Runs after field validation passes, before the transition fires.
-
-  - create_user: creates the user record (registration flows)
-   */
-    on_success?: "create_user";
-    /** Marks this as a terminal step. Tells the frontend what to do:
-  - redirect: navigate to redirect_uri (OIDC/SAML callback done)
-  - show: render as a success/info screen
-   */
-    complete?: "redirect" | "show";
-    /** Maps action/outcome names to their transition descriptor.
-
-  Keys match action names from the `actions` dict. Additional keys
-  come from implicit outcomes based on schema annotations
-  (e.g. `user_not_found` from `x-unique` fields) and engine
-  events (e.g. `sso`, `callback`).
-   */
-    transitions?: {
-      [key: string]: {
-        /** Step name within this flow (when `action` is null), or the name
-  of another flow (when `action` is `switch` or `pivot`).
-   */
-        target: string;
-        /** How to interpret `target`:
-  - null (omitted): transition to a step in the current flow.
-  - switch: replace the current flow with the target flow.
-    No return — the current flow is discarded.
-    Example: login ↔ register.
-  - pivot: push the target flow onto the stack. The current flow
-    is paused and resumes when the target flow completes (auto-pop).
-    Example: login → recovery → back to login.
-   */
-        action?: "switch" | "pivot" | null;
-      };
-    };
-  }[];
-} & {
   /** Unique identifier for the flow definition. */
   id: string;
   /** Identifier of the project this flow definition belongs to. */
   project_id: string;
-  /** URI of the flow definition schema this definition was authored against.
-  If the schema_uri was not provided in the request, the flow definition is validated against the latest version of the schema, and the response includes the schema_uri of the latest version.
-   */
-  schema_uri: string;
   /** Status of the flow definition. */
   status: string;
+  /** A flow definition is the server-side configuration that describes a complete
+  authentication or identity flow. It is NOT sent to the frontend — the flow
+  engine evaluates it and produces FlowResponse payloads (steps with capability
+  dictionaries) for the client.
+
+  Flow definitions are created by administrators and stored in the project/team
+  configuration hierarchy. The engine selects the matching definition based on
+  the purpose + audience when a flow is created via POST /flow.
+   */
+  flow_definition: GetFlowDefinition200FlowDefinition;
   created_at: string;
   updated_at: string;
 };

package/src/generated/model/getFlowDefinition200FlowDefinition.ts

@@ -0,0 +1,58 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { GetFlowDefinition200FlowDefinitionAudience } from "./getFlowDefinition200FlowDefinitionAudience";
+import type { GetFlowDefinition200FlowDefinitionStepsItem } from "./getFlowDefinition200FlowDefinitionStepsItem";
+
+/**
+ * A flow definition is the server-side configuration that describes a complete
+authentication or identity flow. It is NOT sent to the frontend — the flow
+engine evaluates it and produces FlowResponse payloads (steps with capability
+dictionaries) for the client.
+
+Flow definitions are created by administrators and stored in the project/team
+configuration hierarchy. The engine selects the matching definition based on
+the purpose + audience when a flow is created via POST /flow.
+
+ */
+export type GetFlowDefinition200FlowDefinition = {
+  /**
+     * Stable identifier for this flow, used as the target of cross-flow
+  `switch` and `pivot` transitions. Renaming is not supported — the
+  `name` is part of the public contract another definition may
+  reference. Acts as the human display label as well; no separate slug.
+
+     * @pattern ^[a-z][a-z0-9-]*$
+     */
+  name: string;
+  /** User schema this flow operates on. Step `fields` reference properties
+  defined in this schema. The engine resolves field types, validation,
+  and implicit outcomes from schema annotations at runtime.
+   */
+  user_schema: string;
+  /** Maps each purpose this definition handles to its entry-point step.
+  Keys are purpose names; values must match a `name` in `steps`. A
+  definition can serve multiple purposes (e.g. a combined login/register
+  flow) by listing one entry per purpose.
+   */
+  purposes: Partial<
+    Record<"login" | "register" | "recovery" | "profiling" | "reauth" | "link_account", string>
+  >;
+  /** Scopes which teams or apps this flow definition applies to. Empty or
+  omitted fields mean "no restriction"; when both are empty the definition
+  matches every request in the project. The engine picks the most specific
+  matching definition: app > team > project-wide.
+   */
+  audience?: GetFlowDefinition200FlowDefinitionAudience;
+  /**
+     * Ordered list of steps in this flow. The order is for human readability —
+  actual step sequencing is determined by transitions.
+
+     * @minItems 1
+     */
+  steps: GetFlowDefinition200FlowDefinitionStepsItem[];
+};

package/{dist/generated/model/createFlowDefinitionBodyFlowDefinitionAudience.d.ts → src/generated/model/getFlowDefinition200FlowDefinitionAudience.ts}

@@ -5,6 +5,7 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+
 /**
  * Scopes which teams or apps this flow definition applies to. Empty or
 omitted fields mean "no restriction"; when both are empty the definition
@@ -12,10 +13,9 @@ matches every request in the project. The engine picks the most specific
 matching definition: app > team > project-wide.
 
  */
-export type CreateFlowDefinitionBodyFlowDefinitionAudience = {
-    /** Restrict to specific teams (organizations). Empty means no team restriction. */
-    team_ids?: string[];
-    /** Restrict to specific applications. Empty means no app restriction. */
-    app_ids?: string[];
+export type GetFlowDefinition200FlowDefinitionAudience = {
+  /** Restrict to specific teams (organizations). Empty means no team restriction. */
+  team_ids?: string[];
+  /** Restrict to specific applications. Empty means no app restriction. */
+  app_ids?: string[];
 };
-//# sourceMappingURL=createFlowDefinitionBodyFlowDefinitionAudience.d.ts.map

package/src/generated/model/getFlowDefinition200FlowDefinitionStepsItem.ts

@@ -0,0 +1,71 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { GetFlowDefinition200FlowDefinitionStepsItemActionsItem } from "./getFlowDefinition200FlowDefinitionStepsItemActionsItem";
+import type { GetFlowDefinition200FlowDefinitionStepsItemComplete } from "./getFlowDefinition200FlowDefinitionStepsItemComplete";
+import type { GetFlowDefinition200FlowDefinitionStepsItemGates } from "./getFlowDefinition200FlowDefinitionStepsItemGates";
+import type { GetFlowDefinition200FlowDefinitionStepsItemOnSuccess } from "./getFlowDefinition200FlowDefinitionStepsItemOnSuccess";
+import type { GetFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem } from "./getFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem";
+import type { GetFlowDefinition200FlowDefinitionStepsItemTransitions } from "./getFlowDefinition200FlowDefinitionStepsItemTransitions";
+
+/**
+ * A step in a flow definition. This is the admin-authored configuration,
+not the runtime payload sent to the frontend.
+
+Steps are schema-driven: `fields` references properties from the flow's
+user schema, and the engine resolves field metadata (type, validation,
+implicit outcomes) from schema annotations at runtime.
+
+A step with only `complete` set is a terminal step. All other steps are
+rendered to the frontend as capability payloads.
+
+ */
+export type GetFlowDefinition200FlowDefinitionStepsItem = {
+  /** Unique step identifier within this flow. Used as transition targets
+  and returned in the API response as `step.name`.
+   */
+  name: string;
+  /** Schema property names to collect from the user. Each entry references
+  a property in the flow's user schema. The engine resolves field type,
+  validation rules, and implicit outcomes from schema annotations
+  (e.g. a property with `x-unique` set implies a `user_not_found`
+  transition outcome).
+   */
+  fields?: string[];
+  /** Ordered list of actions the user can take. The action name is what the
+  frontend sends back in the submit request. If omitted, the engine
+  provides a default `submit` action.
+   */
+  actions?: GetFlowDefinition200FlowDefinitionStepsItemActionsItem[];
+  /** Security gates that must be satisfied before submission. Keyed by gate
+  name. Each gate selects a kind (e.g. "captcha") and provider-specific
+  configuration. The engine may also inject gates dynamically based on
+  policy.
+   */
+  gates?: GetFlowDefinition200FlowDefinitionStepsItemGates;
+  /** Available SSO identity providers for this step. */
+  sso_providers?: GetFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem[];
+  /** Server-side mutation to execute when this step completes successfully.
+  Runs after field validation passes, before the transition fires.
+
+  - create_user: creates the user record (registration flows)
+   */
+  on_success?: GetFlowDefinition200FlowDefinitionStepsItemOnSuccess;
+  /** Marks this as a terminal step. Tells the frontend what to do:
+  - redirect: navigate to redirect_uri (OIDC/SAML callback done)
+  - show: render as a success/info screen
+   */
+  complete?: GetFlowDefinition200FlowDefinitionStepsItemComplete;
+  /** Maps action/outcome names to their transition descriptor.
+
+  Keys match action names from the `actions` array. Additional keys
+  come from implicit outcomes based on schema annotations
+  (e.g. `user_not_found` from `x-unique` fields) and engine
+  events (e.g. `sso`, `callback`).
+   */
+  transitions?: GetFlowDefinition200FlowDefinitionStepsItemTransitions;
+};

package/src/generated/model/getFlowDefinition200FlowDefinitionStepsItemActionsItem.ts

@@ -0,0 +1,28 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+
+/**
+ * Configuration for a user-invokable action on a step. The `name` is sent
+back in the submit request as `action`.
+
+ */
+export type GetFlowDefinition200FlowDefinitionStepsItemActionsItem = {
+  /** Action identifier. Sent back in the submit request as `action`. */
+  name: string;
+  /** Marks this as the default/primary action. The runtime template uses
+  this hint to choose visual emphasis. At most one action per step
+  should be primary; this is not enforced here.
+   */
+  primary?: boolean;
+  /** Optional localization key override for the action's label. When
+  omitted, the engine derives a key from the step and action names.
+  Display text is resolved client-side from a locale dictionary, never
+  by the engine.
+   */
+  text_key?: string;
+};

package/src/generated/model/getFlowDefinition200FlowDefinitionStepsItemComplete.ts

@@ -0,0 +1,21 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+
+/**
+ * Marks this as a terminal step. Tells the frontend what to do:
+- redirect: navigate to redirect_uri (OIDC/SAML callback done)
+- show: render as a success/info screen
+
+ */
+export type GetFlowDefinition200FlowDefinitionStepsItemComplete =
+  (typeof GetFlowDefinition200FlowDefinitionStepsItemComplete)[keyof typeof GetFlowDefinition200FlowDefinitionStepsItemComplete];
+
+export const GetFlowDefinition200FlowDefinitionStepsItemComplete = {
+  redirect: "redirect",
+  show: "show",
+} as const;

package/src/generated/model/getFlowDefinition200FlowDefinitionStepsItemGates.ts

@@ -0,0 +1,35 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { GetFlowDefinition200FlowDefinitionStepsItemGatesConfig } from "./getFlowDefinition200FlowDefinitionStepsItemGatesConfig";
+import type { GetFlowDefinition200FlowDefinitionStepsItemGatesKind } from "./getFlowDefinition200FlowDefinitionStepsItemGatesKind";
+
+/**
+ * Security gates that must be satisfied before submission. Keyed by gate
+name. Each gate selects a kind (e.g. "captcha") and provider-specific
+configuration. The engine may also inject gates dynamically based on
+policy.
+
+ */
+export type GetFlowDefinition200FlowDefinitionStepsItemGates = {
+  [key: string]: {
+    /** The gate category. Only `captcha` is currently defined. Authenticator
+  ceremonies (e.g. passkey) are modelled as credential auth_attempts via
+  `x-credential` on a field, not as gates.
+   */
+    kind: GetFlowDefinition200FlowDefinitionStepsItemGatesKind;
+    /** Provider identifier within the gate kind — e.g. `altcha`, `turnstile`,
+  `hcaptcha`. The engine looks up an implementation in its provider
+  registry.
+   */
+    provider: string;
+    /** Provider-specific configuration consumed by the implementation when
+  issuing the per-render challenge. Opaque to the engine.
+   */
+    config?: GetFlowDefinition200FlowDefinitionStepsItemGatesConfig;
+  };
+};

package/{dist/generated/model/getFlowStep200StepGatesConfig.d.ts → src/generated/model/getFlowDefinition200FlowDefinitionStepsItemGatesConfig.ts}

@@ -5,12 +5,10 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+
 /**
  * Provider-specific configuration consumed by the implementation when
 issuing the per-render challenge. Opaque to the engine.
 
  */
-export type GetFlowStep200StepGatesConfig = {
-    [key: string]: unknown;
-};
-//# sourceMappingURL=getFlowStep200StepGatesConfig.d.ts.map
+export type GetFlowDefinition200FlowDefinitionStepsItemGatesConfig = { [key: string]: unknown };

package/{dist/generated/model/createFlow201StepGatesKind.d.ts → src/generated/model/getFlowDefinition200FlowDefinitionStepsItemGatesKind.ts}

@@ -5,14 +5,16 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+
 /**
  * The gate category. Only `captcha` is currently defined. Authenticator
 ceremonies (e.g. passkey) are modelled as credential auth_attempts via
 `x-credential` on a field, not as gates.
 
  */
-export type CreateFlow201StepGatesKind = (typeof CreateFlow201StepGatesKind)[keyof typeof CreateFlow201StepGatesKind];
-export declare const CreateFlow201StepGatesKind: {
-    readonly captcha: "captcha";
-};
-//# sourceMappingURL=createFlow201StepGatesKind.d.ts.map
+export type GetFlowDefinition200FlowDefinitionStepsItemGatesKind =
+  (typeof GetFlowDefinition200FlowDefinitionStepsItemGatesKind)[keyof typeof GetFlowDefinition200FlowDefinitionStepsItemGatesKind];
+
+export const GetFlowDefinition200FlowDefinitionStepsItemGatesKind = {
+  captcha: "captcha",
+} as const;