Identity Cloud Webhooks v3 API

📘

Click the link to download the Identity Cloud REST API Postman collection.

Webhooks v3 sends you near real-time notifications any time a user account is created, deleted, or modified. Sometimes these notifications are invaluable in safeguarding your website. For example, a sudden and unexpected flurry of password changes could indicate that your security has been breached and a malefactor is busy changing all your user passwords.

At other times these notifications are useful in improving the user experience. For example, suppose a user wants a copy of their user data. To do that, the user clicks a button in their user profile, an action that updates an attribute in their user record. Because the user record has changed, Webhooks can notify you that the request was made. In turn, and depending on how you’ve set up your system, you can send the information out mere minutes after the user requested it.

Regardless of what you choose to do with these notifications, Webhooks v3 is managed exclusively by using the Webhooks v3 API. The endpoints that make up the Webhooks v3 API enable you to do such things as:

• Manage webhook subscriptions. Subscriptions specify the events you’d like to be notified of. Would you like to know each time a user account is created? Then set up a webhook subscription that sends a notice each time an entityCreated event occurs. Would you prefer not to be notified each time a user account is deleted? Then don’t set up a webhooks subscription that sends a notice each time an entityDeleted event occurs.

• Create webhook subscription filters. Webhooks subscriptions don’t have to be all-or-nothing. Instead, you can pick and choose exactly which events you’d like to subscribe to. For example, maybe you don’t need notification if a user changes their street address or their middle initial, but, for security reasons, you're interested in tracking changes to email addresses and passwords. In that case, set up a filter that watches for instances of the entityUpdated event, but sends a notice only if the update was made to the email attribute or the password attribute.

• Redeliver “failed” events. Sometimes, and for some reason – a power failure, network congestion, server maintenance – webhook notifications can’t reach your listener endpoint (the server where notifications are sent). That sounds like a problem, and it would be a problem except for one thing: the Webhooks v3 API enables to see if you have any of failed events and, if so, allows you to schedule them for redelivery. Problem solved.

Note that all the Webhooks v3 endpoints require token-based authentication. If you aren’t familiar with token-based authentication and how to use it, take a look at the Get started article.