Why correlate identity changes
Correlating Auth0 identity events with external systems is useful when you need to:- Update a CRM record when a user’s email or profile data changes.
- Notify a billing or licensing system when an account is deactivated or deleted.
- Trigger compliance workflows when user attributes change, such as consent or role updates.
- Keep user segments in marketing platforms aligned with current identity data.
How it works
- Auth0 publishes an event when a user profile is created, updated, or deleted.
- Your Event Stream delivers that event to a destination (webhook, AWS EventBridge, or Auth0 Action).
- Your handler maps the Auth0 user to a record in the external system and applies the relevant update.
| 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 the event types you need. To learn more, read Create an Event Stream.
- API credentials for the external system you plan to update (for example, a CRM API key or OAuth token).
Implement identity correlation
The sections below demonstrate how to correlate Auth0 events with a CRM platform. 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.Map Auth0 users to external records
Most external systems identify contacts by email address or an external ID stored in Auth0app_metadata. Define a lookup function that resolves the external record for a given Auth0 user.
Handle user.created
When a new user is created in Auth0, create a corresponding contact in your external system.Handle user.updated
When a user profile changes, update the matching CRM contact with the new data.Handle user.deleted
When a user is removed from Auth0, deactivate or flag the corresponding record in your external system.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 external API calls are slow, place the event on an internal queue and process it asynchronously. To learn more, read Events Best Practices.Handle edge cases
When correlating identity data across systems, consider the following:- Missing external records. A
user.updatedevent may arrive for a user that does not yet exist in your external system. Decide whether to create the record or log it for manual review. - Rate limits on external APIs. If Auth0 delivers a burst of events (for example, during a bulk import), your handler may exceed the external API’s rate limits. Use an asynchronous queue with backoff to stay within limits.
- Partial data. Not every
user.updatedevent includes all profile fields. Apply only the fields present in the event payload to avoid overwriting data with empty values.
Example: Correlate with HubSpot CRM
The following Auth0 Action demonstrates a complete correlation handler that creates, updates, and deletes contacts in HubSpot CRM. The Action uses the HubSpot Contacts API to search for existing contacts by email and apply the corresponding operation.HUBSPOT_TOKEN in the Action editor. To learn more, read Action Secrets.
Verify correlation
After you deploy your handler, create or update a test user in Auth0 and confirm:- The corresponding record in your external system reflects the change.
- Delete the test user in Auth0. Confirm the external record is deactivated or removed.
- Review your handler logs for any errors or skipped events.