Skip to content

Best Practices

Store Process

You can use the OEA notifications to improve your store process. Detailed examples below:

  • Reservation

A reservation identifies certain stock in your store that is reserved for a particular sales channel in your IT system. We recommend you use the "assigned" event to reserve the items for incoming Zalando orders to avoid double selling and cancellations to customers. You can also find out if the item is out of stock or inventory inaccuracy on your store at this step depending on your IT system/POS capability.

  • Automated “book out” from POS

An ideal store process is that you book out the article as soon as it is marked as complete in the Connected Retail Tool. This allows us to receive the most updated stock inventory from your IT systems which will improve stock accuracy. With high stock accuracy you can offer the best customer experience with no cancellations. We recommend you use the “fulfilled” event to automatically book out articles from your IT systems/POS.

  • Build your own BI Reports

You can build your own Business Intelligence reports with the order states triggered by OEA. Each event has a structure which includes item level information which will help you analyse data in depth.

  • Reconciliation

In accounting, reconciliation is the process of ensuring that two sets of records are in agreement. You can use the notification structure/payload provided by OEA events to reconcile your records at the end of the day.

  • Automated “book in” to IT System/POS

OEA triggers a “returned” event which is triggered when a return is confirmed in the Connected Retail Tool. You can use this event to book in the items to your IT system/POS when a customer sends a return to your store.

Security

We highly recommend setting up an API Key when setting up the endpoint. This provides basic authentication that the events are triggered by Connected Retail service and not anyone else.

Queued Notifications

To ensure that notifications are properly delivered, your server should acknowledge them with an appropriate response message

If we don't receive the response message within 10 seconds, we'll retry sending the notification for a limited period of time.

Each consecutive failed attempt increases the time until the next attempt is made. For example, the first retry attempt is ~10 minutes after initial failure, then the second attempt is ~20 minutes after the previous failed attempt, then 40 minutes, etc. We will increase the retry interval for up to 12 hours. After approximately 3,5 days the notification will no longer be retried, and it will not be received through a webhook after that.

The notification queues are maintained separately for each endpoint. If you have multiple endpoints for receiving notifications and we have queued notifications for one of them, this won't affect the remaining endpoints.