When an endpoint is called that requires an insert or update operation into the underlying database, this request is queued to be executed asynchronously. The resulting batch job is called Feed in the context of Seller Center.
Such a feed is assigned identified by a UUID, which is a computed identifier that is assumed to be unique. This identifier is returned upon successful submission of the original request.
For example, if we post this request...
<?xml version="1.0" encoding="UTF-8" ?> <Request> <Product> <SellerSku>4105382173aaee4</SellerSku> <ParentSku></ParentSku> <Status>active</Status> <Name>Dried Water</Name> <Variation>Family Pack</Variation> <PrimaryCategory>4</PrimaryCategory> <Categories>2,3,5</Categories> <Description>You need this!</Description> <Brand>Snake Oil</Brand> <Price>1.00</Price> <SalePrice>0.9</SalePrice> <TaxClass>default</TaxClass> <ShipmentType>dropshipping</ShipmentType> <ProductId>xyzabc</ProductId> <Condition>new</Condition> <ProductData/> <Quantity>1000000</Quantity> </Product> </Request>
...to this URL...
...the API returns this result:
<?xml version="1.0" encoding="UTF-8"?> <SuccessResponse> <Head> <RequestId>6a521aff-e74b-4fb6-b40f-d46b42f91652</RequestId> <RequestAction>ProductCreate</RequestAction> <ResponseType/> <Timestamp>2015-07-01T11:11:11+0000</Timestamp> </Head> <Body/> </SuccessResponse>
The feed identifier is the UUID that is returned inside the RequestId tag, so in this example 6a521aff-e74b-4fb6-b40f-d46b42f91652.
Sellers can ask for a list of feeds and errors from the Feed endpoints. Feeds can have one of several statuses:
The feed was successfully added to the queue and is awaiting processing.
The feed is currently being processed by the server.
The feed was canceled by the seller.
The feed has finished processing
The feed has finished with error(s)
For instance, we can use FeedStatus to inquire on the status of our operation, like so...
...and would find out that the operation failed and why it had failed:
<?xml version="1.0" encoding="UTF-8"?> <SuccessResponse> <Head> <RequestId/> <RequestAction>FeedStatus</RequestAction> <ResponseType>FeedDetail</ResponseType> <Timestamp>2015-07-01T11:11:11+0000</Timestamp> <RequestParameters> <FeedID>6a521aff-e74b-4fb6-b40f-d46b42f91652</FeedID> </RequestParameters> </Head> <Body> <FeedDetail> <Feed>6a521aff-e74b-4fb6-b40f-d46b42f91652</Feed> <Status>Finished</Status> <Action>ProductCreate</Action> <CreationDate>2015-07-01 11:11:11</CreationDate> <UpdatedDate>2015-07-01 11:11:11</UpdatedDate> <Source>api</Source> <TotalRecords>1</TotalRecords> <ProcessedRecords>1</ProcessedRecords> <FailedRecords>1</FailedRecords> <FeedErrors> <Error> <Code>0</Code> <Message>Field PrimaryCategory with value '4' has a problem: Primary category Id is invalid</Message> </Error> <Error> <Code>1</Code> <Message>Field Brand with value 'ASM' has a problem: This brand does not exist in our database. Please contact our support.</Message> </Error> <Error> <Code>2</Code> <Message>Field TaxClass with value 'default' has a problem: 'default' is an invalid Tax Class</Message> </Error> </FeedErrors> </FeedDetail> </Body> </SuccessResponse>
Two more things are notable in the context of feed status:
- Feeds with any status other than 'Queued' will be automatically removed from the system 30 days after their creation.
- Only Queued feeds can be canceled.
Each feed which is created may contain one or more products.
It is more efficient to use one feed containing many product creations / updates, rather than one feed creation per product creation / update.
Seller Center limits the number of feeds that can be created in a certain time-frame. At any day 50 feeds can be created. After the daily limit is reached, you are allowed to create one more feed every two minutes. Eventually when using the full limit 770 feeds per day can be created.
Feed Limitations are per Seller
This limitation is applied for each seller separately.
To visualize this behavior, consider the Leaky Bucket metaphor. There is a bucket with a hole in the bottom, which leaks in a given rhythm. Once the bucket is filled, it's impossible to add more requests to it, and we have to wait for some of them to leak.
In conclusion, the normal processing (or leaking) rate is 30/hour, but the container can hold more requests, so long as there are no more than 50 of them at a time in the system.
Additionally each seller is just allowed to update their inventory 5x per day. So when you have 100.000 products, you can just update 500.000 products per day. Any seller- independent of the product count - is always allowed to do 50.000 updates per day.