The request fails with HTTP 422 Unprocessable Entity for user creation or update | The place for Zendesk users to come together and share
Skip to main content
Question

The request fails with HTTP 422 Unprocessable Entity for user creation or update

  • June 8, 2026
  • 2 replies
  • 33 views
Y

 Hi Zendesk Support,

 

  We believe we've hit a bug (or at least unexpected behavior) in the Users API around user merge combined with the create-or-update endpoint.

 

  Environment

  - Endpoint: POST /api/v2/users/create_or_update

  - We sync users from our internal system into Zendesk. On every sync we send a payload containing email and external_id (in our case external_id is set

  to the user's email address).

 

  What we did

  1. We had two duplicate user records for the same person — one holding the email X  as its primary email, and another holding

  the same value as its external_id (with a different primary email).

  2. We merged these two users into a single user via the merge functionality, to consolidate them.

  3. After the merge, we called POST /api/v2/users/create_or_update to update the surviving user's information, sending the usual payload (email and

  external_id both set to X).

 

  What we expected

  After the merge, there is only one user record associated with X. We expected create_or_update to match that single user (by

  external_id / email) and update it in place.

 

  What actually happened

  The request fails with HTTP 422 Unprocessable Entity and the error:

 

  ▎ Email: X is already being used by another user

 

  This is confusing because, after the merge, there should no longer be "another user" holding that email. The merge appears to have left some lingering

  association (e.g. a secondary email identity or a stale record) that still claims this email address, so the email-uniqueness check fails even though the

  merge reported success.

 

  Questions / What we'd like help with

  1. Is this expected behavior after a merge? If so, what is the correct way to resolve the lingering email association?

  2. Is there a recommended sequence for merging users and then updating them via create_or_update that avoids this 422?

 

  Thanks in advance — happy to provide request/response payloads, timestamps, or correlation IDs if that helps you investigate.

 

  Best regards,

2 replies

marco_zerbini

Hi,

This is a known and documented behavior, not a bug per se, though it's definitely a footgun worth being aware of.

**Why it happens**

When Zendesk merges two users, the discarded user loses everything except tickets and email identities — those get transferred to the surviving user. So after your merge, email X is still present in the system, but now as a secondary identity on the surviving user rather than as a primary email on the discarded one.

The problem is that `create_or_update` resolves the target user by looking up both the `external_id` and the `email` you pass in the payload. If those two lookups resolve to the same user, it updates in place. If they resolve to different records, or if the email is found on an identity that is in an ambiguous state post-merge (e.g. attached to the surviving user as secondary but not yet fully reconciled), the endpoint bails with the 422 rather than risking a silent data collision.

In short: the merge succeeded, but the email identity it transferred is now "in use" on the surviving user in a way that `create_or_update` doesn't automatically handle.

**How to resolve the lingering identity (Question 1)**

After the merge, inspect the surviving user's identities:

```
GET /api/v2/users/{surviving_user_id}/identities
```

You will likely see email X listed as a secondary (non-primary) identity. From there you have two options depending on what you want:
- If X should be the primary email, promote it: `PUT /api/v2/users/{id}/identities/{identity_id}/make_primary`
- If X should just be removed as a redundant secondary, delete it: `DELETE /api/v2/users/{id}/identities/{identity_id}`

Once the identity state is clean and unambiguous, `create_or_update` will work correctly again.

Docs: https://developer.zendesk.com/api-reference/ticketing/users/user_identities/

**Recommended sync sequence going forward (Question 2)**

Rather than relying on `create_or_update` after a merge, a safer pattern for your sync flow is:

1. Look up the surviving user by `external_id` first:
`GET /api/v2/users/search?external_id={X}`
2. Take the user ID from the response and update directly:
`PUT /api/v2/users/{id}`

This bypasses the dual-lookup resolution logic in `create_or_update` entirely and targets the exact record you want, so email conflicts on secondary identities don't interfere.

If you want to keep using `create_or_update`, make sure to clean up the identities via the Identities API immediately after any merge before the next sync run hits that user.

Hope this helps unblock you!

Marco
    Alejandra L.
    • Alejandra L.Community Manager
    • Community Manager
    • June 8, 2026

    Thanks Marco this is really helpful! The explanation about the lingering email identity after merge makes the 422 much clearer, and the suggested cleanup/update flow gives us a good path forward!

     

    Terms & ConditionsAccessibility statement