Based on the knowledge sources, I can explain the difference between your two Ory projects regarding the recovery flow behavior. ## Recovery Flow with Two-Factor Authentication The 422 error you're experiencing in one project is likely related to Two-Factor Authentication (2FA) settings. When an account has 2FA enabled, the recovery flow needs to redirect to the settings page, but this redirect might not be allowed in your configuration. The key difference between your projects could be: 1. 2FA Configuration: The project showing the 422 error likely has 2FA enabled with a configuration that requires the highest available authentication level (AAL). 2. Redirect Handling: In projects with 2FA, after submitting a recovery code, the user needs to be redirected to the settings page, but this redirect might not be properly configured. As mentioned in a GitHub issue: "For accounts with enabled 2FA, recovery flow doesn't navigate to settings on completion. One must manually add /ui/settings to allowed browser redirects." [Github Issue #363](https://github.com/ory/network/issues/363) ## How to Know When to Redirect to Settings Page For your second project, you should redirect to the settings page after a successful recovery flow submission. The recovery flow documentation states: "When a recovery flow is submitted, a session is issued to the application. This allows the user to reset their password and update their profile information on the settings page. Browser applications are automatically redirected to the settings page, while native applications must take the user to the settings page." [Ory Documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#recovery) To properly handle this: 1. For browser applications, the redirect should happen automatically 2. For native applications, you need to manually take the user to the settings page If you're using the API, you can check the response from the

updateRecoveryFlow

endpoint. A successful recovery will include a

continue_with

property that indicates the next action, which could be

show_settings_ui

. ## Possible Solutions If you're experiencing the 422 error, you might need to: 1. Add

/ui/settings

to your allowed browser redirects 2. Check your AAL (Authentication Assurance Level) settings - you might need to adjust

required_aal

in your configuration:

yaml selfservice:   flows:     settings:       required_aal: highest_available  session:   whoami:     required_aal: highest_available

You could try setting

required_aal

to

aal1

as a workaround, as mentioned in the GitHub issue [#222](https://github.com/ory/network/issues/222).

Yes, the difference between your projects could definitely be related to the

use_continue_with_transitions

feature flag. This is exactly what controls the behavior you're experiencing. According to the documentation, this feature flag affects how recovery flows work in native applications: > Ory Identities supports recovery flows in native applications. This allows you to build a native application that allows the user reset their password in the app without opening a browser. This flow is only available for the

code

method. > > Since enabling this alters the behavior of the native recovery flow, you need to enable it in the Ory Console or using the Ory CLI. The setting only affects the recovery flow for API clients. This feature flag is enabled by default for new projects, which explains why your projects behave differently. One project likely has this flag enabled while the other doesn't. ## Setting the Flag in the UI Yes, you can set this flag in the Ory Console UI: 1. Go to Project settings → Advanced in the [Ory Console](https://console.ory.sh/projects/current/settings/advanced) 2. Look for the feature flags section where you can enable/disable

use_continue_with_transitions

Alternatively, you can use the Ory CLI to update this setting as shown in the documentation: 1. Download your current configuration 2. Add the feature flag setting:

yaml    feature_flags:      use_continue_with_transitions: true

3. Update your configuration using the CLI When this flag is enabled, the recovery flow will use the

continue_with

transitions, which provides clearer guidance on what to do next (like redirecting to settings) rather than returning a 422 error. [Ory Documentation](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#native-recovery-flows)

Based on the knowledge sources provided, I can see that you're encountering an issue related to the

created_at

and

updated_at

fields when updating an identity's password via the API. There appears to be a known issue with the Ory Kratos API when creating or updating identities with credentials. According to a GitHub issue ([POST /admin/identities response fields unset](https://github.com/ory/network/issues/347)), when creating an identity with credentials, the response contains incorrect values for

credentials.identifiers

,

credentials.created_at

, and

credentials.updated_at

. The issue shows that when creating an identity with password credentials: -

credentials.identifiers

is set to

null

instead of an empty array -

credentials.created_at

and

credentials.updated_at

are set to

"0001-01-01T00:00:00Z"

instead of the actual creation time However, when retrieving the same identity afterward, these fields are correctly populated. Unfortunately, the knowledge sources don't indicate any way to explicitly set the

created_at

or

updated_at

timestamps when setting a password via the API. These fields appear to be managed internally by the system and aren't exposed as configurable parameters in the API request body for the

updateIdentity

endpoint. As a workaround, the GitHub issue mentions using

batchPatchIdentities

instead of

createIdentity

since the response from

batchPatchIdentities

doesn't contain the

credentials

field that causes parsing issues in some clients. If preserving the original

created_at

timestamp is critical for your use case, you might want to: 1. Retrieve the current identity data first 2. Note the existing timestamps 3. Make your update 4. Check if the timestamps were affected If this is a significant issue for your implementation, you might want to report it to the Ory team through their GitHub repository.