Based on the error message and the patch operation you provided, it appears you encountered a conflict when trying to update an identity's metadata. This is a known behavior in Ory's identity management system. Let me explain what's happening and provide some context. The error message you received indicates a 409 Conflict status, which typically occurs when there's an attempt to create or update a resource that conflicts with an existing one. In the context of identity management in Ory, this can happen when updating metadata. According to the [Ory API Reference](https://www.ory.sh/docs/reference/api), the PATCH operation for updating identities can indeed return a 409 Conflict status in certain situations. The error message suggests that a resource with the value you're trying to set already exists. It's worth noting that the [Ory Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api) also mentions this possibility for the

patchIdentity

endpoint. To resolve this issue, you might want to consider the following approaches: 1. Check if the metadata you're trying to update already exists and if it needs to be updated. 2. If you're certain that the update should proceed, you might need to use a different operation type in your patch request, such as "add" instead of "replace", depending on your specific use case. 3. Ensure that the values you're setting in the metadata are unique if uniqueness is required for certain fields. If the problem persists, you may need to retrieve the current state of the identity first, then carefully construct your patch request to avoid conflicts. For more detailed information on handling errors during identity updates, you might want to check the [Ory documentation on bulk importing identities](https://www.ory.sh/docs/kratos/manage-identities/import-user-accounts-identities#errors-during-bulk-import), which provides examples of how errors are handled in batch operations. If you continue to face issues, it would be helpful to review the full context of your operation and possibly consult the Ory community forums or support channels for more specific assistance.

Based on the information you've provided and the knowledge sources available, I can offer some insights into why you're still encountering a 409 Conflict error even after changing the operation to "add". The conflict is likely occurring because you're trying to add metadata that already exists in the identity's

metadata_public

field. The 409 Conflict error suggests that Ory is preventing the operation to avoid unintended overwrites or duplications. Looking at the current

metadata_public

content you shared and comparing it to your patch request, we can see that all the fields already exist: 1.

accesses

2.

recovery_from

3.

registered_on

4.

parent_user_id

5.

is_verified

The only difference is the value of

is_verified

, which is

false

in the current metadata and

true

in your patch request. This behavior is consistent with what's described in the [Ory API Reference](https://www.ory.sh/docs/reference/api) for the

patchIdentity

endpoint. The API is designed to prevent conflicts when updating identity data. To resolve this issue, you have a few options: 1. Use the "replace" operation instead of "add" for updating existing fields. This is more appropriate when you're changing values of existing fields. 2. If you only want to update the

is_verified

field, you can target that specific field in your patch request:

json    [      {        "op": "replace",        "path": "/metadata_public/is_verified",        "value": true      }    ]

3. If you need to update multiple fields, you can use multiple operations in your patch request, each targeting a specific field that needs to be updated. 4. If you're certain you want to overwrite the entire

metadata_public

object, you might need to use the

updateIdentity

endpoint instead of

patchIdentity

. This would allow you to replace the entire metadata object. Remember, the PATCH operation is designed for partial updates, and Ory's implementation is trying to prevent accidental data loss or unintended overwrites. If you need to completely replace the metadata, consider using a PUT operation (if available) or the appropriate update endpoint. If you continue to face issues after trying these approaches, it might be helpful to consult the [Ory community forums](https://github.com/ory/network/issues) or Ory's support channels for more specific assistance with your use case.

To add phone identifiers to the credentials section of an identity in Ory, you need to modify your identity schema and ensure that the phone number field is properly configured as an identifier. Let me guide you through this process based on the information from the Ory documentation. 1. First, you need to update your identity schema to include the phone number as an identifier. Here's an example of how to do this: [Customize identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#phone-number)

json {   "$id": "<https://example.com/registration.schema.json>",   "$schema": "<http://json-schema.org/draft-07/schema#>",   "title": "Person",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "phone": {           "type": "string",           "format": "tel",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": {                 "identifier": true               }             }           }         }       }     }   } }

2. In this schema, the

"identifier": true

property under

"password"

indicates that the phone number can be used as an identifier for password-based authentication. 3. Once you've updated your schema, you can create or update an identity with both email and phone number identifiers. The credentials section should look similar to what you've provided:

json "credentials": {   "password": {     "type": "password",     "identifiers": [       "<mailto:xxxxx@gmail.com|xxxxx@gmail.com>",       "+51234455"     ]   } }

4. Note that you don't need to include the

mailto:

prefix for email addresses. Ory will handle the email format internally. 5. When creating or updating an identity, make sure to include the phone number in the

traits

section as well:

json "traits": {   "email": "<mailto:xxxxx@gmail.com|xxxxx@gmail.com>",   "phone": "+51234455" }

By following these steps, you should be able to add both email and phone identifiers to an identity in Ory. This configuration allows users to log in using either their email address or phone number. Remember that changes to the identity schema may require updates to your existing identities and potentially your application logic to handle multiple identifier types. For more detailed information on customizing identity schemas and handling multiple identifiers, you can refer to the [Ory documentation on customizing identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#multiple-identifiers).

Based on the scenario you've described, it appears you're encountering an issue with updating an existing identity after modifying the identity schema. This is a known challenge when working with Ory Kratos, especially when changing the schema to include new identifiers. Let me explain why this is happening and suggest some potential solutions. The problem you're facing is likely due to the mismatch between the old identity schema (without phone as an identifier) and the new schema (with phone as an identifier). When you try to patch User A, who was created with the old schema, Ory Kratos is attempting to apply the new schema rules, which can lead to conflicts. Here are a few approaches you can consider to resolve this issue: 1. Update the existing identity: You might need to manually update User A's identity to include the phone number as an identifier. This can be done using the Admin API, specifically the

patchIdentity

endpoint. However, you'll need to be careful to format the patch request correctly to avoid conflicts. 2. Migrate the identity: You may need to perform a migration of the existing identities to match the new schema. This process isn't automatically handled by Ory Kratos and would require you to write a custom migration script. 3. Version your schemas: In the future, consider versioning your identity schemas. This allows you to maintain backwards compatibility with existing identities while introducing new schema versions for new users. 4. Use a more flexible schema: Design your identity schema to be more flexible from the start, anticipating potential future changes. For example, you could include the phone field in the initial schema but not mark it as an identifier, then update it to be an identifier later. It's worth noting that changing identity schemas, especially in ways that affect core functionality like identifiers, can be complex and potentially disruptive. The [Ory documentation on customizing identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema) recommends careful planning when making such changes. If you continue to face issues, you might want to consider reaching out to the Ory community or support channels for more specific guidance on migrating existing identities to a new schema structure. They may be able to provide more tailored advice based on your exact setup and requirements. Remember, when making significant changes to identity schemas in a production environment, it's always a good idea to thoroughly test the changes in a staging environment first and have a rollback plan in place.