Webhook oddities and general questions

[RogerAsbury]

I have added a webhook to a view of one of our feature layers so that I can get notified when changes are made to any of the features (trigger featureEdit). This webhook appears to work... oddly... for lack of a better phrase.

Here is the setup:

This seems to suggest an interval of 30 seconds after changes are made, but in reality, I've seen times from four to ten minutes, which seems crazy for a webhook. I'm guessing this allows for more changes per response, which is fine, but still rather slow.

Second, the resultant package seems to contain old edits that were already sent. I'm attaching an example. In the example the only new changes since the last time the webhook triggered were changes to the feature with OBJECTID 1. In this case the EVENT_NAME and POLY_STATUS fields were updated. Which leads to the questions:

1. Why are older edits still showing here? Is there a way to prevent this?
2. Why does it not tell you what was edited? Like a before edit/after edit? There's no indication here what changed.
3. Is there a way to NOT show geometry as it's not needed here and just makes for a much larger to process payload?
    

[RogerAsbury]

Figured I'd repost what I received after turning this community question into a support request.
-----

I reviewed your Esri Community post and took a close look at the structure of the triggerJSON.txt payload you shared. I would like to provide some initial architectural insights regarding the specific behaviors you are encountering, which should help clarify how ArcGIS Online handles these events natively:

1. High latency (4–10 minutes delay):

Unlike immediate transactional webhooks, feature layer webhooks in ArcGIS Online operate on an internal batch-processing scheduler. Editions are grouped and dispatched based on an internal server cycle (controlled by a background property called scheduleInterval, which typically defaults to a 5-minute polling window). If there is a high volume of server events queued in the organization, this processing interval can extend further.

2. Payload data overlapping (repeated items):

In your JSON file, I noticed that the webhook is tracking a specific serverGen (Server Generation ID) and utilizes esriDataChangesResponseTypeEdits as the response type.
When ArcGIS Online sends this payload to your Azure Function, it expects a rapid HTTP 200 OK response to acknowledge successful delivery. Because your payload carries heavy geometry features (such as the extensive coordinate rings of the wildfire polygon), if the Azure Function experiences any processing lag or timeout before sending the HTTP 200 response, ArcGIS Online will assume delivery failed. Consequently, it will re-send the exact same serverGen batch during the next cycle, creating the overlapping data you are seeing.

3. Identifying specific Feature changes ("Diff"):

By design, ArcGIS Online webhooks send a "snapshot" of the feature's current state (its geometry and updated attribute array) rather than an explicit delta of what field changed (e.g., it will not explicitly state "Field X changed from A to B"). To determine exact modifications, the standard industry practice is to program the receiving application (the Azure Function) to store the prior state and perform a property comparison against the incoming JSON.