@zitadel/components 0.1.0-alpha.0 → 0.1.0-alpha.11

package/dist/{index-Dd8hfOWt.d.mts → index-DVDCrfkv.d.mts}

@@ -168,12 +168,28 @@ declare class ZlButton extends LitElement {
   accessor disabled: boolean;
   accessor block: boolean;
   accessor label: string | undefined;
+  accessor testId: string | undefined;
+  /**
+   * Forces a visual interaction state on the inner button, projected to its
+   * `data-state` attribute. Used by the design playground to capture
+   * hover/pressed/focus states; reactive so toggling the host attribute
+   * re-renders.
+   */
+  accessor forcedState: string | null;
   private readonly internals;
   constructor();
+  connectedCallback(): void;
+  disconnectedCallback(): void;
   focus(options?: FocusOptions): void;
-  private surfaceClasses;
   render(): _$lit.TemplateResult<1>;
   private handleClick;
+  private handleHostClick;
+  private nativeButtonTestId;
+  private buttonType;
+  private buttonAction;
+  private activate;
+  private stringOption;
+  private booleanOption;
 }
 declare const zlButtonManifest: AtomManifest;
 declare global {
@@ -217,6 +233,13 @@ declare class ZlCard extends LitElement {
   static styles: _$lit.CSSResult[];
   accessor compact: boolean;
   render(): _$lit.TemplateResult<1>;
+  /**
+   * `lightDomSlotFilled` is a render-time snapshot, so re-run render whenever a
+   * named slot's assignment changes (e.g. a header added after first paint).
+   * The initial render still reads children synchronously, avoiding the
+   * empty-then-filled flash a slotchange-only approach would introduce.
+   */
+  private onSlotChange;
   /** Slotted nodes are always light-DOM children of the host in our templates. */
   private lightDomSlotFilled;
 }
@@ -227,7 +250,7 @@ declare global {
   }
 } //# sourceMappingURL=zl-card.d.ts.map
 //#endregion
-//#region ../api/dist/index-DlEenfQJ.d.mts
+//#region ../api/dist/index-BGnjxx-b.d.mts
 //#region src/generated/model/authorizeDevice200.d.ts
 /**
  * Generated by orval v8.10.0 🍺
@@ -773,7 +796,7 @@ type CreateFlow201Branding = {
   font_url?: string; /** Hero/background image URL (used by split layout). */
   hero_url?: string;
 }; //#endregion
-//#region src/generated/model/createFlow201StepActions.d.ts
+//#region src/generated/model/createFlow201StepActionsItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -782,24 +805,23 @@ type CreateFlow201Branding = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * Unordered dictionary of available user actions. Keyed by action name.
-The LiquidJS template controls positioning and presentation.
+ * Configuration for a user-invokable action on a step. The `name` is sent
+back in the submit request as `action`.
 
  */
