With the introduction of Akeneo 5.0 came the new Akeneo Events API aka “Webhooks” from Akeneo. After spending some time playing with the feature I’d like to take you on a deep dive into the pros and cons of using webhooks.
The Akeneo Events API Brings Powerful New Capabilities
Let’s start with the good news. Every data team’s dream is to make an update to their product data and have that data instantly and automatically flow downstream. Webhooks is an answer to that dream. Akeneo will send messages for 6 different events: product creation, product updates, product deletes, product model creation, product model updates, and product model deletes. Each of these events can be linked to different processes. For example, you could set up your workflow to have your team create products only with a sku. Then you could create a script to pull that product’s data from your ERP via the API in real time. See Sitation’s demo of doing this with ElasticSearch – our entry that won Akeneo’s 2021 Hackathon!
Another massive advantage of using webhooks is the ability to track product and product model deletes. Before the introduction of events, when a product or product model was deleted from Akeneo there would be no record of it anywhere. With webhooks you can now accurately track which of your products and product models are deleted by using the product delete and product model delete events.
Now for the bad news. First of all, there are currently only the 6 events listed above in the Akeneo Events API. This limits the real time processing that you can set up with your webhooks. Products and product models are probably the most important components of Akeneo, so it makes sense that they would be the initial events created. The major drawback is that other Akeneo objects, such as attributes or categories, that need to flow downstream still need to be sent with a non-webhook process. Additionally, all product updates will trigger the same event. If you’re only interested in specific product data updates you will have to filter those out later in the process. Sending those extra messages could clog up your message queue.
Some Items to Look Out For
Speaking of the message queue, another limitation of webhooks is the volume of messages it can handle. The webhooks can handle 4000 messages per hour across all urls. Each of these messages can contain up to 10 events. After reaching this limit all messages will be queued for up to 2 hours. If those 2 hours pass and the message hasn’t been consumed it will expire and not be processed. While 40,000 product creations or updates per hour may be sufficient for some implementations, if you have millions of products in Akeneo it is possible to exceed the message limit in the Akeneo Events API .
Lastly, there is a 500ms timeout when waiting for a webhook response. If the webhook server doesn’t receive the message within 500ms it will silently fail. Currently there are no re-send mechanisms for these messages. This means that it is likely that if you rely solely on the Akeneo Events API your events will miss at some point and you will not be alerted when they miss. For this reason you can’t commit any critical business functionality to the Events API without also building your own process for tracking progress. For example, if you’re using the Events API to push updated products downstream you would need to set up a nightly check to compare the SKUs updated in Akeneo vs. the SKUs updated in your destination system. This extra step will ensure that products don’t slip through the cracks, but it does come at the cost of extra effort.
Wrapping Up
In conclusion, the Akeneo Events API is an extremely powerful tool that has the potential to dramatically improve your product data management by allowing real time automation of the product data management process. Webhooks are also uniquely able to track product deletes. However, in their current state, webhooks are most suitable for small, incremental product changes rather than massive updates to hundreds of thousands of products. Additionally, if you want to guarantee that every message gets consumed, you’ll need to build additional processes to check for missed SKUs. Overall, I’m extremely excited about the potential of the Akeneo Events API. It’s important to remember that the Events API feature has just been introduced with the 5.0 version of Akeneo. Sure there are some limitations, but with proper planning they can be worked around. I’m extremely excited to see what improvements will be made to the Events APi in the future. I fully expect that webhooks will be the future of Akeneo data management.
