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": [
"primaryAddress.city",
"primaryAddress.state",
"primaryAddress.country"
],
"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.
Updated over 1 year ago