Advanced Topics

Extra headers

All HTTP requests sent by Shop Update include the following headers

Header name

Value type

Definition

X-SC-Flow

string

‘synchronous’ or ‘asynchronous’, depending on Seller Center's configuration - refer to Introduction and the Guide

X-SC-Topic

string

name of the event in Seller Center that triggered the Shop Update request

X-SC-Requeue-Count

number

number of times the request was requeued - refer to Requeue Behaviour

X-SC-Enqueued-At

number

the time the request entered, or re-entered, Shop Update’s queue, as a timestamp in nanoseconds - refer to Requeue Behaviour

About requests order

When a Product is created or modified in Seller Center, Shop Update adds requests to a queue which is processed in FIFO order, with some exceptions due to dependencies on data provided by the Shop (Source IDs and Shop SKU).

For example, if a seller creates one Product Set with one Product and changes its price and stock, the following items will be in Shop Update’s queue after the Product Set is approved in QC:

  1. Stock Change
  2. Price Change
  3. New Product Set

Even though Stock Change and Price Change were added to the queue earlier, New Product Set is sent first in order to retrieve source IDs and Shop SKUs.

When Shop Update has received the (synchronous or asynchronous) response for New Product Set, the request for the oldest item in the queue - Stock Change - is sent. Once this request has successfully reached the Shop, the Price Change request is sent, too.

As Shop Update’s responsibility is to notify the Shop of a Product change as soon as possible after it The exact moment when the next request is sent depend on the “flow” configured in Seller Center:

  • in the synchronous flow, a request is sent only after Shop Update has received a successful response for the previous request from the Shop
  • in the asynchronous flow, a request is sent only after Shop Update has received a successful ACK for the previous request from the Shop

About request IDs and requeue behaviour

Every time Shop Update detects a Product’s change, it will first check if there’s already an item in the queue for the same Product and type of change (or topic). If an existing queue item is found, instead of adding a new item to the queue, it will update the payload and increase a “requeue counter” on the existing one.

This can lead to a corner case where multiple requests with the same request ID reach the Shop, if a product is edited multiple times in the short interval between when Shop Update has initiated a request and when the Shop has returned a response or an ACK.

The Shop can take advantage of the X-SC-Requeue-Count or X-SC-Equeued-At HTTP headers in order to sort and/or disambiguate between requests with the same ID.

  • The X-SC-Enqueued-At header’s value is the time when the queue item for the current request entered, or re-entered, the Shop Update’s queue; requests with the same request ID will have different timestamps
  • The X-SC-Requeue-Count header’s value is the numer of times the item for the current request was requeued; requests with the same request ID will have different values for the counter

Understanding Product’s approval status

When the Shop receives a requests:

  • If the request payload includes an approval_status field, the field’s value (0: pending, 1: approved, 2: rejected) applies to all fields in the payload

  • For Product.updatePrices and Product.updateStock: if the request payload does not include an approval_status field, then all price changes or the stock changes in the request are to be considered approved