> For the complete documentation index, see [llms.txt](https://docs.tryterra.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryterra.co/help-center/help-topics/no-data/auth-scopes-user-id-matching/reauth-webhook-user-id-changes.md).

# How do I handle a changed Terra user ID after reauth?

When a Terra user ID changes, the user **reauthenticated** (reconnected the same provider account under the same `reference_id`). Terra issues a new `terra_user_id` and sends a **`user_reauth` webhook** that includes the `old_user_id`.

**Add handling for `user_reauth`:**

* Use `old_user_id` to **map the new id to the previous one** (stitching historic data across reauths without needing a fresh backfill).
* **Treat it like a deauth of the old id.** The subsequent `auth` webhook creates the new id.

If you match webhooks on both `reference_id` and `user_id`, you must process `user_reauth` so the new id is recognised.

A common cause of reconnects appearing to 'not work' is the reauth flow **not reusing the original `reference_id`**: a new `reference_id` creates a new Terra user and orphans the old one, so key the widget call on a stable internal user ID. See [handling authentication events](https://docs.tryterra.co/health-and-fitness-api/user-authentication/handling-authentication-events).