The only catalog webhook appears to be the “catalog.version.updated” one, which contains the JSON below, but the ID of “732b6677-1acb-4d81-b09c-5a3a49399d8f” does not appear to relate to anything useful - it is not the ID of the catalog item that was actually changed. The catalog item IDs are formatted like “73X5WSPXUFUDFD2UWPZF6SWE”, so even with the webhook below, there is no way to know which item was updated or query for it.
What is the point of the ID below, and how can we get notifications when a specific item changes, so we can update another system? Is this webhook useless for this, and we just have to constantly poll the entire catalog item list for changes?
Hey there – The ID here is likely the “event_id” which assigns a unique ID to each webhook sent. See this reference for details.
Unfortunately the Catalog API doesn’t offer webhooks for specific items, but it’s worth considering in the future. Since Catalogs can be updated in bulk, there could be thousands of items updated in a single instance, spawning a massive number of webhooks. It’s possible a feed with optional subscriptions would work better here, but we’ll need to dig in further.
If you’re monitoring for a small number of items, you could batch retrieve those items each time you see a webhook as opposed to pulling the entire catalog.
No, it is not the “event_id”, see your documentation here - the full webhook is below. Thanks for the reply, but what is this other ID? The doc calls it the “ID of the affected object”, but it is not that - the ID of the affected item in this case was 73X5WSPXUFUDFD2UWPZF6SWE.
We want to update another system every time a catalog change of any kind is made, so it sounds like the only option is polling the entire catalog, no?
It doesn’t give any specifics, only that the catalog has been updated. The recommended method - and the one I use - is to store a last update timestamp somewhere, and when a catalog update event comes in you call “Search catalog objects” and use the date you store as the “begin_time” parameter for the call. This way you only pull back the objects that have been updated since the last search. You can also specify the object_types and whether or not to include_deleted_objects. You of course also want to update your date/timestamp immediately after pulling in the objects so you have an accurate stamp of the last time you got changes.
How do you distinguish between catalog updates made by the user and those made by your own api?
How do you distinguish between when the user changes an image caption versus an image file?
Currently with the catalog.version.updated event there isn’t a way to tell where the updates are being made. We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team.
