Why synchronize identity data
Maintaining a local copy of identity data is useful when you need to:- Run analytics, reporting, or compliance queries without calling the Management API.
- Power search experiences that require low-latency lookups across user attributes.
- Feed data pipelines that join identity records with other business data.
- Maintain a backup of user profile state for disaster recovery.
How it works
- Auth0 publishes an event each time a user profile changes.
- Your Event Stream delivers that event to a destination (webhook, AWS EventBridge, or Auth0 Action).
- Your handler inspects the event type and applies the corresponding write operation to the external system.
| Event type | When it triggers |
|---|---|
user.created | A new user profile is created in Auth0. |
user.updated | An existing user profile is modified. |
user.deleted | A user profile is removed from Auth0. |
Prerequisites
Before you begin, make sure you have:- An Auth0 tenant with Events enabled. To learn more about plan availability, read Create an Event Stream.
- An active Event Stream subscribed to
user.created,user.updated, anduser.deleted. To learn more, read Create an Event Stream. - An external data store (for example, PostgreSQL, MySQL, or a data warehouse) that you can write to from your handler.
Implement data synchronization
The sections below demonstrate how to handle each event type. The handler functions are the same regardless of your Event Stream destination. The Route events by type section shows how to dispatch events for both webhook and Auth0 Action destinations.Handle user.created
When Auth0 publishes auser.created event, insert a new row in your database.
Handle user.updated
When Auth0 publishes auser.updated event, update the matching row. Compare the event timestamp against the last_event_processed column to avoid overwriting with stale data.
Events can arrive out of order. Always compare timestamps before applying updates to prevent stale data from overwriting newer records. To learn more, read Events Best Practices.
Handle user.deleted
When Auth0 publishes auser.deleted event, remove or soft-delete the matching row.
Route events by type
Use a top-level router to dispatch each event to the correct handler. The examples below show how to route events for webhook and Auth0 Action destinations.- Webhook
- Auth0 Action
Return an HTTP
2XX response as quickly as possible. If your handler needs to perform slow operations, place the event on an internal queue and process it asynchronously. To learn more, read Events Best Practices.Guard against duplicates and ordering issues
Event Streams provide at-least-once delivery, which means your handler may receive the same event more than once. To handle this safely:- Track event IDs. Store each processed event
idand skip any event you have already handled. - Compare timestamps. Each event payload includes
created_atandupdated_atfields on thedata.object. Use these fields to determine whether an incoming event is newer than what your system has already recorded. - Use idempotent writes. Structure your database operations so that applying the same event twice produces the same result. For example, use
INSERT ... ON CONFLICT DO UPDATEin PostgreSQL.
Verify synchronization
After you deploy your handler, create a test user in Auth0 and confirm:- A new row appears in your external database with the correct profile data.
- Update the user’s name or email in Auth0. Confirm the database row reflects the change.
- Delete the user in Auth0. Confirm the row is removed (or marked as deleted) in your database.