To patch Kratos identity traits when the schema has changed but the user is already created in the database, you need to update both the identity's schema ID and its traits to match the new schema. This can be done using the Admin API, specifically the patchIdentity endpoint, which allows you to apply JSON Patch operations to the identity. Here’s how you can do it: ### 1. Prepare the Patch Request Use the PATCH method on the identity, specifying the changes you want to make. For example, to change the schema ID, remove an old trait, and add a new trait:

bash curl --location --request PATCH "https://$<http://ORY_SLUG.projects.oryapis.com/admin/identities/$IDENTITY_ID|ORY_SLUG.projects.oryapis.com/admin/identities/$IDENTITY_ID>" \ --header "Authorization: Bearer $ORY_API_KEY" \ --header "Content-Type: application/json" \ --data-raw '[   {     "op": "replace",     "path": "/schema_id",     "value": "{new-schema-id}"   },   {     "op": "remove",     "path": "/traits/foo"   },   {     "op": "add",     "path": "/traits/bar",     "value": "barfoo"   } ]'

- Replace

{new-schema-id}

with your new schema ID. - Adjust the traits operations as needed to match your new schema requirements. ### 2. Validate the Update The response should return the updated identity. Make sure the traits now conform to the new schema. ### 3. Repeat for Other Identities If you have multiple identities to update, repeat the process for each one. ### Notes - Using patchIdentity is the recommended way to update identities after a schema change. - Make sure to update the traits so they are valid according to the new schema, otherwise the request will fail validation. - You can also use the Ory SDKs to perform these operations programmatically if you prefer. For more details and example code (including Go SDK usage), see the official documentation: [Update identities to use a new schema](https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identities-to-use-a-new-schema)

Based on the available knowledge sources, patching an identity (such as updating traits or schema) is intended to be performed via the Admin API endpoints like patchIdentity or updateIdentity, which require admin privileges and an API key. There is no documentation or official guidance indicating that you can patch or update an identity's schema or traits during the login process (i.e., as part of the self-service login flow). The self-service flows (login, registration, settings) are designed for user-driven actions such as authentication, registration, or updating profile information (traits) via the settings flow, but not for arbitrary admin-level patching of identities. The settings flow allows users to update their own traits, but this is not the same as patching the identity in the sense of changing the schema or performing admin-level updates. Admin-level changes, such as changing the schema ID or making structural changes to traits, must be done via the Admin API and not during the login process [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata) [Update identities to use a new schema](https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identities-to-use-a-new-schema). In summary: No, you cannot patch the identity (e.g., change schema or admin-level traits) during the login process. Such operations must be performed using the Admin API. The login process is not designed for this purpose, and there is no support for admin-level patching during user login in the current Ory Kratos flows.

After a schema change has been deployed in Ory Kratos, updating new trait properties for users during their next login is not handled automatically by the login flow. The login process itself does not update or patch user traits to match the new schema. Instead, users will continue to use their existing traits until those are explicitly updated. How to update traits after a schema change: - Admin API Required: To update existing users' traits to match the new schema, you must use the Admin API (e.g.,

patchIdentity

or

updateIdentity

). This is a manual or programmatic process that you need to trigger outside of the login flow [Update identities to use a new schema](https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identities-to-use-a-new-schema). - Settings Flow for User-Editable Traits: If the new schema adds traits that are user-editable (e.g., new profile fields), users can update these themselves via the self-service settings flow. However, this requires the user to actively visit the settings/profile page and submit the new data. The login flow does not prompt for or update these fields automatically [Settings and profile updates](https://www.ory.sh/docs/kratos/self-service/flows/user-settings). - Validation on Write: If a user attempts to update their profile (traits) and the data does not conform to the new schema, the update will fail validation until the required fields are provided [Identity schema best practices](https://www.ory.sh/docs/kratos/manage-identities/best-practices). Summary: After deploying a new schema, you must use the Admin API to update existing users' traits, or rely on users to update their own traits via the settings flow. The login process does not automatically update or prompt for new trait properties introduced by a schema change.

To patch your identity Jsonnet mapping when new trait properties are introduced, you need to update your Jsonnet code to map the new properties from the external data (such as OIDC claims) to the corresponding fields in your identity schema. Steps: 1. Update the Identity Schema: First, ensure your identity schema includes the new trait properties you want to support. This is required so that the mapped data will be valid when processed by Ory Kratos [Customize identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema). 2. Modify the Jsonnet Mapping: Edit your Jsonnet mapping to include the new properties. For example, if you add a new trait called

department

, update your Jsonnet like this:

jsonnet    local claims = std.extVar('claims');     {      identity: {        traits: {          email: claims.email,          [if "department" in claims then "department" else null]: claims.department,          // Add other new traits as needed        },      },    }

This approach ensures that the new trait is only set if it exists in the incoming claims, making the mapping robust to missing data [Data mapping with Jsonnet](https://www.ory.sh/docs/kratos/reference/jsonnet). 3. Deploy the Updated Mapping: - If you are using Ory Network, encode your updated Jsonnet file in Base64 or host it at a URL, and update your provider configuration to reference the new mapping [Data mapping](https://www.ory.sh/docs/kratos/social-signin/ory#data-mapping). - For Ory Kratos, update the configuration to use the new Jsonnet mapping. 4. Test the Mapping: After deploying, test the flow (e.g., OIDC login or SCIM sync) to ensure the new trait is correctly mapped and stored in the identity. Tip: If you want to make the new trait optional, use the conditional key syntax as shown above. If the trait is required, ensure your schema and mapping always provide a value. For more details and examples, see the official documentation on [Data mapping with Jsonnet](https://www.ory.sh/docs/kratos/reference/jsonnet) and [Social sign-in data mapping](https://www.ory.sh/docs/kratos/social-signin/ory#data-mapping).