Webhook event filters and personal information

In addition to application IDs, client IDs, and entity types, organizations are often interested in user profile attributes: they want to be notified when users change their passwords or their email addresses or their mobile device numbers. And that’s fine: pretty much any attribute in your entity types, including custom attributes you create yourself, can be used in an event filter )

However, there is a catch here. As you know, a user’s personal information (such as an email address or a phone number or even a first or last name) is never included in a Webhooks notification. For example, with an entityUpdated event you’ll get back the user’s UUID (the sub) claim, and you’ll get back the list of attributes that have been updated:

  "events": {
    "entityUpdated": {
       "captureApplicationId": "zzyn9gy9r8xdy5zkru4y54syk6",
       "captureClientId": "elrrniux51a3nrhfwzklvz3t46lb5n2m",
       "entityType": "user",
       "globalSub": "capture-v1://us.janraincapture.com/zzyn9gy9r8xdy5zkru4y54syk6/user/6b004bc5-179c-45c2-815d-31b06169371d",
       "sub": "6b004bc5-179c-45c2-815d-31b06169371d",
       "attributes": [
       "id": "e0a70b4f-1eef-4856-bcdb-f050fee66aae"

In this notification we can see that a user has changed their city, state, and country. But which user made these changes? The event notification doesn’t tell us. (Or at least not directly. However, the user’s UUID is listed as the value of the sub claim, which means that we can look up the user responsible for the event).

Similarly, we know that three attributes were updated:

  • primaryAddress.city
  • primaryAddress.state
  • primaryAddress.country

However, we don’t know the previous values for these attributes nor do we know the new values for these attributes. That information isn’t included in a Webhooks notification.

In other words, using a filter you can create a Webhooks subscription that looks for events where a specific attribute or set of attributes were changed. However, you can't get any more specific than that; for example, you can’t create a subscription that looks for events where a user switched email providers to Gmail, or where a user changed their country of residence to Belgium, or where a user decided to withdraw their marketing consent. You can tell which attributes have been changed, but that's pretty much it. To find out the new value for an attribute you'd have to look use the UUID to locate the user account (using either Console or the Configuration APIs) and look up the new value.