Amazon productType is sticky. PATCH doesn't change it

Once a listing is created with a given productType classification on Amazon, you cannot change it via SP-API. PATCH with a different productType returns success but the field doesn't update. Only DELETE+CREATE or a Seller Central reclassification request actually changes the underlying category. If your catalog ended up in AUTO_PART because of a sloppy initial upload, your rejection rates and Buy Box performance are quietly worse than reality suggests.

$The behavior the documentation doesn't make obvious

Amazon's SP-API uses productType as the top-level taxonomy for what a listing is. SHOES, LAPTOP, FOOD_DROPPER, AUTO_PART, etc. The full taxonomy has thousands of leaf types, each with a different attribute schema and rejection-rule set.

When you submit a listing via PUT /listings/2021-08-01/items/{seller}/{sku}, the request body specifies the productType. Amazon validates the rest of the payload against that productType's schema. If you got the productType wrong on initial submission, every subsequent change you make has to conform to the wrong schema, and you can't fix the productType field by PATCHing it.

Specifically: if you send a PATCH with a new productType value, the API returns 200 OK and a successful processing report. The processing report does not indicate the productType change was rejected. The listing's productType remains unchanged. You can verify this by GETting the listing afterward; the productType field reflects the original value, not your PATCH.

$How catalogs end up wrong

Three common paths to a wrong productType:

Sloppy initial upload. The catalog was loaded once via a connector or a flat-file template that picked a productType heuristically, usually because the operator wasn't sure which leaf type applied and the connector defaulted to a generic option.
Marketplace migration. The catalog was originally on a different productType taxonomy (legacy BrowseNodeIds, or pre-SP-API MWS classifications) and the migration mapped everything to a single fallback type to avoid manual classification.
AUTO_PART as fallback. This one is specific and worth flagging: AUTO_PART is Amazon's most permissive productType. Many connectors default to it when their classification heuristic is uncertain because it accepts the broadest range of attribute payloads without rejection. Listings in AUTO_PART often submit successfully, but they're miscategorized, so Amazon's search and Buy Box logic treats them as worse-quality than their actual category would.

On the prior engagement, the AUTO_PART fallback was the single largest "silent revenue leak" category in the catalog. Most of the products were not automotive parts. They were correctly-described in title and bullets, but Amazon's recommendation engine had them ranked against actual auto parts.

$Diagnostic. Find your productType distribution

Before fixing anything, find out what your catalog looks like. The Amazon Catalog API lets you GET item details including productType:

# For each active SKU, pull catalog details and group by productType.
def categorize_catalog(seller_id, marketplace_id, sp_client):
    counter = Counter()
    for sku in get_active_skus(seller_id):
        r = sp_client.get(
            f"/catalog/2022-04-01/items",
            params={
                "identifiers": sku,
                "identifiersType": "SKU",
                "marketplaceIds": marketplace_id,
                "includedData": "productTypes",
            },
        )
        items = r.json().get("items", [])
        for item in items:
            for pt_entry in item.get("productTypes", []):
                counter[pt_entry["productType"]] += 1
    return counter

dist = categorize_catalog(seller_id, marketplace_id, sp_client)
for pt, n in dist.most_common():
    print(f"{pt:<40} {n}")

What you want to see: distribution roughly matching the categories your products actually belong to. Apparel sellers should have a long tail of SHIRT / PANTS / DRESS / etc. Auto parts sellers should have a long tail of AUTO_PART / VEHICLE_FLUID / TIRE. Food sellers should have a long tail of food types.

What raises a flag: a giant cluster in AUTO_PART if you're not selling auto parts. A giant cluster in SPORTING_GOODS if you're not selling sporting goods. Anywhere the fallback type dominates your distribution disproportionately to your actual catalog composition.

$Why `PATCH` doesn't fix it

You'd think, having identified the misclassified listings, you'd just PATCH them with the correct productType. That's what doesn't work. The SP-API does not allow productType to be updated on an existing listing.

The reason is structural: productType determines the attribute schema. Changing it would mean revalidating every attribute on the listing against a new schema. Amazon doesn't support that flow via API. They want you to delete the listing and re-create it with the correct productType from scratch.

$The fix (and why it's expensive)

Three options, in order of cost and reversibility:

Option 1. Seller Central reclassification request

For high-value listings (high sales volume, established reviews, established ranking), open a Seller Central case requesting reclassification. Amazon's support team can change the productType on the backend without deleting the listing, preserving the ASIN, reviews, and ranking history. Slow (3-7 business days per case) and not reliably granted for low-volume listings.

Option 2. DELETE + CREATE via SP-API

For mid-volume listings, the SP-API path is: DELETE the existing listing, wait for confirmation (the listing goes from BUYABLE to SUPPRESSED to fully removed over ~24-48 hours), then CREATE a new listing with the correct productType. The new listing gets a new ASIN unless you can map it to an existing parent ASIN.

This loses reviews and ranking. If the listing has accumulated material reviews, do Option 1 first.

Option 3. Accept and move on

For low-volume listings where reviews and ranking are minimal, accept the misclassification and move on. The cost-benefit doesn't justify the work. Document the decision so you don't re-investigate later.

Most operators end up with a mix: Option 1 for the top 10-50 listings by volume, Option 2 for the next 100-500, Option 3 for the long tail. The classification work is the bottleneck. Figuring out the correct productType for each listing requires manual category browsing or a paid classifier.

$The structural prevention

The actual fix isn't catalog cleanup. It's making sure new listings get the right productType on initial submission. Two ways to do that:

Pre-validate every new listing against productType-specific schema. Before submitting, run the payload through the productType's attribute schema (available via SP-API /definitions/2020-09-01/productTypes/{productType}). If validation fails on required attributes, the productType is wrong; pick a better one before submitting.
Use Amazon's classification API. The Catalog API has a searchClassifications endpoint that takes a title and returns suggested productTypes ranked by confidence. Building this into your listing-creation flow eliminates the heuristic-fallback path.

If your Odoo connector doesn't do either, it's quietly setting you up for future cleanup work. Worth fixing in the connector layer once, not patching catalog-by-catalog forever.