Create listing - Product type - required attributes

[upsitesolutionsnl]

When I'm trying to create a new listing, i'm faced with inconsistencies between the required fields and what the actual JSON LISTING FEED gives back as what should havve been required fields.

To start this process I'm using the SP API to get the product type definition for indentifier HEADPHONE_EARPAD.

This gives back the following required_fields:

[0 : "brand"]
[1 : "bullet_point"]
[2 : "country_of_origin"]
[3 : "item_name"]
[4 : "product_description"]
[5 : "recommended_browse_nodes"]
[6 : "supplier_declared_dg_hz_regulation"]

Even when I go down to the base node CONSUMER_ELECTRONICS I'm getting the same default list of required fields.

When I submit my feed based on these required fields im getting many required fields errors that are not related this list of required fields

90220 | ERROR | item_package_weight is required but not supplied.
90220 | ERROR | warranty_description is required but not supplied.
90220 | ERROR | item_package_dimensions is required but not supplied.
90220 | ERROR | number_of_items is required but not supplied.
90220 | ERROR | list_price is required but not supplied.
90220 | ERROR | batteries_required is required but not supplied.
90220 | ERROR | manufacturer is required but not supplied.

I'm really wondering how I'm going to do this. The Amazon documentation for this 90220 error explains "To avoid this, use the Product Type Definitions API to identify required attributes and add to validation checks."

But that really does not solve this issue at all. I'm using the same MarketplaceID consistenly throughout these calls.

Thanks in advance for your help!

[weilinggu]

Hi @upsitesolutionsnl The required attributes are dynamic. As you fill out different attributes, the required attributes might change. So typically you will get more required attributes than the 6 attributes you saw. You can find allOf in product type JSON schema returned, which contains the conditional requirements.

• Here is a deep dive video on product type JSON schema that explains how the product type JSON schema works with a demo submission in part II
• Here is a Listings sample application that implemented a dynamic UI based on product type JSON schema.

json-schema.org has tools you can use to render the product type JSON schema and validate your product payload. We recommend you validate your product payload using these tools first before submitting the product payload. You can also consider using VALIDATION PREVIEW with putListingsItem to test a few product payloads before submission.

Hope this helps! Let me know if you have any questions about the information above.

Weiling
Selling Partner Developer Services

[karanrana-artoon]

Hi @weilinggu
Do you have any reference links, like how to manage thousands lines of allOf conditional requirements and complex logic.
I go through Amazon SP-API Developer University youTube videos but didn't get much idea how to handel this.
It will be really helpful, if you share some great resource. Thanks.

[weilinggu]

Hi @karanrana-artoon

I recommend taking a look at the Listings Sample Solution. The solution uses an open source library to parse the JSON schema and validate the listing payload.

You can also check the json-schema.org to find an open source library that works with your application's stack.

Thanks
Weiling
Amazon Selling Partner Services

[elburro1887]

Why does VALIDATION_PREVIEW return different errors than when using the actual putListingsItem call?

[weilinggu]

Hi @elburro1887

We have recently released changes to improve the validation accuracy. See annoucement.
Are you still seeing discrepancy now? Can you share the error difference?

Thanks
Weiling
Amazon Selling Partner Services

[elburro1887]

To be clearer:

I had an issue yesterday where I uploaded a product via putListingsItem and it was ACCEPTED, but never showed up in the product list in Seller Central. I had no idea why, even after multiple tries.

Then I uploaded this data with VALIDATION_PREVIEW enabled, and I received an error message, which allowed me to pinpoint and fix the issue, the product then appeared.

So my questions are, rephrased:

• Why does VALIDATION_PREVIEW return error messages than are not returned when using the actual putListingsItem call?
• Why do we even need VALIDATION_PREVIEW, shouldn't the normal putListingsItem call return any and all errors, instead of returning ACCEPTED, even though there was clearly an error?

[jawheral]

Hi @elburro1887,

With the VALIDATION_PREVIEW mode, you get issues synchronously so issues are returned immediately with the http response. This mode is used for validation before actual submissions, to detect issues early and address them.
With the regular submission mode, submissions are checked asynchronously: your data is ACCEPTED then issues are added later on. That's why you have the LISTINGS_ITEM_ISSUES_CHANGE notification to notify you when issues are added. You can also call getListingsItem with issues part of the includedData to poll for new issues and check your listing status after submission, for instance to diagnose why it was not added to your catalog.

Note: Please keep in mind that VALIDATION_PREVIEW does not support all issue types that could possibly occur. The annoucement recently shared shows further support of issue types to this mode.

I hope this helps.

Best,
Jawher
Selling Partner Developer Services