@zitadel/api 0.0.0 → 0.1.0-alpha.10

package/src/generated/model/createFlow201.ts

@@ -18,9 +18,10 @@ export type CreateFlow201 = {
   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

package/src/generated/model/createFlow201Step.ts

@@ -5,18 +5,19 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
-import type { CreateFlow201StepActions } from "./createFlow201StepActions";
+import type { CreateFlow201StepActionsItem } from "./createFlow201StepActionsItem";
 import type { CreateFlow201StepChallenge } from "./createFlow201StepChallenge";
 import type { CreateFlow201StepComplete } from "./createFlow201StepComplete";
-import type { CreateFlow201StepFields } from "./createFlow201StepFields";
+import type { CreateFlow201StepFieldsItem } from "./createFlow201StepFieldsItem";
 import type { CreateFlow201StepGates } from "./createFlow201StepGates";
 import type { CreateFlow201StepSsoProvidersItem } from "./createFlow201StepSsoProvidersItem";
 import type { CreateFlow201StepTexts } from "./createFlow201StepTexts";
 
 /**
- * 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.
 
  */
 export type CreateFlow201Step = {
@@ -35,16 +36,16 @@ export 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.

package/src/generated/model/{createFlow201StepActions.ts → createFlow201StepActionsItem.ts}

@@ -7,22 +7,22 @@
  */
 
 /**
- * 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`.
 
  */
-export type CreateFlow201StepActions = {
-  [key: string]: {
-    /** Marks this as the default/primary action. The runtime template uses
+export 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
+  primary?: boolean;
+  /** Optional localization key override for the action's label. When
   omitted, the engine derives a key from the step and action names.
   Display text is resolved client-side from a locale dictionary, never
   by the engine.
    */
-    text_key?: string;
-  };
+  text_key?: string;
 };

package/src/generated/model/createFlow201StepFieldsItem.ts

@@ -0,0 +1,46 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { CreateFlow201StepFieldsItemType } from "./createFlow201StepFieldsItemType";
+import type { CreateFlow201StepFieldsItemValidation } from "./createFlow201StepFieldsItemValidation";
+
+/**
+ * A data input capability. Describes what the user must provide.
+Does not contain display text — only a `text_key` resolved client-side.
+
+ */
+export 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;
+};

package/src/generated/model/createFlow201StepFieldsItemType.ts

@@ -0,0 +1,31 @@
+/**
+ * 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 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.
+
+ */
+export type CreateFlow201StepFieldsItemType =
+  (typeof CreateFlow201StepFieldsItemType)[keyof typeof CreateFlow201StepFieldsItemType];
+
+export const CreateFlow201StepFieldsItemType = {
+  text: "text",
+  email: "email",
+  password: "password",
+  tel: "tel",
+  number: "number",
+  url: "url",
+  date: "date",
+  hidden: "hidden",
+  checkbox: "checkbox",
+  select: "select",
+} as const;

package/src/generated/model/{createFlow201StepFieldsValidation.ts → createFlow201StepFieldsItemValidation.ts}

@@ -5,7 +5,7 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
-import type { CreateFlow201StepFieldsValidationFormat } from "./createFlow201StepFieldsValidationFormat";
+import type { CreateFlow201StepFieldsItemValidationFormat } from "./createFlow201StepFieldsItemValidationFormat";
 
 /**
  * Schema-derived rules the frontend SHOULD apply at input time. The
@@ -18,14 +18,14 @@ Each key mirrors a JSON Schema keyword on the underlying user
 property; absent keys mean no rule.
 
  */
-export type CreateFlow201StepFieldsValidation = {
+export 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
@@ -36,4 +36,10 @@ export 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[];
 };

package/src/generated/model/{submitFlowStep400StepFieldsValidationFormat.ts → createFlow201StepFieldsItemValidationFormat.ts}

@@ -14,10 +14,10 @@ sufficient for client-side validation. When `type` is `text`
 (e.g. `format: uuid`), this key is the only signal.
 
  */
-export type SubmitFlowStep400StepFieldsValidationFormat =
-  (typeof SubmitFlowStep400StepFieldsValidationFormat)[keyof typeof SubmitFlowStep400StepFieldsValidationFormat];
+export type CreateFlow201StepFieldsItemValidationFormat =
+  (typeof CreateFlow201StepFieldsItemValidationFormat)[keyof typeof CreateFlow201StepFieldsItemValidationFormat];
 
-export const SubmitFlowStep400StepFieldsValidationFormat = {
+export const CreateFlow201StepFieldsItemValidationFormat = {
   email: "email",
   "date-time": "date-time",
   uuid: "uuid",

package/src/generated/model/createFlowDefinition201.ts

@@ -5,158 +5,25 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+import type { CreateFlowDefinition201FlowDefinition } from "./createFlowDefinition201FlowDefinition";
 
 export 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;
+  /** 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: CreateFlowDefinition201FlowDefinition;
   created_at: string;
   updated_at: string;
 };

package/src/generated/model/createFlowDefinition201FlowDefinition.ts

@@ -0,0 +1,58 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { CreateFlowDefinition201FlowDefinitionAudience } from "./createFlowDefinition201FlowDefinitionAudience";
+import type { CreateFlowDefinition201FlowDefinitionStepsItem } from "./createFlowDefinition201FlowDefinitionStepsItem";
+
+/**
+ * A flow definition is the server-side configuration that describes a complete
+authentication or identity flow. It is NOT sent to the frontend — the flow
+engine evaluates it and produces FlowResponse payloads (steps with capability
+dictionaries) for the client.
+
+Flow definitions are created by administrators and stored in the project/team
+configuration hierarchy. The engine selects the matching definition based on
+the purpose + audience when a flow is created via POST /flow.
+
+ */
+export type CreateFlowDefinition201FlowDefinition = {
+  /**
+     * 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?: CreateFlowDefinition201FlowDefinitionAudience;
+  /**
+     * Ordered list of steps in this flow. The order is for human readability —
+  actual step sequencing is determined by transitions.
+
+     * @minItems 1
+     */
+  steps: CreateFlowDefinition201FlowDefinitionStepsItem[];
+};

package/{dist/generated/model/updateFlowDefinitionBodyAudience.d.ts → src/generated/model/createFlowDefinition201FlowDefinitionAudience.ts}

@@ -5,6 +5,7 @@
  * This is the next generation of the Zitadel identity platform.
  * OpenAPI spec version: 0.0.1
  */
+
 /**
  * Scopes which teams or apps this flow definition applies to. Empty or
 omitted fields mean "no restriction"; when both are empty the definition
@@ -12,10 +13,9 @@ matches every request in the project. The engine picks the most specific
 matching definition: app > team > project-wide.
 
  */
-export type 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[];
+export 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[];
 };
-//# sourceMappingURL=updateFlowDefinitionBodyAudience.d.ts.map

package/src/generated/model/createFlowDefinition201FlowDefinitionStepsItem.ts

@@ -0,0 +1,71 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { CreateFlowDefinition201FlowDefinitionStepsItemActionsItem } from "./createFlowDefinition201FlowDefinitionStepsItemActionsItem";
+import type { CreateFlowDefinition201FlowDefinitionStepsItemComplete } from "./createFlowDefinition201FlowDefinitionStepsItemComplete";
+import type { CreateFlowDefinition201FlowDefinitionStepsItemGates } from "./createFlowDefinition201FlowDefinitionStepsItemGates";
+import type { CreateFlowDefinition201FlowDefinitionStepsItemOnSuccess } from "./createFlowDefinition201FlowDefinitionStepsItemOnSuccess";
+import type { CreateFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem } from "./createFlowDefinition201FlowDefinitionStepsItemSsoProvidersItem";
+import type { CreateFlowDefinition201FlowDefinitionStepsItemTransitions } from "./createFlowDefinition201FlowDefinitionStepsItemTransitions";
+
+/**
+ * A step in a flow definition. This is the admin-authored configuration,
+not the runtime payload sent to the frontend.
+
+Steps are schema-driven: `fields` references properties from the flow's
+user schema, and the engine resolves field metadata (type, validation,
+implicit outcomes) from schema annotations at runtime.
+
+A step with only `complete` set is a terminal step. All other steps are
+rendered to the frontend as capability payloads.
+
+ */
+export type CreateFlowDefinition201FlowDefinitionStepsItem = {
+  /** 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?: 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?: 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?: 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?: CreateFlowDefinition201FlowDefinitionStepsItemComplete;
+  /** 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?: CreateFlowDefinition201FlowDefinitionStepsItemTransitions;
+};

package/src/generated/model/createFlowDefinition201FlowDefinitionStepsItemActionsItem.ts

@@ -0,0 +1,28 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+
+/**
+ * Configuration for a user-invokable action on a step. The `name` is sent
+back in the submit request as `action`.
+
+ */
+export type 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;
+};

package/src/generated/model/createFlowDefinition201FlowDefinitionStepsItemComplete.ts

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

package/src/generated/model/createFlowDefinition201FlowDefinitionStepsItemGates.ts

@@ -0,0 +1,35 @@
+/**
+ * Generated by orval v8.10.0 🍺
+ * Do not edit manually.
+ * Zitadel NextGen
+ * This is the next generation of the Zitadel identity platform.
+ * OpenAPI spec version: 0.0.1
+ */
+import type { CreateFlowDefinition201FlowDefinitionStepsItemGatesConfig } from "./createFlowDefinition201FlowDefinitionStepsItemGatesConfig";
+import type { CreateFlowDefinition201FlowDefinitionStepsItemGatesKind } from "./createFlowDefinition201FlowDefinitionStepsItemGatesKind";
+
+/**
+ * Security gates that must be satisfied before submission. Keyed by gate
+name. Each gate selects a kind (e.g. "captcha") and provider-specific
+configuration. The engine may also inject gates dynamically based on
+policy.
+
+ */
+export type 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: CreateFlowDefinition201FlowDefinitionStepsItemGatesKind;
+    /** 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?: CreateFlowDefinition201FlowDefinitionStepsItemGatesConfig;
+  };
+};

package/{dist/generated/model/createFlow201StepGatesConfig.d.ts → src/generated/model/createFlowDefinition201FlowDefinitionStepsItemGatesConfig.ts}

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