Webhooks - Trying to understand ServerGen in the changeURL

[lightpro]

I'm trying to set up and test webhooks in AGOL and I'm not fully understanding what the ServerGen numbers returned in the change URL actually mean

For example, I've a webhook to monitor changes to a feature layer. The changeURL in the response payload is as follows:

https://services6.arcgis.com/FFFFFFFFFFFFFFFFF/arcgis/rest/services/myService/FeatureServer/extractChanges?serverGens=[248694,248697]&async=true&returnInserts=false&returnDeletes=false&returnAttachments=false

 According to the documentation, the ServerGen is the current server generation number of the changes. Every changed feature has a version or a generation number that is changed every time the feature is updated.

When I make one change to a single feature on my layer why is as array of serverGens included in the changeURL, [248649,248697] in the above URL for example? Should there not just be one ServerGen number associated with that change?

[MichaelVolz]

Are you getting unexpected or no results with your current webhook configuration?

[lightpro]

I've no issue with the webhook. I'm trying to understand what's happening better, specifically the ServerGen  numbers that are returned in the changeURL.

It doesn't make sense to me why one edit would produce an array of 2 numbers in the changeURL?

[LongDinh]

Usually the layerServerGen number sent to the /ExtractChanges endpoint is an epoch timestamp (in seconds) which retrieves changes from that particular datetime so perhaps it is the timestamp in minutes?

It's not documented in the ExtractChanges API but I suspect that the servergens request parameter is an array of timestamps in the order of the feature service's layers - a hidden method on the REST API. In your case, there are two layers in your feature service?

[lightpro]

Ok, the epoch timestamp makes sense! I also originally suspected that the array was somehow related to the no. of layers however my feature service has 9 layers so I don't think it's that!

Another odd thing I found was that when doing an extract changes query, often the json returned has a different servergen number than was was requested? Much higher than the requested number although the edits seem to be correct.

[LongDinh]

I suspect (and this is purely speculation from playing with the API) that the returned value is the toDate; the returned value is the next serverGen you should send to get the next set of latest changes. Since /extractChanges is a service level API, it takes time to get each set of changes from each layer for in the database's changes table.

On that same note, perhaps the serverGens array is a pair of start/end epoch timestamps denoting the fromDate/toDate which to extract changes?