Zalando Price Update

The purpose of this page is to describe in detail how to use the Zalando functionality to update Price on the channels

Price needs to be “updated” in two cases

When we are creating a product for the first time and have successfully determined it as created (basically when the PSR has marked a product with Product Status as “Product Created”)
In live trading scenarios when we have an update_price flag on “pending” (Everything else when the product status is already “Product Published”)

API Docs: https://developers.merchants.zalando.com/docs/offers-prices.html

API Call: POST /merchants/{$MERCHANT_ID}/prices

Prices can be sent in batches of up to 1000 products at the same time. We are expecting an immediate response detailing success / warning / error of the requested update. We should create a flag in Account Zalando that will specify if we want Warnings for price updates to be flagged to Zalando for blocks or not (if flagged yes we are to utilise one more filed in the request as per the below mapping. This will tell Zalando to block updates even if the validation returns only warning too) Last but not least - the limit of the calls is the be utilised across all channels with the same Merchant ID in Account Zalando. This way we will be able to update with the fastest possible times without any blockings. To do this we are to track how many products we have sent for the first picked account and utilise the left over limit for the minute on the second account and so on. We have to keep in mind though that we have up to 1 call per second limit with Zalando for the prices as well

Example call:

{
  "product_prices": [
    {
      "ean": "$EAN_1",
      "sales_channel_id": "$SALES_CHANNEL",
      "regular_price": {
        "amount": $AMOUNT,
        "currency": "$CURRENCY_CODE"
      }
    },
    {
      "ean": "$EAN_2",
      "sales_channel_id": "$SALES_CHANNEL",
      "regular_price": {
        "amount": $AMOUNT_1,
        "currency": "$CURRENCY_CODE"
      },
      "promotional_price": {
        "amount": $AMOUNT_2,
        "currency": "$CURRENCY_CODE"
      },
      "scheduled_prices": [
        {
          "regular_price": {
            "amount": $AMOUNT_3,
            "currency": "$CURRENCY_CODE"
          },
          "promotional_price": {
            "amount": $AMOUNT_4,
            "currency": "$CURRENCY_CODE"
          },
          "start_time": "$START_TIME",
          "end_time": "$END_TIME"
        }
      ],
      "ignore_warnings": $BOOLEAN
    }
  ]
}

Mapping:

Zalando Field			WAP Mapping	WAP Notes
`product_prices`			N/A
	`ean`		Item Account > Marketplace EAN

(This is the “flag” I am referring to in the first paragraph of this document) |

Base logic for RRP vs StartPrice promotions: In Hemisphere we have 2 price fields that can be used and sent to the Marketplace - StartPrice & RRP. If both fields are filled in we have to make a decision how to send them to the respective Marketplace 🙂 StartPrice, as a standard rule is our main price. This is the price an end buyer should see and pay for a product. RRP is what in most places we see as “Was price” or “Old price” - but basically the price the manufacturer of the product recommends as base price so any seller from there can sell it for whatever they want (Example: It was 2000 = {RRP}, now come and grab it for only 999 = {StartPrice})

We always MUST have StartPrice. RRP is optional.

Marketplaces very often have 2 fields as well. In this case those are the regular_price and the promotional_price. The marketplaces always MUST have the regular_price (or its equivalent on other MPs) which makes it slightly different how we send info.

The basic RRP vs StartPrice logic states: If we have only StartPrice in Hemi and no RRP then we will send the StartPrice as “regular_price” and that’s it. We don’t have anything to promo against and the MP needs its regular_price to sell the item. If we have both StartPrice and RRP and the RRP is greater than the StartPrice we should send the RRP in “regular_price” and move the StartPrice to “promotional_price” as in this case the end buyer will see and use “promotional_price”

To have RRP means for it to be more than the StartPrice!

Please note I haven’t described the scheduled prices section as this is something we are not doing. In a case of a promotion (as per the abstraction standard definition of promotion) we are to track internally and update at the right time as a preference to sending a beforehand update if this is available on the marketplace. Other than that Scheduled Prices follow the same logic and structure as the standard price fields just have a specifically set time associated with them

If the call was successful we will receive in response a 207 status code and a feed back for all requested price updates. A response of 207 is not an indication all was accepted successfully as it validates through the file as a schema and value issue validations are returned in the response body

Example response:

{
  "results": [
    {
      "product_price": {
        "ean": "5901234123457",
        "sales_channel_id": "01924c48-49bb-40c2-9c32-ab582e6db6f4",
        "regular_price": {
          "amount": 89.95,
          "currency": "EUR"
        },
      "scheduled_prices": [
        {
          "regular_price": {
            "amount": 89.95,
            "currency": "EUR"
          },
          "promotional_price": {
            "amount": 50,
            "currency": "EUR"
          },
          "start_time": "2020-05-01T14:00:00Z",
          "end_time": "2020-05-05T22:00:00Z",
          "status": "ACCEPTED",
          "code": 0,
          "description": null
        }
      ],
      "ignore_warnings": true
      },
      "status": "ACCEPTED",
      "code": 0,
      "description": null
    },
    {
      "product_price": {
        "ean": "6661234123457",
        "sales_channel_id": "01924c48-49bb-40c2-9c32-ab582e6db6f4",
        "regular_price": {
          "amount": 59.95,
          "currency": "EUR"
        },
        "promotional_price": {
          "amount": 24.95,
          "currency": "EUR"
        },
      "scheduled_prices": [],
      "ignore_warnings": false
      },
      "status": "ACCEPTED",
      "code": 0,
      "description": null
    }
  ]
}

For each product with information we’ve provided we will receive back a status. ACCEPTED indicates that the change has been queued up and will be executed. WARNING indicates that a specific level of the validation has been hit but unless we’ve specifically requested that the change will still take effect. ERROR will block it. the “description” field will provide all needed details. If we’ve selected for Warnings to block price updates we are to treat them as ERRORs and make the necessary updates on the status fields

Besides the standard Update Price management and error handling if this was the first price was sent successfully to Zalando (product was picked from status Product Created) we should properly mark the product with its next status - Product Published. As we should send stock only to published items this will in effect lead to the last step - the stock update that will make the product live and active for selling

Marketplaces / Zalando Direct connection / Zalando Price Update

Zalando Price Update