This post in the Khoros community is from someone who has not read the documentation.
Developers who are unaccustomed to the basic premise of a webhook need to know that the hook is designed to be a notification of the change, not the actual changed value.
When a change that matches the webhook’s specification occurs, we send a notification via a POST request to the relevant webhook’s notification URL containing the base ID and the webhook ID.
The client (your webhook listener) is obligated to intelligently unpack the notification payload and use it (and following notifications) to understand the nature of the change.
The recipient of this request should respond with an HTTP 200 or 204 status code and an empty response body. After successful delivery, the recipient of this notification is then responsible for requesting the contents of the updates from the API (using list webhook payloads) in a separate HTTP request.
I could be wrong, but I don’t get the sense that this user is doing this. I think he’s assuming a webhook POST is a one-and-done proposition.
Well, it is different because, unlike the events in the client, the Enterprise API sends all sorts of information useful to understanding the likelihood that a field edit has been completed. As a developer, it’s your duty to build a listener that takes advantage of this added stream of data.