Unclear what current & previous property holds

Hello, a couple of days ago we noticed our webhook (which listens on all object and all actions [*.*]) started erroring when a user is updated.
An example of this is simply when a user logs in, this would send us an update (because last_login changes) which would contain the current property as an array.
After a rather long chat support interaction I got a point where this is by design, but I have no idea what it means when the current property contains multiple objects. So far all the request for our webhook simply contained a single object in the array (so the array seemed useless).

Do webhooks now somehow support batching? Should we prepare to handle multiple objects being updated via a single webhook request?

The documentation was updated today to say that both the current and previous field CAN be an array, but doesn’t say when it happens and what it means for us.

Also from observation, this only happens for the User endpoint, others seem to work fine (Deal, Activity are the ones we handle).

1 Like

Hi @tomaskallup
Welcome to the community :wave: That’s a very good catch and sorry about the confusion. Apparently, the changes specific to the user object is different compared to the rest of the other objects based on my observation.

I am currently checking this with the engineering team. Couple of questions to understand this much better

  • Can you share the before vs after changes in the received payload that resulted in the error?
  • I agree that it sounds ambiguous but have you noticed more than one change object when it was represented as an array of objects (with regards to current & previous property)

Feel free to add screenshots or snippets of changes to the thread.

Hi @DevRel, thanks for the response.

To answer your questions:

Can you share the before vs after changes in the received payload that resulted in the error?

We didn’t have a hook setup for Users before, so I can’t say if the payload was different before. What started erroring was our validation, which expected the updated object to be an object and with Users it was an array. The difference is only in User vs other objects, where there is no array.

I agree that it sounds ambiguous but have you noticed more than one change object when it was represented as an array of objects (with regards to current & previous property)

As far as I’ve checked, the array always included a single object. There were never more, so our quick fix is to just take the first one and handle that.

This is what the payload looks like right now.

My confusion is mainly what it would mean if multiple objects were present in that array and how to replicate such scenario, so we can implement it properly.

Hey @tomaskallup
Thanks for sharing this in detail. I had the chance to check this with the engineering team. It seems to be a case of payload inconsistency only for user object-related changes. As you rightly pointed out, there will only be one single object in that array and no more than that.

You can perform a 1-on-1 comparison on a property level without having to worry about n-to-n scenarios.

We are also currently looking at payload standardization and we hope to keep you informed when that happens :slight_smile:

So does that mean in the future this will be resolved to not be and array (or all of the webhooks will use array in the payload)? If so, I’m happy with that right now, I’ll keep our workaround of “just taking the first element from the array” and once the payload is standardized, we’ll update our implementation.

Thanks @tomaskallup !

This will be fixed in the future as part of payload standardization. I would recommend subscribing to our changelog to stay updated :slight_smile: