<![CDATA[Why doesn't user.update.complete fire when email verification changes verified flag?]]>When using FusionAuth's email verification flow, the verified flag in user.data changes, but the user.update.complete webhook event does not fire.

We sync user state to external systems through the Kafka integration (using Azure Event Hub's Kafka endpoints). We expected user.update.complete to fire for all user mutations, including when the verified flag changes during the email verification process.

Without this event firing, we have to listen to both user.update.complete and user.email.verified events. However, since both events contain the verified flag on the user object and can fire simultaneously, this creates race conditions downstream — the Kafka integration doesn't guarantee ordering unless the partitioning strategy is keyed on userId.

Why doesn't user.update.complete fire when email verification changes the verified state? Is there a recommended approach to handle this scenario without encountering race conditions?

]]>https://fusionauth.io/community/forum/topic/3200/why-doesn-t-user-update-complete-fire-when-email-verification-changes-verified-flagRSS for NodeFri, 09 Oct 2026 00:09:21 GMTFri, 02 Oct 2026 23:48:06 GMT60<![CDATA[Reply to Why doesn't user.update.complete fire when email verification changes verified flag? on Fri, 02 Oct 2026 23:48:17 GMT]]>The user.update.complete event intentionally does not fire when the verified flag changes through email verification. This is by design.

Email verification is considered a distinct workflow separate from the general user update process in FusionAuth's event model. As noted in a related GitHub issue, the decision was made to introduce dedicated verification events rather than triggering user.update.complete because email verification "does not occur due to the Update User API, but because of a separate workflow." The user.update.complete event is reserved for changes made through the Update User API, while verification-specific changes trigger their own dedicated events.

Recommended Solution

You should listen to these specific webhook events for verification state changes:

Handling Race Conditions

If you're concerned about race conditions when multiple events fire simultaneously:

  1. Adjust your Kafka partitioning strategy to key on userId — this ensures all events for the same user go to the same partition and are processed in order
  2. Use event timestamps in your downstream consumers to deduplicate or order events correctly. Each event includes a createInstant field in the event object that can be used for ordering
  3. Design your sync logic to be idempotent so that processing events out of order doesn't cause inconsistent state

The separate user.email.verified and user.identity.verified events provide more granular control over what verification changes you respond to, which is generally more useful than a generic user update event.

Related Documentation

]]>https://fusionauth.io/community/forum/post/8737https://fusionauth.io/community/forum/post/8737Fri, 02 Oct 2026 23:48:17 GMT