-type CreateFlow201StepActions = {
-  [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;
-  };
+type CreateFlow201StepActionsItem = {
+  /** 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;
 }; //#endregion
 //#region src/generated/model/createFlow201StepChallengeMethod.d.ts
 /**
@@ -877,7 +899,7 @@ declare const CreateFlow201StepComplete: {
   readonly redirect: "redirect";
   readonly show: "show";
 }; //#endregion
-//#region src/generated/model/createFlow201StepFieldsType.d.ts
+//#region src/generated/model/createFlow201StepFieldsItemType.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -886,14 +908,15 @@ declare const CreateFlow201StepComplete: {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * The input kind the client should render. Encodes the formats that
-have a matching HTML input type (email, url, date). For other
-formats (e.g. uuid) the type is `text` and `validation.format`
-carries the rule.
+ * The input kind the client should render. Encodes the formats and
+JSON types that map to a familiar HTML input: `email`, `url`,
+`date` come from `format`; `checkbox` from JSON `type: boolean`;
+`select` from a closed `enum`. For other formats (e.g. uuid) the
+type is `text` and `validation.format` carries the rule.
 
  */
-type CreateFlow201StepFieldsType = (typeof CreateFlow201StepFieldsType)[keyof typeof CreateFlow201StepFieldsType];
-declare const CreateFlow201StepFieldsType: {
+type CreateFlow201StepFieldsItemType = (typeof CreateFlow201StepFieldsItemType)[keyof typeof CreateFlow201StepFieldsItemType];
+declare const CreateFlow201StepFieldsItemType: {
   readonly text: "text";
   readonly email: "email";
   readonly password: "password";
@@ -902,8 +925,10 @@ declare const CreateFlow201StepFieldsType: {
   readonly url: "url";
   readonly date: "date";
   readonly hidden: "hidden";
+  readonly checkbox: "checkbox";
+  readonly select: "select";
 }; //#endregion
-//#region src/generated/model/createFlow201StepFieldsValidationFormat.d.ts
+//#region src/generated/model/createFlow201StepFieldsItemValidationFormat.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -919,14 +944,14 @@ sufficient for client-side validation. When `type` is `text`
 (e.g. `format: uuid`), this key is the only signal.
 
  */
-type CreateFlow201StepFieldsValidationFormat = (typeof CreateFlow201StepFieldsValidationFormat)[keyof typeof CreateFlow201StepFieldsValidationFormat];
-declare const CreateFlow201StepFieldsValidationFormat: {
+type CreateFlow201StepFieldsItemValidationFormat = (typeof CreateFlow201StepFieldsItemValidationFormat)[keyof typeof CreateFlow201StepFieldsItemValidationFormat];
+declare const CreateFlow201StepFieldsItemValidationFormat: {
   readonly email: "email";
   readonly "date-time": "date-time";
   readonly uuid: "uuid";
   readonly uri: "uri";
 }; //#endregion
-//#region src/generated/model/createFlow201StepFieldsValidation.d.ts
+//#region src/generated/model/createFlow201StepFieldsItemValidation.d.ts
 /**
  * Schema-derived rules the frontend SHOULD apply at input time. The
 server runs the same rules on submit and is the only authority on
@@ -938,14 +963,14 @@ Each key mirrors a JSON Schema keyword on the underlying user
 property; absent keys mean no rule.
 
  */
-type CreateFlow201StepFieldsValidation = {
+type CreateFlow201StepFieldsItemValidation = {
   /** Semantic format the value must match. Values mirror the user
   meta-schema. When `type` already encodes the format (email,
   url, date), this key is informative and the input type is
   sufficient for client-side validation. When `type` is `text`
   (e.g. `format: uuid`), this key is the only signal.
    */
-  format?: CreateFlow201StepFieldsValidationFormat;
+  format?: CreateFlow201StepFieldsItemValidationFormat;
   /**
    * Minimum length in characters (inclusive). Mirrors `minLength`.
    * @minimum 0
@@ -956,39 +981,46 @@ type CreateFlow201StepFieldsValidation = {
    * @minimum 0
    */
   max_length?: number;
+  /** Closed list of allowed values. Mirrors the JSON Schema `enum`
+  keyword on the underlying user property. When `type` is
+  `select` the client renders these as options; for other types
+  the rule still applies as a membership check.
+   */
+  enum?: string[];
 }; //#endregion
-//#region src/generated/model/createFlow201StepFields.d.ts
+//#region src/generated/model/createFlow201StepFieldsItem.d.ts
 /**
- * Unordered dictionary of input fields to collect. Keyed by field name.
-The LiquidJS template controls which fields appear and in what order.
-Field metadata (type, validation) is resolved by the engine from the
-flow's user schema.
+ * A data input capability. Describes what the user must provide.
+Does not contain display text — only a `text_key` resolved client-side.
 
  */
-type CreateFlow201StepFields = {
-  [key: string]: {
-    /** The input kind the client should render. Encodes the formats that
-    have a matching HTML input type (email, url, date). For other
-    formats (e.g. uuid) the type is `text` and `validation.format`
-    carries the rule.
-    */
-    type: CreateFlow201StepFieldsType; /** Localization key for the field label. */
-    text_key: string;
-    /** The field MUST be present and non-empty on submit. Mirrors the
-    schema's top-level `required` array.
-    */
-    required?: boolean; /** Pre-filled value (e.g., an identifier carried over from a pivot). */
-    value?: unknown;
-    /** Schema-derived rules the frontend SHOULD apply at input time. The
-    server runs the same rules on submit and is the only authority on
-    whether the step advances — these rules are a UX hint to reduce
-    round trips, not a contract guarantee.
-       Omitted entirely when the field has no rules beyond its `type`.
-    Each key mirrors a JSON Schema keyword on the underlying user
-    property; absent keys mean no rule.
-    */
-    validation?: CreateFlow201StepFieldsValidation;
-  };
+type CreateFlow201StepFieldsItem = {
+  /** Field name, matching a property in the flow's user schema. Carries
+  the submitted value back to the engine.
+   */
+  name: string;
+  /** The input kind the client should render. Encodes the formats and
+  JSON types that map to a familiar HTML input: `email`, `url`,
+  `date` come from `format`; `checkbox` from JSON `type: boolean`;
+  `select` from a closed `enum`. For other formats (e.g. uuid) the
+  type is `text` and `validation.format` carries the rule.
+   */
+  type: CreateFlow201StepFieldsItemType; /** Localization key for the field label. */
+  text_key: string;
+  /** The field MUST be present and non-empty on submit. Mirrors the
+  schema's top-level `required` array.
+   */
+  required?: boolean; /** Pre-filled value (e.g., an identifier carried over from a pivot). */
+  value?: unknown;
+  /** Schema-derived rules the frontend SHOULD apply at input time. The
+  server runs the same rules on submit and is the only authority on
+  whether the step advances — these rules are a UX hint to reduce
+  round trips, not a contract guarantee.
+     Omitted entirely when the field has no rules beyond its `type`.
+  Each key mirrors a JSON Schema keyword on the underlying user
+  property; absent keys mean no rule.
+   */
+  validation?: CreateFlow201StepFieldsItemValidation;
 }; //#endregion
 //#region src/generated/model/createFlow201StepGatesConfig.d.ts
 /**
@@ -1084,9 +1116,10 @@ type CreateFlow201StepTexts = {
 }; //#endregion
 //#region src/generated/model/createFlow201Step.d.ts
 /**
- * A step contains unordered capability dictionaries: what to collect (fields),
+ * A step contains ordered capability arrays: what to collect (fields),
 what the user can do (actions), and what security gates must be satisfied (gates).
-Layout and element ordering are controlled by the LiquidJS template in `branding.liquid_template`.
+The LiquidJS template in `branding.liquid_template` iterates these arrays in order
+and builds name-keyed indexes locally for lookup.
 
  */
 type CreateFlow201Step = {
@@ -1102,16 +1135,16 @@ type CreateFlow201Step = {
    */
   complete?: CreateFlow201StepComplete; /** URL to navigate to (e.g., SSO provider redirect). */
   redirect_url?: string;
-  /** Unordered dictionary of input fields to collect. Keyed by field name.
-  The LiquidJS template controls which fields appear and in what order.
-  Field metadata (type, validation) is resolved by the engine from the
-  flow's user schema.
+  /** Ordered list of input fields to collect. Field metadata (type, validation)
+  is resolved by the engine from the flow's user schema. The LiquidJS
+  template iterates this array; for keyed lookup it builds a name-indexed
+  map locally.
    */
-  fields: CreateFlow201StepFields;
-  /** Unordered dictionary of available user actions. Keyed by action name.
-  The LiquidJS template controls positioning and presentation.
+  fields: CreateFlow201StepFieldsItem[];
+  /** Ordered list of available user actions. The LiquidJS template iterates
+  this array and builds a name-indexed map locally for keyed lookup.
    */
-  actions: CreateFlow201StepActions;
+  actions: CreateFlow201StepActionsItem[];
   /** Security gates that must be satisfied before the step can be submitted.
   The engine injects gates dynamically based on policy, even if they
   are not declared in the flow definition.
@@ -1136,9 +1169,10 @@ type CreateFlow201 = {
   id: string; /** Underlying session ID. Stable across all stacked flows. */
   session_id: string; /** Reserved for future rotation. The sealed `_zflow` cookie carries the flow state today. */
   session_token?: string;
-  /** A step contains unordered capability dictionaries: what to collect (fields),
+  /** A step contains ordered capability arrays: what to collect (fields),
   what the user can do (actions), and what security gates must be satisfied (gates).
-  Layout and element ordering are controlled by the LiquidJS template in `branding.liquid_template`.
+  The LiquidJS template in `branding.liquid_template` iterates these arrays in order
+  and builds name-keyed indexes locally for lookup.
    */
   step: CreateFlow201Step;
   /** Resolved branding configuration. Inherited from the app → team → project
@@ -1242,168 +1276,7 @@ type CreateFlowBody = {
  * Additional error-specific context.
  */
 //#endregion
-//#region src/generated/model/createFlowDefinition201.d.ts
-/**
- * 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
- */
-type CreateFlowDefinition201 = {
-  /**
-     * 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;
-  created_at: string;
-  updated_at: string;
-}; //#endregion
-//#region src/generated/model/createFlowDefinition400Details.d.ts
-/**
- * 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
- */
-/**
- * Additional error-specific context.
- */
-//#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionAudience.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionAudience.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1418,11 +1291,11 @@ matches every request in the project. The engine picks the most specific
 matching definition: app > team > project-wide.
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionAudience = {
+type CreateFlowDefinition201FlowDefinitionAudience = {
   /** 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[];
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemActions.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemActionsItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1431,27 +1304,25 @@ type CreateFlowDefinitionBodyFlowDefinitionAudience = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * 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`.
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemActions = {
-  [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;
-  };
+type CreateFlowDefinition201FlowDefinitionStepsItemActionsItem = {
+  /** 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;
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemComplete.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemComplete.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1465,12 +1336,12 @@ type CreateFlowDefinitionBodyFlowDefinitionStepsItemActions = {
 - show: render as a success/info screen
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete = (typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete)[keyof typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete];
-declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete: {
+type CreateFlowDefinition201FlowDefinitionStepsItemComplete = (typeof CreateFlowDefinition201FlowDefinitionStepsItemComplete)[keyof typeof CreateFlowDefinition201FlowDefinitionStepsItemComplete];
+declare const CreateFlowDefinition201FlowDefinitionStepsItemComplete: {
   readonly redirect: "redirect";
   readonly show: "show";
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemGatesConfig.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemGatesConfig.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1483,10 +1354,10 @@ declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete: {
 issuing the per-render challenge. Opaque to the engine.
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesConfig = {
+type CreateFlowDefinition201FlowDefinitionStepsItemGatesConfig = {
   [key: string]: unknown;
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemGatesKind.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemGatesKind.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1500,11 +1371,11 @@ ceremonies (e.g. passkey) are modelled as credential auth_attempts via
 `x-credential` on a field, not as gates.
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind = (typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind)[keyof typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind];
-declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind: {
+type CreateFlowDefinition201FlowDefinitionStepsItemGatesKind = (typeof CreateFlowDefinition201FlowDefinitionStepsItemGatesKind)[keyof typeof CreateFlowDefinition201FlowDefinitionStepsItemGatesKind];
+declare const CreateFlowDefinition201FlowDefinitionStepsItemGatesKind: {
   readonly captcha: "captcha";
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemGates.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemGates.d.ts
 /**
  * Security gates that must be satisfied before submission. Keyed by gate
 name. Each gate selects a kind (e.g. "captcha") and provider-specific
@@ -1512,13 +1383,13 @@ configuration. The engine may also inject gates dynamically based on
 policy.
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemGates = {
+type CreateFlowDefinition201FlowDefinitionStepsItemGates = {
   [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: CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind;
+    kind: CreateFlowDefinition201FlowDefinitionStepsItemGatesKind;
     /** Provider identifier within the gate kind — e.g. `altcha`, `turnstile`,
     `hcaptcha`. The engine looks up an implementation in its provider
     registry.
@@ -1527,10 +1398,10 @@ type CreateFlowDefinitionBodyFlowDefinitionStepsItemGates = {
     /** Provider-specific configuration consumed by the implementation when
     issuing the per-render challenge. Opaque to the engine.
     */
-    config?: CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesConfig;
+    config?: CreateFlowDefinition201FlowDefinitionStepsItemGatesConfig;
   };
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemOnSuccess.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1545,11 +1416,11 @@ Runs after field validation passes, before the transition fires.
 - create_user: creates the user record (registration flows)
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess = (typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess)[keyof typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess];
-declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess: {
+type CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess = (typeof CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess)[keyof typeof CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess];
+declare const CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess: {
   readonly create_user: "create_user";
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1560,12 +1431,12 @@ declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess: {
 /**
  * An available SSO identity provider.
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem = {
+type CreateFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem = {
   /** Provider instance identifier. */id: string; /** Display name for the provider. */
   name: string; /** Template hint for rendering (logo, colors). */
   template: string;
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemTransitions.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItemTransitions.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1576,13 +1447,13 @@ type CreateFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem = {
 /**
  * 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`).
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItemTransitions = {
+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`).
@@ -1600,7 +1471,7 @@ type CreateFlowDefinitionBodyFlowDefinitionStepsItemTransitions = {
     action?: "switch" | "pivot" | null;
   };
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItem.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinitionStepsItem.d.ts
 /**
  * A step in a flow definition. This is the admin-authored configuration,
 not the runtime payload sent to the frontend.
@@ -1613,7 +1484,7 @@ A step with only `complete` set is a terminal step. All other steps are
 rendered to the frontend as capability payloads.
 
  */
-type CreateFlowDefinitionBodyFlowDefinitionStepsItem = {
+type CreateFlowDefinition201FlowDefinitionStepsItem = {
   /** Unique step identifier within this flow. Used as transition targets
   and returned in the API response as `step.name`.
    */
@@ -1625,37 +1496,37 @@ 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?: CreateFlowDefinition201FlowDefinitionStepsItemActionsItem[];
   /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemGates; /** Available SSO identity providers for this step. */
-  sso_providers?: CreateFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem[];
+  gates?: CreateFlowDefinition201FlowDefinitionStepsItemGates; /** Available SSO identity providers for this step. */
+  sso_providers?: CreateFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem[];
   /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess;
+  on_success?: CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess;
   /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete;
+  complete?: CreateFlowDefinition201FlowDefinitionStepsItemComplete;
   /** 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`).
    */
-  transitions?: CreateFlowDefinitionBodyFlowDefinitionStepsItemTransitions;
+  transitions?: CreateFlowDefinition201FlowDefinitionStepsItemTransitions;
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBodyFlowDefinition.d.ts
+//#region src/generated/model/createFlowDefinition201FlowDefinition.d.ts
 /**
  * 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
@@ -1667,7 +1538,7 @@ configuration hierarchy. The engine selects the matching definition based on
 the purpose + audience when a flow is created via POST /flow.
 
  */
-type CreateFlowDefinitionBodyFlowDefinition = {
+type CreateFlowDefinition201FlowDefinition = {
   /**
      * Stable identifier for this flow, used as the target of cross-flow
   `switch` and `pivot` transitions. Renaming is not supported — the
@@ -1692,22 +1563,19 @@ type CreateFlowDefinitionBodyFlowDefinition = {
   matches every request in the project. The engine picks the most specific
   matching definition: app > team > project-wide.
    */
-  audience?: CreateFlowDefinitionBodyFlowDefinitionAudience;
+  audience?: CreateFlowDefinition201FlowDefinitionAudience;
   /**
      * Ordered list of steps in this flow. The order is for human readability —
   actual step sequencing is determined by transitions.
         * @minItems 1
      */
-  steps: CreateFlowDefinitionBodyFlowDefinitionStepsItem[];
+  steps: CreateFlowDefinition201FlowDefinitionStepsItem[];
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionBody.d.ts
-type CreateFlowDefinitionBody = {
-  /** @pattern ^[a-zA-Z0-9_-]+$ */project_id: string;
-  /** URI of the server-published flow definition schema this definition was
-  authored against. The server uses this to validate the definition.
-  If not provided, the engine will use the latest schema version for validation.
-   */
-  schema_uri?: string;
+//#region src/generated/model/createFlowDefinition201.d.ts
+type CreateFlowDefinition201 = {
+  /** Unique identifier for the flow definition. */id: string; /** Identifier of the project this flow definition belongs to. */
+  project_id: 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
@@ -1716,9 +1584,11 @@ type CreateFlowDefinitionBody = {
   configuration hierarchy. The engine selects the matching definition based on
   the purpose + audience when a flow is created via POST /flow.
    */
-  flow_definition: CreateFlowDefinitionBodyFlowDefinition;
+  flow_definition: CreateFlowDefinition201FlowDefinition;
+  created_at: string;
+  updated_at: string;
 }; //#endregion
-//#region src/generated/model/createFlowDefinitionDefaultDetails.d.ts
+//#region src/generated/model/createFlowDefinition400Details.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1730,7 +1600,7 @@ type CreateFlowDefinitionBody = {
  * Additional error-specific context.
  */
 //#endregion
-//#region src/generated/model/createHandoff200.d.ts
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionAudience.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1739,26 +1609,17 @@ type CreateFlowDefinitionBody = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * The handoff token and metadata for session exchange.
-
-This is a short-lived credential (TTL ≤ 60 seconds) that the client must exchange
-at POST /sessions/exchange to receive the final session and session_token.
-The handoff token is single-use and audience-bound to the project.
+ * 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.
 
  */
-type CreateHandoff200 = {
-  /** The short-lived handoff token for session exchange.
-     Exchange at: POST /sessions/exchange
-     Requirements:
-  - Single-use (atomic GETDEL on exchange)
-  - TTL ≤ 60 seconds
-  - Audience-bound to project (exchange requires sk_proj_… for matching project)
-  - Idempotency-safe (Category B, 5-minute window)
-   */
-  handoff_token: string; /** When this handoff token expires */
-  expires_at: string;
+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[];
 }; //#endregion
-//#region src/generated/model/createHandoffDefault.d.ts
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemActionsItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1766,29 +1627,26 @@ type CreateHandoff200 = {
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
-//#endregion
-//#region src/generated/model/createProject201.d.ts
 /**
- * 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`.
+
  */
-type CreateProject201 = {
-  /** The unique identifier of the project. */id: string;
-  /** Secret which can be used for authentication when modifying the project.
+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.
    */
-  projectSecret: string;
-  /** Secret which can be used for previewing and testing the project.
-   */
-  previewSecret: string;
-  /** Origins which are allowed for previewing and testing the project.
+  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.
    */
-  previewOrigins: string[]; /** The time when the project was created. */
-  createdAt: string;
+  text_key?: string;
 }; //#endregion
-//#region src/generated/model/createProject429Details.d.ts
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemComplete.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1797,23 +1655,17 @@ type CreateProject201 = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * Additional error-specific context.
- */
-//#endregion
-//#region src/generated/model/createProjectBody.d.ts
-/**
- * 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
+
  */
-type CreateProjectBody = {
-  /** Origins which are allowed for previewing and testing the project.
-   */
-  previewOrigins?: string[];
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete = (typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete)[keyof typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete];
+declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete: {
+  readonly redirect: "redirect";
+  readonly show: "show";
 }; //#endregion
-//#region src/generated/model/createProjectDefaultDetails.d.ts
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemGatesConfig.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1822,21 +1674,14 @@ type CreateProjectBody = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * Additional error-specific context.
- */
-//#endregion
-//#region src/generated/model/createSchema201.d.ts
-/**
- * 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
+ * Provider-specific configuration consumed by the implementation when
+issuing the per-render challenge. Opaque to the engine.
+
  */
-type CreateSchema201 = {
-  /** The ID of the created schema */id: string;
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesConfig = {
+  [key: string]: unknown;
 }; //#endregion
-//#region src/generated/model/createSchema400Details.d.ts
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemGatesKind.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -1845,19 +1690,369 @@ type CreateSchema201 = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * Additional error-specific context.
+ * 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.
+
  */
-//#endregion
-//#region src/generated/model/createSchemaBody.d.ts
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind = (typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind)[keyof typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind];
+declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind: {
+  readonly captcha: "captcha";
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemGates.d.ts
 /**
- * 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
- */
-type CreateSchemaBody = {
-  /** Discriminator value for a user schema create request. */kind: "user-schema"; /** The user Schema version used for this schema. */
+ * 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.
+
+ */
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemGates = {
+  [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: CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesKind;
+    /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemGatesConfig;
+  };
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess.d.ts
+/**
+ * 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
+ */
+/**
+ * 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)
+
+ */
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess = (typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess)[keyof typeof CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess];
+declare const CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess: {
+  readonly create_user: "create_user";
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem.d.ts
+/**
+ * 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.
+ */
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem = {
+  /** Provider instance identifier. */id: string; /** Display name for the provider. */
+  name: string; /** Template hint for rendering (logo, colors). */
+  template: string;
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItemTransitions.d.ts
+/**
+ * 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`).
+
+ */
+type CreateFlowDefinitionBodyFlowDefinitionStepsItemTransitions = {
+  [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;
+  };
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinitionStepsItem.d.ts
+/**
+ * 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.
+
+ */
+type CreateFlowDefinitionBodyFlowDefinitionStepsItem = {
+  /** 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?: 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
+  policy.
+   */
+  gates?: CreateFlowDefinitionBodyFlowDefinitionStepsItemGates; /** Available SSO identity providers for this step. */
+  sso_providers?: CreateFlowDefinitionBodyFlowDefinitionStepsItemSsoProvidersItem[];
+  /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemOnSuccess;
+  /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemComplete;
+  /** 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?: CreateFlowDefinitionBodyFlowDefinitionStepsItemTransitions;
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBodyFlowDefinition.d.ts
+/**
+ * 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.
+
+ */
+type CreateFlowDefinitionBodyFlowDefinition = {
+  /**
+     * 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?: CreateFlowDefinitionBodyFlowDefinitionAudience;
+  /**
+     * Ordered list of steps in this flow. The order is for human readability —
+  actual step sequencing is determined by transitions.
+        * @minItems 1
+     */
+  steps: CreateFlowDefinitionBodyFlowDefinitionStepsItem[];
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionBody.d.ts
+type CreateFlowDefinitionBody = {
+  /** @pattern ^[a-zA-Z0-9_-]+$ */project_id: string;
+  /** URI of the server-published flow definition schema this definition was
+  authored against. The server uses this to validate the definition.
+  If not provided, the engine will use the latest schema version for validation.
+   */
+  schema_uri?: 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: CreateFlowDefinitionBodyFlowDefinition;
+}; //#endregion
+//#region src/generated/model/createFlowDefinitionDefaultDetails.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
+//#region src/generated/model/createHandoff200.d.ts
+/**
+ * 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
+ */
+/**
+ * The handoff token and metadata for session exchange.
+
+This is a short-lived credential (TTL ≤ 60 seconds) that the client must exchange
+at POST /sessions/exchange to receive the final session and session_token.
+The handoff token is single-use and audience-bound to the project.
+
+ */
+type CreateHandoff200 = {
+  /** The short-lived handoff token for session exchange.
+     Exchange at: POST /sessions/exchange
+     Requirements:
+  - Single-use (atomic GETDEL on exchange)
+  - TTL ≤ 60 seconds
+  - Audience-bound to project (exchange requires sk_proj_… for matching project)
+  - Idempotency-safe (Category B, 5-minute window)
+   */
+  handoff_token: string; /** When this handoff token expires */
+  expires_at: string;
+}; //#endregion
+//#region src/generated/model/createHandoffDefault.d.ts
+/**
+ * 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
+ */
+//#endregion
+//#region src/generated/model/createProject201.d.ts
+/**
+ * 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
+ */
+type CreateProject201 = {
+  /** The unique identifier of the project. */id: string;
+  /** Secret which can be used for authentication when modifying the project.
+   */
+  projectSecret: string;
+  /** Secret which can be used for previewing and testing the project.
+   */
+  previewSecret: string;
+  /** Origins which are allowed for previewing and testing the project.
+   */
+  previewOrigins: string[]; /** The time when the project was created. */
+  createdAt: string;
+}; //#endregion
+//#region src/generated/model/createProject429Details.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
+//#region src/generated/model/createProjectBody.d.ts
+/**
+ * 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
+ */
+type CreateProjectBody = {
+  /** Origins which are allowed for previewing and testing the project.
+   */
+  previewOrigins?: string[];
+}; //#endregion
+//#region src/generated/model/createProjectDefaultDetails.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
+//#region src/generated/model/createSchema201.d.ts
+/**
+ * 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
+ */
+type CreateSchema201 = {
+  /** The ID of the created schema */id: string;
+}; //#endregion
+//#region src/generated/model/createSchema400Details.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
+//#region src/generated/model/createSchemaBody.d.ts
+/**
+ * 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
+ */
+type CreateSchemaBody = {
+  /** Discriminator value for a user schema create request. */kind: "user-schema"; /** The user Schema version used for this schema. */
   metaSchema: string; /** A list of authentication methods supported by the user definition. */
   "x-auth-methods": {
     password?: {
@@ -2328,7 +2523,34 @@ type CreateUserParams = {
    */
   team_id?: string;
 }; //#endregion
-//#region src/generated/model/deleteFlowDefinition404Details.d.ts
+//#region src/generated/model/deleteFlowDefinitionDefaultDetails.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
+//#region src/generated/model/deleteFlowDefinitionParams.d.ts
+/**
+ * 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
+ */
+type DeleteFlowDefinitionParams = {
+  /**
+   * The project id to filter by.
+   * @pattern ^[a-zA-Z0-9_-]+$
+   */
+  project_id: string;
+}; //#endregion
+//#region src/generated/model/endSession400Details.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -2822,85 +3044,339 @@ declare const GetAuthAttempt200RequiredFactorsItem: {
 - `expired`: the 15-minute TTL has been exceeded.
 
  */
-type GetAuthAttempt200State = (typeof GetAuthAttempt200State)[keyof typeof GetAuthAttempt200State];
-declare const GetAuthAttempt200State: {
-  readonly in_progress: "in_progress";
-  readonly completed: "completed";
-  readonly failed: "failed";
-  readonly expired: "expired";
+type GetAuthAttempt200State = (typeof GetAuthAttempt200State)[keyof typeof GetAuthAttempt200State];
+declare const GetAuthAttempt200State: {
+  readonly in_progress: "in_progress";
+  readonly completed: "completed";
+  readonly failed: "failed";
+  readonly expired: "expired";
+}; //#endregion
+//#region src/generated/model/getAuthAttempt200.d.ts
+/**
+ * The current state of an authentication attempt.
+
+An attempt is an ephemeral state machine (15-minute TTL) that drives a single authentication round.
+It accepts factor challenges, verifies proofs, and completes into a handoff token.
+Clients drive the attempt by:
+1. Issuing challenges: POST /auth_attempts/{attempt_id}/challenges
+2. Verifying proofs: POST /auth_attempts/{attempt_id}/challenges/{challenge_id}/verify
+3. Completing: POST /auth_attempts/{attempt_id}/handoff
+
+ */
+type GetAuthAttempt200 = {
+  /**
+   * Unique identifier for this authentication attempt
+   * @pattern ^[a-zA-Z0-9_-]+$
+   */
+  attempt_id: string; /** @pattern ^[a-zA-Z0-9_-]+$ */
+  project_id: string;
+  /** Overall state of the authentication attempt:
+  - `in_progress`: factors are still being collected; continue issuing challenges.
+  - `completed`: all required factors have been verified; the attempt is ready for handoff.
+  - `failed`: the attempt has failed (e.g. too many failed proofs) and cannot be continued.
+  - `expired`: the 15-minute TTL has been exceeded.
+   */
+  state: GetAuthAttempt200State;
+  /** The session being authenticated into. Either newly created or passed in on POST.
+  For step-up (re-auth), this is the existing session_id provided on creation.
+   */
+  session_id?: string | null;
+  /** The user ID, if known at this point in the flow.
+  Null until an identifier challenge has been verified.
+   */
+  user_id?: string | null;
+  /** The authentication factor methods that the project policy requires in order
+  to complete this attempt. Computed by the server from the project's auth policy.
+  Clients should use this to determine which challenges still need to be issued.
+   */
+  required_factors?: GetAuthAttempt200RequiredFactorsItem[];
+  /** The factors that have been successfully verified in this attempt so far.
+  Each item includes method-specific metadata in the payload field.
+     The flow engine uses verified_at timestamps to enforce time-based policies, such as
+  requiring password verification within the last 5 minutes for step-up auth to
+  access sensitive operations.
+     A factor appears here once its challenge reaches `verified` state.
+   */
+  completed_factors?: GetAuthAttempt200CompletedFactorsItem[];
+  /** All challenges issued within this attempt, in creation order.
+  Use this to track the state of each factor challenge (pending, verified, failed, expired).
+   */
+  challenges?: GetAuthAttempt200ChallengesItem[]; /** When this attempt expires (15-minute TTL from creation) */
+  expires_at?: string; /** When this attempt was created */
+  created_at: string;
+}; //#endregion
+//#region src/generated/model/getAuthAttemptDefault.d.ts
+/**
+ * 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
+ */
+//#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionAudience.d.ts
+/**
+ * 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
+ */
+/**
+ * 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.
+
+ */
+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[];
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemActionsItem.d.ts
+/**
+ * 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`.
+
+ */
+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;
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemComplete.d.ts
+/**
+ * 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
+
+ */
+type GetFlowDefinition200FlowDefinitionStepsItemComplete = (typeof GetFlowDefinition200FlowDefinitionStepsItemComplete)[keyof typeof GetFlowDefinition200FlowDefinitionStepsItemComplete];
+declare const GetFlowDefinition200FlowDefinitionStepsItemComplete: {
+  readonly redirect: "redirect";
+  readonly show: "show";
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemGatesConfig.d.ts
+/**
+ * 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
+ */
+/**
+ * Provider-specific configuration consumed by the implementation when
+issuing the per-render challenge. Opaque to the engine.
+
+ */
+type GetFlowDefinition200FlowDefinitionStepsItemGatesConfig = {
+  [key: string]: unknown;
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemGatesKind.d.ts
+/**
+ * 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
+ */
+/**
+ * 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.
+
+ */
+type GetFlowDefinition200FlowDefinitionStepsItemGatesKind = (typeof GetFlowDefinition200FlowDefinitionStepsItemGatesKind)[keyof typeof GetFlowDefinition200FlowDefinitionStepsItemGatesKind];
+declare const GetFlowDefinition200FlowDefinitionStepsItemGatesKind: {
+  readonly captcha: "captcha";
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemGates.d.ts
+/**
+ * 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.
+
+ */
+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;
+  };
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemOnSuccess.d.ts
+/**
+ * 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
+ */
+/**
+ * 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)
+
+ */
+type GetFlowDefinition200FlowDefinitionStepsItemOnSuccess = (typeof GetFlowDefinition200FlowDefinitionStepsItemOnSuccess)[keyof typeof GetFlowDefinition200FlowDefinitionStepsItemOnSuccess];
+declare const GetFlowDefinition200FlowDefinitionStepsItemOnSuccess: {
+  readonly create_user: "create_user";
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem.d.ts
+/**
+ * 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.
+ */
+type GetFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem = {
+  /** Provider instance identifier. */id: string; /** Display name for the provider. */
+  name: string; /** Template hint for rendering (logo, colors). */
+  template: string;
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItemTransitions.d.ts
+/**
+ * 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`).
+
+ */
+type GetFlowDefinition200FlowDefinitionStepsItemTransitions = {
+  [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;
+  };
 }; //#endregion
-//#region src/generated/model/getAuthAttempt200.d.ts
+//#region src/generated/model/getFlowDefinition200FlowDefinitionStepsItem.d.ts
 /**
- * The current state of an authentication attempt.
+ * A step in a flow definition. This is the admin-authored configuration,
+not the runtime payload sent to the frontend.
 
-An attempt is an ephemeral state machine (15-minute TTL) that drives a single authentication round.
-It accepts factor challenges, verifies proofs, and completes into a handoff token.
-Clients drive the attempt by:
-1. Issuing challenges: POST /auth_attempts/{attempt_id}/challenges
-2. Verifying proofs: POST /auth_attempts/{attempt_id}/challenges/{challenge_id}/verify
-3. Completing: POST /auth_attempts/{attempt_id}/handoff
+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.
 
  */
-type GetAuthAttempt200 = {
-  /**
-   * Unique identifier for this authentication attempt
-   * @pattern ^[a-zA-Z0-9_-]+$
+type GetFlowDefinition200FlowDefinitionStepsItem = {
+  /** Unique step identifier within this flow. Used as transition targets
+  and returned in the API response as `step.name`.
    */
-  attempt_id: string; /** @pattern ^[a-zA-Z0-9_-]+$ */
-  project_id: string;
-  /** Overall state of the authentication attempt:
-  - `in_progress`: factors are still being collected; continue issuing challenges.
-  - `completed`: all required factors have been verified; the attempt is ready for handoff.
-  - `failed`: the attempt has failed (e.g. too many failed proofs) and cannot be continued.
-  - `expired`: the 15-minute TTL has been exceeded.
+  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).
    */
-  state: GetAuthAttempt200State;
-  /** The session being authenticated into. Either newly created or passed in on POST.
-  For step-up (re-auth), this is the existing session_id provided on creation.
+  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.
    */
-  session_id?: string | null;
-  /** The user ID, if known at this point in the flow.
-  Null until an identifier challenge has been verified.
+  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.
    */
-  user_id?: string | null;
-  /** The authentication factor methods that the project policy requires in order
-  to complete this attempt. Computed by the server from the project's auth policy.
-  Clients should use this to determine which challenges still need to be issued.
+  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)
    */
-  required_factors?: GetAuthAttempt200RequiredFactorsItem[];
-  /** The factors that have been successfully verified in this attempt so far.
-  Each item includes method-specific metadata in the payload field.
-     The flow engine uses verified_at timestamps to enforce time-based policies, such as
-  requiring password verification within the last 5 minutes for step-up auth to
-  access sensitive operations.
-     A factor appears here once its challenge reaches `verified` state.
+  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
    */
-  completed_factors?: GetAuthAttempt200CompletedFactorsItem[];
-  /** All challenges issued within this attempt, in creation order.
-  Use this to track the state of each factor challenge (pending, verified, failed, expired).
+  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`).
    */
-  challenges?: GetAuthAttempt200ChallengesItem[]; /** When this attempt expires (15-minute TTL from creation) */
-  expires_at?: string; /** When this attempt was created */
-  created_at: string;
+  transitions?: GetFlowDefinition200FlowDefinitionStepsItemTransitions;
 }; //#endregion
-//#region src/generated/model/getAuthAttemptDefault.d.ts
-/**
- * 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
- */
-//#endregion
-//#region src/generated/model/getFlowDefinition200.d.ts
+//#region src/generated/model/getFlowDefinition200FlowDefinition.d.ts
 /**
- * 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
+ * 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.
+
  */
-type GetFlowDefinition200 = {
+type GetFlowDefinition200FlowDefinition = {
   /**
      * Stable identifier for this flow, used as the target of cross-flow
   `switch` and `pivot` transitions. Renaming is not supported — the
@@ -2925,123 +3401,32 @@ type GetFlowDefinition200 = {
   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[];
-  };
+  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: {
-    /** 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;
-      };
-    };
-  }[];
-} & {
+  steps: GetFlowDefinition200FlowDefinitionStepsItem[];
+}; //#endregion
+//#region src/generated/model/getFlowDefinition200.d.ts
+type GetFlowDefinition200 = {
   /** 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. */
+  project_id: 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;
 }; //#endregion
-//#region src/generated/model/getFlowDefinition404Details.d.ts
+//#region src/generated/model/getFlowDefinitionDefaultDetails.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -3053,6 +3438,21 @@ type GetFlowDefinition200 = {
  * Additional error-specific context.
  */
 //#endregion
+//#region src/generated/model/getFlowDefinitionParams.d.ts
+/**
+ * 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
+ */
+type GetFlowDefinitionParams = {
+  /**
+   * The project id to filter by.
+   * @pattern ^[a-zA-Z0-9_-]+$
+   */
+  project_id: string;
+}; //#endregion
 //#region src/generated/model/getFlowStep200BrandingLayout.d.ts
 /**
  * Generated by orval v8.10.0 🍺
@@ -3094,7 +3494,7 @@ type GetFlowStep200Branding = {
   font_url?: string; /** Hero/background image URL (used by split layout). */
   hero_url?: string;
 }; //#endregion
-//#region src/generated/model/getFlowStep200StepActions.d.ts
+//#region src/generated/model/getFlowStep200StepActionsItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -3103,24 +3503,23 @@ type GetFlowStep200Branding = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * Unordered dictionary of available user actions. Keyed by action name.
-The LiquidJS template controls positioning and presentation.
+ * Configuration for a user-invokable action on a step. The `name` is sent
+back in the submit request as `action`.
 
  */
-type GetFlowStep200StepActions = {
-  [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;
-  };
+type GetFlowStep200StepActionsItem = {
+  /** 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;
 }; //#endregion
 //#region src/generated/model/getFlowStep200StepChallengeMethod.d.ts
 /**
@@ -3198,7 +3597,7 @@ declare const GetFlowStep200StepComplete: {
   readonly redirect: "redirect";
   readonly show: "show";
 }; //#endregion
-//#region src/generated/model/getFlowStep200StepFieldsType.d.ts
+//#region src/generated/model/getFlowStep200StepFieldsItemType.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -3207,14 +3606,15 @@ declare const GetFlowStep200StepComplete: {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * The input kind the client should render. Encodes the formats that
-have a matching HTML input type (email, url, date). For other
-formats (e.g. uuid) the type is `text` and `validation.format`
-carries the rule.
+ * The input kind the client should render. Encodes the formats and
+JSON types that map to a familiar HTML input: `email`, `url`,
+`date` come from `format`; `checkbox` from JSON `type: boolean`;
+`select` from a closed `enum`. For other formats (e.g. uuid) the
+type is `text` and `validation.format` carries the rule.
 
  */
-type GetFlowStep200StepFieldsType = (typeof GetFlowStep200StepFieldsType)[keyof typeof GetFlowStep200StepFieldsType];
-declare const GetFlowStep200StepFieldsType: {
+type GetFlowStep200StepFieldsItemType = (typeof GetFlowStep200StepFieldsItemType)[keyof typeof GetFlowStep200StepFieldsItemType];
+declare const GetFlowStep200StepFieldsItemType: {
   readonly text: "text";
   readonly email: "email";
   readonly password: "password";
@@ -3223,8 +3623,10 @@ declare const GetFlowStep200StepFieldsType: {
   readonly url: "url";
   readonly date: "date";
   readonly hidden: "hidden";
+  readonly checkbox: "checkbox";
+  readonly select: "select";
 }; //#endregion
-//#region src/generated/model/getFlowStep200StepFieldsValidationFormat.d.ts
+//#region src/generated/model/getFlowStep200StepFieldsItemValidationFormat.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -3240,14 +3642,14 @@ sufficient for client-side validation. When `type` is `text`
 (e.g. `format: uuid`), this key is the only signal.
 
  */
-type GetFlowStep200StepFieldsValidationFormat = (typeof GetFlowStep200StepFieldsValidationFormat)[keyof typeof GetFlowStep200StepFieldsValidationFormat];
-declare const GetFlowStep200StepFieldsValidationFormat: {
+type GetFlowStep200StepFieldsItemValidationFormat = (typeof GetFlowStep200StepFieldsItemValidationFormat)[keyof typeof GetFlowStep200StepFieldsItemValidationFormat];
+declare const GetFlowStep200StepFieldsItemValidationFormat: {
   readonly email: "email";
   readonly "date-time": "date-time";
   readonly uuid: "uuid";
   readonly uri: "uri";
 }; //#endregion
-//#region src/generated/model/getFlowStep200StepFieldsValidation.d.ts
+//#region src/generated/model/getFlowStep200StepFieldsItemValidation.d.ts
 /**
  * Schema-derived rules the frontend SHOULD apply at input time. The
 server runs the same rules on submit and is the only authority on
@@ -3259,14 +3661,14 @@ Each key mirrors a JSON Schema keyword on the underlying user
 property; absent keys mean no rule.
 
  */
-type GetFlowStep200StepFieldsValidation = {
+type GetFlowStep200StepFieldsItemValidation = {
   /** Semantic format the value must match. Values mirror the user
   meta-schema. When `type` already encodes the format (email,
   url, date), this key is informative and the input type is
   sufficient for client-side validation. When `type` is `text`
   (e.g. `format: uuid`), this key is the only signal.
    */
-  format?: GetFlowStep200StepFieldsValidationFormat;
+  format?: GetFlowStep200StepFieldsItemValidationFormat;
   /**
    * Minimum length in characters (inclusive). Mirrors `minLength`.
    * @minimum 0
@@ -3277,39 +3679,46 @@ type GetFlowStep200StepFieldsValidation = {
    * @minimum 0
    */
   max_length?: number;
+  /** Closed list of allowed values. Mirrors the JSON Schema `enum`
+  keyword on the underlying user property. When `type` is
+  `select` the client renders these as options; for other types
+  the rule still applies as a membership check.
+   */
+  enum?: string[];
 }; //#endregion
-//#region src/generated/model/getFlowStep200StepFields.d.ts
+//#region src/generated/model/getFlowStep200StepFieldsItem.d.ts
 /**
- * Unordered dictionary of input fields to collect. Keyed by field name.
-The LiquidJS template controls which fields appear and in what order.
-Field metadata (type, validation) is resolved by the engine from the
-flow's user schema.
+ * A data input capability. Describes what the user must provide.
+Does not contain display text — only a `text_key` resolved client-side.
 
  */
-type GetFlowStep200StepFields = {
-  [key: string]: {
-    /** The input kind the client should render. Encodes the formats that
-    have a matching HTML input type (email, url, date). For other
-    formats (e.g. uuid) the type is `text` and `validation.format`
-    carries the rule.
-    */
-    type: GetFlowStep200StepFieldsType; /** Localization key for the field label. */
-    text_key: string;
-    /** The field MUST be present and non-empty on submit. Mirrors the
-    schema's top-level `required` array.
-    */
-    required?: boolean; /** Pre-filled value (e.g., an identifier carried over from a pivot). */
-    value?: unknown;
-    /** Schema-derived rules the frontend SHOULD apply at input time. The
-    server runs the same rules on submit and is the only authority on
-    whether the step advances — these rules are a UX hint to reduce
-    round trips, not a contract guarantee.
-       Omitted entirely when the field has no rules beyond its `type`.
-    Each key mirrors a JSON Schema keyword on the underlying user
-    property; absent keys mean no rule.
-    */
-    validation?: GetFlowStep200StepFieldsValidation;
-  };
+type GetFlowStep200StepFieldsItem = {
+  /** Field name, matching a property in the flow's user schema. Carries
+  the submitted value back to the engine.
+   */
+  name: string;
+  /** The input kind the client should render. Encodes the formats and
+  JSON types that map to a familiar HTML input: `email`, `url`,
+  `date` come from `format`; `checkbox` from JSON `type: boolean`;
+  `select` from a closed `enum`. For other formats (e.g. uuid) the
+  type is `text` and `validation.format` carries the rule.
+   */
+  type: GetFlowStep200StepFieldsItemType; /** Localization key for the field label. */
+  text_key: string;
+  /** The field MUST be present and non-empty on submit. Mirrors the
+  schema's top-level `required` array.
+   */
+  required?: boolean; /** Pre-filled value (e.g., an identifier carried over from a pivot). */
+  value?: unknown;
+  /** Schema-derived rules the frontend SHOULD apply at input time. The
+  server runs the same rules on submit and is the only authority on
+  whether the step advances — these rules are a UX hint to reduce
+  round trips, not a contract guarantee.
+     Omitted entirely when the field has no rules beyond its `type`.
+  Each key mirrors a JSON Schema keyword on the underlying user
+  property; absent keys mean no rule.
+   */
+  validation?: GetFlowStep200StepFieldsItemValidation;
 }; //#endregion
 //#region src/generated/model/getFlowStep200StepGatesConfig.d.ts
 /**
@@ -3405,9 +3814,10 @@ type GetFlowStep200StepTexts = {
 }; //#endregion
 //#region src/generated/model/getFlowStep200Step.d.ts
 /**
- * A step contains unordered capability dictionaries: what to collect (fields),
+ * A step contains ordered capability arrays: what to collect (fields),
 what the user can do (actions), and what security gates must be satisfied (gates).
-Layout and element ordering are controlled by the LiquidJS template in `branding.liquid_template`.
+The LiquidJS template in `branding.liquid_template` iterates these arrays in order
+and builds name-keyed indexes locally for lookup.
 
  */
 type GetFlowStep200Step = {
@@ -3423,16 +3833,16 @@ type GetFlowStep200Step = {
    */
   complete?: GetFlowStep200StepComplete; /** URL to navigate to (e.g., SSO provider redirect). */
   redirect_url?: string;
-  /** Unordered dictionary of input fields to collect. Keyed by field name.
-  The LiquidJS template controls which fields appear and in what order.
-  Field metadata (type, validation) is resolved by the engine from the
-  flow's user schema.
+  /** Ordered list of input fields to collect. Field metadata (type, validation)
+  is resolved by the engine from the flow's user schema. The LiquidJS
+  template iterates this array; for keyed lookup it builds a name-indexed
+  map locally.
    */
-  fields: GetFlowStep200StepFields;
-  /** Unordered dictionary of available user actions. Keyed by action name.
-  The LiquidJS template controls positioning and presentation.
+  fields: GetFlowStep200StepFieldsItem[];
+  /** Ordered list of available user actions. The LiquidJS template iterates
+  this array and builds a name-indexed map locally for keyed lookup.
    */
-  actions: GetFlowStep200StepActions;
+  actions: GetFlowStep200StepActionsItem[];
   /** Security gates that must be satisfied before the step can be submitted.
   The engine injects gates dynamically based on policy, even if they
   are not declared in the flow definition.
@@ -3457,9 +3867,10 @@ type GetFlowStep200 = {
   id: string; /** Underlying session ID. Stable across all stacked flows. */
   session_id: string; /** Reserved for future rotation. The sealed `_zflow` cookie carries the flow state today. */
   session_token?: string;
-  /** A step contains unordered capability dictionaries: what to collect (fields),
+  /** A step contains ordered capability arrays: what to collect (fields),
   what the user can do (actions), and what security gates must be satisfied (gates).
-  Layout and element ordering are controlled by the LiquidJS template in `branding.liquid_template`.
+  The LiquidJS template in `branding.liquid_template` iterates these arrays in order
+  and builds name-keyed indexes locally for lookup.
    */
   step: GetFlowStep200Step;
   /** Resolved branding configuration. Inherited from the app → team → project
@@ -3766,6 +4177,29 @@ type GetMySession200 = {
  * Additional error-specific context.
  */
 //#endregion
+//#region src/generated/model/getMyUser200.d.ts
+/**
+ * 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
+ */
+type GetMyUser200 = {
+  [key: string]: unknown;
+}; //#endregion
+//#region src/generated/model/getMyUser401Details.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
 //#region src/generated/model/getOpenIDConfiguration200ClaimTypesSupportedItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
@@ -4673,7 +5107,7 @@ type ListFlowDefinitions200FlowDefinitionsItem = {
   /** 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. */
+  schema_uri?: string; /** Status of the flow definition. */
   status: string; /** Timestamp when the flow definition was created. */
   created_at: string; /** Timestamp when the flow definition was last updated. */
   updated_at: string;
@@ -4728,7 +5162,7 @@ type ListFlowDefinitionsParams = {
     */
   page_token?: string;
   /**
-   * The unique identifier of the project
+   * The project id to filter by.
    * @pattern ^[a-zA-Z0-9_-]+$
    */
   project_id: string;
@@ -5072,6 +5506,63 @@ type RevokeTokenBody = {
  * Additional error-specific context.
  */
 //#endregion
+//#region src/generated/model/setUserPasswordBody.d.ts
+/**
+ * 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
+ */
+/**
+ * Request to update the user's password.
+ */
+type SetUserPasswordBody = {
+  /** The new password for the user. */password: string;
+  /** Whether the user is required to change their password on the next login.
+  If not provided, it will default to false.
+   */
+  isChangeRequired?: boolean;
+}; //#endregion
+//#region src/generated/model/setUserPasswordDefaultDetails.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
+//#region src/generated/model/setUserPasswordParams.d.ts
+/**
+ * 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
+ */
+type SetUserPasswordParams = {
+  /**
+   * The unique identifier of the project
+   * @pattern ^[a-zA-Z0-9_-]+$
+   */
+  project_id: string;
+}; //#endregion
+//#region src/generated/model/submitFlowEvent400Details.d.ts
+/**
+ * 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
+ */
+/**
+ * Additional error-specific context.
+ */
+//#endregion
 //#region src/generated/model/submitFlowEventBodyPayload.d.ts
 /**
  * Generated by orval v8.10.0 🍺
@@ -5158,7 +5649,7 @@ type SubmitFlowStep200Branding = {
   font_url?: string; /** Hero/background image URL (used by split layout). */
   hero_url?: string;
 }; //#endregion
-//#region src/generated/model/submitFlowStep200StepActions.d.ts
+//#region src/generated/model/submitFlowStep200StepActionsItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -5167,24 +5658,23 @@ type SubmitFlowStep200Branding = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * Unordered dictionary of available user actions. Keyed by action name.
-The LiquidJS template controls positioning and presentation.
+ * Configuration for a user-invokable action on a step. The `name` is sent
+back in the submit request as `action`.
 
  */
-type SubmitFlowStep200StepActions = {
-  [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;
-  };
+type SubmitFlowStep200StepActionsItem = {
+  /** 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;
 }; //#endregion
 //#region src/generated/model/submitFlowStep200StepChallengeMethod.d.ts
 /**
@@ -5262,7 +5752,7 @@ declare const SubmitFlowStep200StepComplete: {
   readonly redirect: "redirect";
   readonly show: "show";
 }; //#endregion
-//#region src/generated/model/submitFlowStep200StepFieldsType.d.ts
+//#region src/generated/model/submitFlowStep200StepFieldsItemType.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -5271,14 +5761,15 @@ declare const SubmitFlowStep200StepComplete: {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * The input kind the client should render. Encodes the formats that
-have a matching HTML input type (email, url, date). For other
-formats (e.g. uuid) the type is `text` and `validation.format`
-carries the rule.
+ * The input kind the client should render. Encodes the formats and
+JSON types that map to a familiar HTML input: `email`, `url`,
+`date` come from `format`; `checkbox` from JSON `type: boolean`;
+`select` from a closed `enum`. For other formats (e.g. uuid) the
+type is `text` and `validation.format` carries the rule.
 
  */
-type SubmitFlowStep200StepFieldsType = (typeof SubmitFlowStep200StepFieldsType)[keyof typeof SubmitFlowStep200StepFieldsType];
-declare const SubmitFlowStep200StepFieldsType: {
+type SubmitFlowStep200StepFieldsItemType = (typeof SubmitFlowStep200StepFieldsItemType)[keyof typeof SubmitFlowStep200StepFieldsItemType];
+declare const SubmitFlowStep200StepFieldsItemType: {
   readonly text: "text";
   readonly email: "email";
   readonly password: "password";
@@ -5287,8 +5778,10 @@ declare const SubmitFlowStep200StepFieldsType: {
   readonly url: "url";
   readonly date: "date";
   readonly hidden: "hidden";
+  readonly checkbox: "checkbox";
+  readonly select: "select";
 }; //#endregion
-//#region src/generated/model/submitFlowStep200StepFieldsValidationFormat.d.ts
+//#region src/generated/model/submitFlowStep200StepFieldsItemValidationFormat.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -5304,14 +5797,14 @@ sufficient for client-side validation. When `type` is `text`
 (e.g. `format: uuid`), this key is the only signal.
 
  */
-type SubmitFlowStep200StepFieldsValidationFormat = (typeof SubmitFlowStep200StepFieldsValidationFormat)[keyof typeof SubmitFlowStep200StepFieldsValidationFormat];
-declare const SubmitFlowStep200StepFieldsValidationFormat: {
+type SubmitFlowStep200StepFieldsItemValidationFormat = (typeof SubmitFlowStep200StepFieldsItemValidationFormat)[keyof typeof SubmitFlowStep200StepFieldsItemValidationFormat];
+declare const SubmitFlowStep200StepFieldsItemValidationFormat: {
   readonly email: "email";
   readonly "date-time": "date-time";
   readonly uuid: "uuid";
   readonly uri: "uri";
 }; //#endregion
-//#region src/generated/model/submitFlowStep200StepFieldsValidation.d.ts
+//#region src/generated/model/submitFlowStep200StepFieldsItemValidation.d.ts
 /**
  * Schema-derived rules the frontend SHOULD apply at input time. The
 server runs the same rules on submit and is the only authority on
@@ -5323,14 +5816,14 @@ Each key mirrors a JSON Schema keyword on the underlying user
 property; absent keys mean no rule.
 
  */
-type SubmitFlowStep200StepFieldsValidation = {
+type SubmitFlowStep200StepFieldsItemValidation = {
   /** Semantic format the value must match. Values mirror the user
   meta-schema. When `type` already encodes the format (email,
   url, date), this key is informative and the input type is
   sufficient for client-side validation. When `type` is `text`
   (e.g. `format: uuid`), this key is the only signal.
    */
-  format?: SubmitFlowStep200StepFieldsValidationFormat;
+  format?: SubmitFlowStep200StepFieldsItemValidationFormat;
   /**
    * Minimum length in characters (inclusive). Mirrors `minLength`.
    * @minimum 0
@@ -5341,39 +5834,46 @@ type SubmitFlowStep200StepFieldsValidation = {
    * @minimum 0
    */
   max_length?: number;
+  /** Closed list of allowed values. Mirrors the JSON Schema `enum`
+  keyword on the underlying user property. When `type` is
+  `select` the client renders these as options; for other types
+  the rule still applies as a membership check.
+   */
+  enum?: string[];
 }; //#endregion
-//#region src/generated/model/submitFlowStep200StepFields.d.ts
+//#region src/generated/model/submitFlowStep200StepFieldsItem.d.ts
 /**
- * Unordered dictionary of input fields to collect. Keyed by field name.
-The LiquidJS template controls which fields appear and in what order.
-Field metadata (type, validation) is resolved by the engine from the
-flow's user schema.
+ * A data input capability. Describes what the user must provide.
+Does not contain display text — only a `text_key` resolved client-side.
 
  */
-type SubmitFlowStep200StepFields = {
-  [key: string]: {
-    /** The input kind the client should render. Encodes the formats that
-    have a matching HTML input type (email, url, date). For other
-    formats (e.g. uuid) the type is `text` and `validation.format`
-    carries the rule.
-    */
-    type: SubmitFlowStep200StepFieldsType; /** Localization key for the field label. */
-    text_key: string;
-    /** The field MUST be present and non-empty on submit. Mirrors the
-    schema's top-level `required` array.
-    */
-    required?: boolean; /** Pre-filled value (e.g., an identifier carried over from a pivot). */
-    value?: unknown;
-    /** Schema-derived rules the frontend SHOULD apply at input time. The
-    server runs the same rules on submit and is the only authority on
-    whether the step advances — these rules are a UX hint to reduce
-    round trips, not a contract guarantee.
-       Omitted entirely when the field has no rules beyond its `type`.
-    Each key mirrors a JSON Schema keyword on the underlying user
-    property; absent keys mean no rule.
-    */
-    validation?: SubmitFlowStep200StepFieldsValidation;
-  };
+type SubmitFlowStep200StepFieldsItem = {
+  /** Field name, matching a property in the flow's user schema. Carries
+  the submitted value back to the engine.
+   */
+  name: string;
+  /** The input kind the client should render. Encodes the formats and
+  JSON types that map to a familiar HTML input: `email`, `url`,
+  `date` come from `format`; `checkbox` from JSON `type: boolean`;
+  `select` from a closed `enum`. For other formats (e.g. uuid) the
+  type is `text` and `validation.format` carries the rule.
+   */
+  type: SubmitFlowStep200StepFieldsItemType; /** Localization key for the field label. */
+  text_key: string;
+  /** The field MUST be present and non-empty on submit. Mirrors the
+  schema's top-level `required` array.
+   */
+  required?: boolean; /** Pre-filled value (e.g., an identifier carried over from a pivot). */
+  value?: unknown;
+  /** Schema-derived rules the frontend SHOULD apply at input time. The
+  server runs the same rules on submit and is the only authority on
+  whether the step advances — these rules are a UX hint to reduce
+  round trips, not a contract guarantee.
+     Omitted entirely when the field has no rules beyond its `type`.
+  Each key mirrors a JSON Schema keyword on the underlying user
+  property; absent keys mean no rule.
+   */
+  validation?: SubmitFlowStep200StepFieldsItemValidation;
 }; //#endregion
 //#region src/generated/model/submitFlowStep200StepGatesConfig.d.ts
 /**
@@ -5469,9 +5969,10 @@ type SubmitFlowStep200StepTexts = {
 }; //#endregion
 //#region src/generated/model/submitFlowStep200Step.d.ts
 /**
- * A step contains unordered capability dictionaries: what to collect (fields),
+ * A step contains ordered capability arrays: what to collect (fields),
 what the user can do (actions), and what security gates must be satisfied (gates).
-Layout and element ordering are controlled by the LiquidJS template in `branding.liquid_template`.
+The LiquidJS template in `branding.liquid_template` iterates these arrays in order
+and builds name-keyed indexes locally for lookup.
 
  */
 type SubmitFlowStep200Step = {
@@ -5487,16 +5988,16 @@ type SubmitFlowStep200Step = {
    */
   complete?: SubmitFlowStep200StepComplete; /** URL to navigate to (e.g., SSO provider redirect). */
   redirect_url?: string;
-  /** Unordered dictionary of input fields to collect. Keyed by field name.
-  The LiquidJS template controls which fields appear and in what order.
-  Field metadata (type, validation) is resolved by the engine from the
-  flow's user schema.
+  /** Ordered list of input fields to collect. Field metadata (type, validation)
+  is resolved by the engine from the flow's user schema. The LiquidJS
+  template iterates this array; for keyed lookup it builds a name-indexed
+  map locally.
    */
-  fields: SubmitFlowStep200StepFields;
-  /** Unordered dictionary of available user actions. Keyed by action name.
-  The LiquidJS template controls positioning and presentation.
+  fields: SubmitFlowStep200StepFieldsItem[];
+  /** Ordered list of available user actions. The LiquidJS template iterates
+  this array and builds a name-indexed map locally for keyed lookup.
    */
-  actions: SubmitFlowStep200StepActions;
+  actions: SubmitFlowStep200StepActionsItem[];
   /** Security gates that must be satisfied before the step can be submitted.
   The engine injects gates dynamically based on policy, even if they
   are not declared in the flow definition.
@@ -5521,9 +6022,10 @@ type SubmitFlowStep200 = {
   id: string; /** Underlying session ID. Stable across all stacked flows. */
   session_id: string; /** Reserved for future rotation. The sealed `_zflow` cookie carries the flow state today. */
   session_token?: string;
-  /** A step contains unordered capability dictionaries: what to collect (fields),
+  /** A step contains ordered capability arrays: what to collect (fields),
   what the user can do (actions), and what security gates must be satisfied (gates).
-  Layout and element ordering are controlled by the LiquidJS template in `branding.liquid_template`.
+  The LiquidJS template in `branding.liquid_template` iterates these arrays in order
+  and builds name-keyed indexes locally for lookup.
    */
   step: SubmitFlowStep200Step;
   /** Resolved branding configuration. Inherited from the app → team → project
@@ -5659,7 +6161,7 @@ type SubmitFlowStepBody = {
  * Additional error-specific context.
  */
 //#endregion
-//#region src/generated/model/updateFlowDefinition200.d.ts
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionAudience.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -5667,7 +6169,261 @@ type SubmitFlowStepBody = {
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
-type UpdateFlowDefinition200 = {
+/**
+ * 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.
+
+ */
+type UpdateFlowDefinition200FlowDefinitionAudience = {
+  /** 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[];
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemActionsItem.d.ts
+/**
+ * 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`.
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemActionsItem = {
+  /** 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;
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemComplete.d.ts
+/**
+ * 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
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemComplete = (typeof UpdateFlowDefinition200FlowDefinitionStepsItemComplete)[keyof typeof UpdateFlowDefinition200FlowDefinitionStepsItemComplete];
+declare const UpdateFlowDefinition200FlowDefinitionStepsItemComplete: {
+  readonly redirect: "redirect";
+  readonly show: "show";
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemGatesConfig.d.ts
+/**
+ * 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
+ */
+/**
+ * Provider-specific configuration consumed by the implementation when
+issuing the per-render challenge. Opaque to the engine.
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemGatesConfig = {
+  [key: string]: unknown;
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemGatesKind.d.ts
+/**
+ * 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
+ */
+/**
+ * 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.
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemGatesKind = (typeof UpdateFlowDefinition200FlowDefinitionStepsItemGatesKind)[keyof typeof UpdateFlowDefinition200FlowDefinitionStepsItemGatesKind];
+declare const UpdateFlowDefinition200FlowDefinitionStepsItemGatesKind: {
+  readonly captcha: "captcha";
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemGates.d.ts
+/**
+ * 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.
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemGates = {
+  [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: UpdateFlowDefinition200FlowDefinitionStepsItemGatesKind;
+    /** 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?: UpdateFlowDefinition200FlowDefinitionStepsItemGatesConfig;
+  };
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemOnSuccess.d.ts
+/**
+ * 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
+ */
+/**
+ * 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)
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemOnSuccess = (typeof UpdateFlowDefinition200FlowDefinitionStepsItemOnSuccess)[keyof typeof UpdateFlowDefinition200FlowDefinitionStepsItemOnSuccess];
+declare const UpdateFlowDefinition200FlowDefinitionStepsItemOnSuccess: {
+  readonly create_user: "create_user";
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem.d.ts
+/**
+ * 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.
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem = {
+  /** Provider instance identifier. */id: string; /** Display name for the provider. */
+  name: string; /** Template hint for rendering (logo, colors). */
+  template: string;
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItemTransitions.d.ts
+/**
+ * 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`).
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItemTransitions = {
+  [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;
+  };
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinitionStepsItem.d.ts
+/**
+ * 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.
+
+ */
+type UpdateFlowDefinition200FlowDefinitionStepsItem = {
+  /** 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?: UpdateFlowDefinition200FlowDefinitionStepsItemActionsItem[];
+  /** 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?: UpdateFlowDefinition200FlowDefinitionStepsItemGates; /** Available SSO identity providers for this step. */
+  sso_providers?: UpdateFlowDefinition200FlowDefinitionStepsItemSsoProvidersItem[];
+  /** 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?: UpdateFlowDefinition200FlowDefinitionStepsItemOnSuccess;
+  /** 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?: UpdateFlowDefinition200FlowDefinitionStepsItemComplete;
+  /** 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?: UpdateFlowDefinition200FlowDefinitionStepsItemTransitions;
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200FlowDefinition.d.ts
+/**
+ * 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.
+
+ */
+type UpdateFlowDefinition200FlowDefinition = {
   /**
      * Stable identifier for this flow, used as the target of cross-flow
   `switch` and `pivot` transitions. Renaming is not supported — the
@@ -5692,119 +6448,28 @@ type UpdateFlowDefinition200 = {
   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[];
-  };
+  audience?: UpdateFlowDefinition200FlowDefinitionAudience;
   /**
      * 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;
-      };
-    };
-  }[];
-} & {
+  steps: UpdateFlowDefinition200FlowDefinitionStepsItem[];
+}; //#endregion
+//#region src/generated/model/updateFlowDefinition200.d.ts
+type UpdateFlowDefinition200 = {
   /** 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. */
+  project_id: 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: UpdateFlowDefinition200FlowDefinition;
   created_at: string;
   updated_at: string;
 }; //#endregion
@@ -5839,7 +6504,7 @@ type UpdateFlowDefinitionBodyAudience = {
   /** 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[];
 }; //#endregion
-//#region src/generated/model/updateFlowDefinitionBodyStepsItemActions.d.ts
+//#region src/generated/model/updateFlowDefinitionBodyStepsItemActionsItem.d.ts
 /**
  * Generated by orval v8.10.0 🍺
  * Do not edit manually.
@@ -5848,25 +6513,23 @@ type UpdateFlowDefinitionBodyAudience = {
  * OpenAPI spec version: 0.0.1
  */
 /**
- * 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`.
 
  */
-type UpdateFlowDefinitionBodyStepsItemActions = {
-  [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;
-  };
+type UpdateFlowDefinitionBodyStepsItemActionsItem = {
+  /** 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;
 }; //#endregion
 //#region src/generated/model/updateFlowDefinitionBodyStepsItemComplete.d.ts
 /**
@@ -5993,7 +6656,7 @@ type UpdateFlowDefinitionBodyStepsItemSsoProvidersItem = {
 /**
  * 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`).
@@ -6042,11 +6705,11 @@ type UpdateFlowDefinitionBodyStepsItem = {
   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?: UpdateFlowDefinitionBodyStepsItemActions;
+  actions?: UpdateFlowDefinitionBodyStepsItemActionsItem[];
   /** 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
@@ -6065,7 +6728,7 @@ type UpdateFlowDefinitionBodyStepsItem = {
    */
   complete?: UpdateFlowDefinitionBodyStepsItemComplete;
   /** 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`).
@@ -6117,6 +6780,21 @@ type UpdateFlowDefinitionBody = {
  * Additional error-specific context.
  */
 //#endregion
+//#region src/generated/model/updateFlowDefinitionParams.d.ts
+/**
+ * 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
+ */
+type UpdateFlowDefinitionParams = {
+  /**
+   * The project id to filter by.
+   * @pattern ^[a-zA-Z0-9_-]+$
+   */
+  project_id: string;
+}; //#endregion
 //#region src/generated/model/verifyChallengeProof200ChallengesItemMethod.d.ts
 /**
  * Generated by orval v8.10.0 🍺
@@ -6409,7 +7087,7 @@ type VerifyChallengeProofBody = {
  * Alias of the orval-generated wire enum for field types so the atom's
  * accepted `type` values track the API contract exactly.
  */
-type ZlFieldType = CreateFlow201StepFieldsType;
+type ZlFieldType = CreateFlow201StepFieldsItemType;
 /**
  * Atom: `<zl-field>` — labelled input bound to a step `field`. Visual
  * spec lineage:
@@ -6447,6 +7125,7 @@ declare class ZlField extends LitElement {
   accessor pattern: string | undefined;
   accessor error: string;
   accessor success: string;
+  accessor testId: string | undefined;
   accessor forgotPasswordHref: string | undefined;
   accessor forgotPasswordLabel: string;
   accessor trailingIcon: boolean;
@@ -6455,6 +7134,7 @@ declare class ZlField extends LitElement {
   accessor invalid: boolean;
   private accessor hasHelp;
   private accessor hasSuffixSlot;
+  private accessor inputEl;
   private readonly inputId;
   private readonly internals;
   constructor();
@@ -6473,6 +7153,9 @@ declare class ZlField extends LitElement {
   private handleInput;
   private handleChange;
   private handleKeyDown;
+  private nativeInputTestId;
+  private dispatchNativeInput;
+  private dispatchNativeChange;
 }
 declare const zlFieldManifest: AtomManifest;
 declare global {
@@ -6513,6 +7196,12 @@ declare global {
 declare class ZlPageShell extends LitElement {
   static styles: _$lit.CSSResult[];
   render(): _$lit.TemplateResult<1>;
+  /**
+   * Re-render when a named slot's assignment changes so a footer/header added
+   * after first paint updates the empty-region class. The initial render reads
+   * children synchronously (no empty-then-filled flash).
+   */
+  private onSlotChange;
   private lightDomSlotFilled;
 }
 declare const zlPageShellManifest: AtomManifest;
@@ -6694,7 +7383,6 @@ declare class ZlPill extends LitElement {
   accessor tone: "neutral" | "pink" | "purple" | "orange" | "success";
   accessor href: string | undefined;
   accessor ariaLabel: string | null;
-  private surfaceClasses;
   render(): _$lit.TemplateResult<1>;
 }
 declare const zlPillManifest: AtomManifest;
@@ -6704,5 +7392,5 @@ declare global {
   }
 } //# sourceMappingURL=zl-pill.d.ts.map
 //#endregion
-export { GetKeys200 as $, CreateFlowDefinitionBody as A, SubmitFlowStepBody as At, CreateTeamBody as B, zlAlertManifest as Bt, CreateFlow201StepChallenge as C, ListSessionsParams as Ct, CreateFlowBody as D, RevokeTokenBody as Dt, CreateFlow201StepSsoProvidersItem as E, RevokeSessionParams as Et, CreateSchemaBody as F, ZlCard as Ft, EndSessionParams as G, CreateUser201 as H, ZlIcon as Ht, CreateSchemaParams as I, zlCardManifest as It, ExchangeHandoffParams as J, ExchangeHandoff200 as K, CreateSession201 as L, ZlButton as Lt, CreateProject201 as M, UpdateFlowDefinitionBody as Mt, CreateProjectBody as N, VerifyChallengeProof200 as Nt, CreateFlowBodyPurpose as O, SubmitFlowEventBody as Ot, CreateSchema201 as P, VerifyChallengeProofBody as Pt, GetHealthDefault as Q, CreateSessionBody as R, zlButtonManifest as Rt, CreateFlow201StepActions as S, ListSessions200 as St, CreateFlow201StepGates as T, ListUsersParams as Tt, CreateUserBody as U, zlIconManifest as Ut, CreateTeamParams as V, IconName as Vt, CreateUserParams as W, GetFlowDefinition200 as X, GetAuthAttempt200 as Y, GetFlowStep200 as Z, CreateAuthAttemptBody as _, IntrospectBody as _t, ZlPasskeyResultDetail as a, GetSchemaById200 as at, CreateFlow201BrandingLayout as b, ListFlowDefinitions200 as bt, zlPageShellManifest as c, GetSessionParams as ct, zlFieldManifest as d, GetToken200 as dt, GetLiveDefault as et, AuthorizeDevice200 as f, GetTokenBody as ft, CreateAuthAttempt201 as g, Introspect200 as gt, AuthorizeGetParams as h, GetUserInfo200 as ht, ZlPasskeyErrorDetail as i, GetReadyDefault as it, CreateHandoff200 as j, UpdateFlowDefinition200 as jt, CreateFlowDefinition201 as k, SubmitFlowStep200 as kt, ZlField as l, GetTeam200 as lt, AuthorizeGetDefault as m, GetUserByIDParams as mt, zlPillManifest as n, GetOpenIDConfiguration200 as nt, zlPasskeyManifest as o, GetSchemaByIdParams as ot, AuthorizeDeviceParams as p, GetUserByID200 as pt, ExchangeHandoffBody as q, ZlPasskey as r, GetProject200 as rt, ZlPageShell as s, GetSession200 as st, ZlPill as t, GetMySession200 as tt, ZlFieldType as u, GetTeamParams as ut, CreateFlow201 as v, IssueChallenge201 as vt, CreateFlow201StepFields as w, ListUsers200Item as wt, CreateFlow201Step as x, ListFlowDefinitionsParams as xt, CreateFlow201Branding as y, IssueChallengeBody as yt, CreateTeam201 as z, ZlAlert as zt };
-//# sourceMappingURL=index-Dd8hfOWt.d.mts.map
+export { GetFlowStep200 as $, CreateFlowDefinitionBody as A, RevokeTokenBody as At, CreateTeamBody as B, VerifyChallengeProofBody as Bt, CreateFlow201StepChallenge as C, ListFlowDefinitions200 as Ct, CreateFlowBody as D, ListUsers200Item as Dt, CreateFlow201StepSsoProvidersItem as E, ListSessionsParams as Et, CreateSchemaBody as F, SubmitFlowStepBody as Ft, DeleteFlowDefinitionParams as G, ZlAlert as Gt, CreateUser201 as H, zlCardManifest as Ht, CreateSchemaParams as I, UpdateFlowDefinition200 as It, ExchangeHandoffBody as J, ZlIcon as Jt, EndSessionParams as K, zlAlertManifest as Kt, CreateSession201 as L, UpdateFlowDefinitionBody as Lt, CreateProject201 as M, SetUserPasswordParams as Mt, CreateProjectBody as N, SubmitFlowEventBody as Nt, CreateFlowBodyPurpose as O, ListUsersParams as Ot, CreateSchema201 as P, SubmitFlowStep200 as Pt, GetFlowDefinitionParams as Q, CreateSessionBody as R, UpdateFlowDefinitionParams as Rt, CreateFlow201StepActionsItem as S, IssueChallengeBody as St, CreateFlow201StepGates as T, ListSessions200 as Tt, CreateUserBody as U, ZlButton as Ut, CreateTeamParams as V, ZlCard as Vt, CreateUserParams as W, zlButtonManifest as Wt, GetAuthAttempt200 as X, ExchangeHandoffParams as Y, zlIconManifest as Yt, GetFlowDefinition200 as Z, CreateAuthAttemptBody as _, GetUserByIDParams as _t, ZlPasskeyResultDetail as a, GetOpenIDConfiguration200 as at, CreateFlow201BrandingLayout as b, IntrospectBody as bt, zlPageShellManifest as c, GetSchemaById200 as ct, zlFieldManifest as d, GetSessionParams as dt, GetHealthDefault as et, AuthorizeDevice200 as f, GetTeam200 as ft, CreateAuthAttempt201 as g, GetUserByID200 as gt, AuthorizeGetParams as h, GetTokenBody as ht, ZlPasskeyErrorDetail as i, GetMyUser200 as it, CreateHandoff200 as j, SetUserPasswordBody as jt, CreateFlowDefinition201 as k, RevokeSessionParams as kt, ZlField as l, GetSchemaByIdParams as lt, AuthorizeGetDefault as m, GetToken200 as mt, zlPillManifest as n, GetLiveDefault as nt, zlPasskeyManifest as o, GetProject200 as ot, AuthorizeDeviceParams as p, GetTeamParams as pt, ExchangeHandoff200 as q, IconName as qt, ZlPasskey as r, GetMySession200 as rt, ZlPageShell as s, GetReadyDefault as st, ZlPill as t, GetKeys200 as tt, ZlFieldType as u, GetSession200 as ut, CreateFlow201 as v, GetUserInfo200 as vt, CreateFlow201StepFieldsItem as w, ListFlowDefinitionsParams as wt, CreateFlow201Step as x, IssueChallenge201 as xt, CreateFlow201Branding as y, Introspect200 as yt, CreateTeam201 as z, VerifyChallengeProof200 as zt };
+//# sourceMappingURL=index-DVDCrfkv.d.mts.map