Navigating Listings API Rate Limits: 3 Optimization Strategies for Speedy Listings Management 🚀📊🔍

[weilinggu]

Navigating Amazon Selling Partner API (SP-API) Listings API requires strategic planning and technical expertise. This comprehensive guide provides three critical optimization strategies to help solution providers and seller partners to accelerate listings processing while working within rate limit constraints.

This guide breaks down three proven strategies to optimize processing speed, minimize rate limit bottlenecks, and maintain seamless listings management. Before diving into the strategies, let’s dissect the system mechanics governing API submissions—because optimizing workflows starts with understanding how your feeds are processed, not just how many you can submit.

Authored by: Weiling Gu, Solutions Architect, Selling Partner Developer Services

Key Mechanisms

1. 📊 Rate Limits

It is crucial to understand Listings API and JSON_LISTINGS_FEED usage plan. Here is a list of resources available:

• Usage plans and rate limits
• Listings Items API rate limits
• Listings Restrictions API rate limits
• Product Type Definitions API rate limits
• JSON_LISTINGS_FEED rate limits

There are four rate limit levels (Reference the documentation above to understand the rate limits for each operation):

• Application-Level Rate Limit 🖥️: Applies to the application calling the SP-API.
• Selling Partner-Level Rate Limit 📈: Applies to the selling partner account calling the application.
• Operation-Level Rate Limit: Applies to individual operations, such as PUT, PATCH.
• Data Type-Level Rate Limit: Applied based on the data type submitted such as product data, variation relationship, price/inventory.

Important

Including relationship attributes such as child_parent_sku_relationship to the submission will result it being subject to rate limit of 5TPS100TPS per application(for patchListingsItem operation).
Including product data attributes such as merchant_shipping_group to the submission will result it being subject to rate limit of 100TPS per application(for patchListingsItem operation).

2. 🚦 Listings Submission Processing Pipeline

This graph is based on a single merchant’s listing submissions

Important

Feeds with higher throughput (such as XML feeds) DO NOT indicate faster processing time.
Submitting more feeds simply adds them to a feed queue, where they are handled sequentially. While high-throughput feeds allow more submissions, the system’s rate limits and first-in-first-out (FIFO) queue structure mean that increasing your submission rate won’t accelerate how quickly individual feeds are processed. Prioritize optimizing feed quality and avoiding retries to reduce bottlenecks, not just maximizing submission volume.

Tip

Amazon's catalog write mechanism has per-SKU update rate limits. Submitting large amounts of updates for the same SKU will result in processing delays.

STRATEGY 1: Avoid Unnecessary API Calls

1.1 🔍 Payload Validation Before Submission

The Selling Partner API for Product Type Definitions provides programmatic access to attribute and data requirements for product types in the Amazon catalog. Solution providers can validate the product payload using the Product Type JSON Schema via self-built or publicly available tools, reducing errors that would trigger re-submissions.

Tip

Visit json-schema.org for a list of publicly available tools to use.

Tip

New to the Product Type Definitions API? Watch the following video series:
▶️ How to Use Product Type Definitions API to Create Product JSON Payload - Part I
▶️ How to Use Product Type Definitions API to Create Product JSON Payload - Part II

Tip

Check out Listings Sample Solution for example implementation:
Sample solution ->

1.2 🔔 Event-Driven Architecture

Monitor notifications and perform actions based on specific conditions (such as low stock, featured offer disqualification) can help reduce the amount of submissions, save bandwidth and improve processing speed.

Listings Management Relevant Notifications to Consider:

Category	Notifications	Use case
Issues	LISTINGS_ITEM_ISSUES_CHANGE	Check severity and EnforcementActions. For example, if issue has LISTING_SUPPRESSED enforcement, take immediate action
Pricing	PRICING_HEALTH, ANY_OFFER_CHANGED	Featured Offer eligibility changes
Inventory	LISTINGS_ITEM_MFN_QUANTITY_CHANGE, FBA_INVENTORY_AVAILABILITY_CHANGES	Update inventory when stock is low

Full list of notifications →

1.3 🔄 De-Duplication Mechanisms

Important

Submit only material changes to Amazon.
Submitting the same data over and over again simply creates delays as Amazon system has to reprocess every update provided in the order it was received.

Repeatedly inserting the same content could take up bandwidth, increase the queue size and impacting the important updates that need to go through. Implementing a de-duplication mechanism can help improve throughput and provide a better selling partner experience:

• Implement hashing algorithm: Uses hashing algorithms like SHA-1 or MD5 to generate unique identifiers for data chunks and avoid repeat submissions.
• Integrate exactly-once processing services: Use services such as Amazon SQS - FIFO queues which has exactly-once processing feature to avoid sending duplicates to a queue.

Tip

Only include attributes that have changed
Avoid including variation attributes or product data attributes such as child_parent_sku_relationship or item_name to your submission unless they have changed. Adding these attributes could lead to lowering your submission throughput and processing delay.
merchant_shipping_group and condition_type are part of product data attribute group.

1.4 🌐 Cross-Region Attribute Handling

Attributes such as inventory are shared across regions. Check if marketplace_id is required in the JSON Schema’s selectors—if not, update once per region instead of per marketplace.

Example Product Type JSON Schema for fulfillment_availability

"fulfillment_availability": {  
      "title": "Fulfillment Availability",  
      ...  
      "selectors": ["fulfillment_channel_code"],  
      "items": {  
        "required": ["fulfillment_channel_code"],  
        "properties": {  
          ...  
        },  
        ...  
      }  
    }

STRATEGY 2: Spread Traffic Evenly Through-out the Day

Daily Maximum Throughput for Common Use Cases:

Method	Seller-Level Capacity	Application-Level Capacity
PUT	432K/day	8.6M/day
PATCH	432K/day	43.2M/day
JSON_LISTINGS_FEED	36M/day	NA

Seller Partner-level capacity: submission on behalf a single seller a solution provider presents
Application-level capacity: submission across all sellers a solution provider presents

Instead of making listings submissions as soon as changes happen, consider spreading non-urgent updates through-out the day to avoid exceeding the rate limit of the Listings API and JSON_LISTINGS_FEED and utilize the full capability of the API.

🤔 Queue Optimization Considerations

• 🚨 Priority Routing
  • Urgent:
    • Small Volume: Use Listings Items API(e.g. PUT/PATCH) for real-time updates such as critical price/inventory updates. Listings Items API provides a priority processing lane and can bypass congested feed queues.
    • Large Volume: When large amount of urgent, high-priority updates like inventory changes require rapid processing, temporarily pause non-urgent attribute modifications (e.g., product data) and isolate critical updates into dedicated JSON_LISTINGS_FEED submissions.
  • Less urgent: JSON_LISTINGS_FEED. Feeds can experience significant queuing delays during high-volume periods.
  • Need real-time feedback: Listings Items API can provide real-time feedback, suitable for UX based experience where users might be expecting immediate feedback. Validation Preview feature can be used in addition to Listings Items API to get more comprehensive feedback.
• 📦 Maximize JSON_LISTINGS_FEED capacity
  • A single JSON_LISTINGS_FEED can contain up to 25K updates. Consider combining small feeds into larger feeds to maximize the amount of updates that can be made.
  • Combine updates such as images, pricing, inventory, variations for the same SKU in a single feed item message to maximize the content in the feed file.
• 🛡️ Implement rate limiters based on x-amzn-RateLimit-Limit headers
  • Avoid repeatedly hitting 429s.
  • Help manage remaining token balance across different applications of a selling partner.

STRATEGY 3: Adopt New Features

🔍 FEATURE 1: searchListingsItems operation

Solution providers need to retrieve large amounts of Listings data on behalf of their Sellers and Vendors should utilize searchListingsItems. This operation returns information for up to 20 listings items based on filters. With 5 TPS (Transactions Per Second), solution providers can retrieve a maximum of 8.6M products per day.

Use different query parameters to filter and avoid retrieving more than necessary.

Example Use Cases:

• Find all child listings under a parent listing (variationParentSku).

GET <https://sellingpartnerapi-na.amazon.com/listings/2021-08-01/items/AXXXXXXXXXXXX?marketplaceIds=ATVPDKIKX0DER>  
&variationParentSku=EXAMPLE-PARENT-SKU  
&issueLocale=en_US  
&includedData=issues,attributes,summaries  
&pageSize=20

• Identify listings with critical issues (withIssueSeverity).

GET <https://sellingpartnerapi-na.amazon.com/listings/2021-08-01/items/AXXXXXXXXXXXX?marketplaceIds=ATVPDKIKX0DER>  
&withIssueSeverity=ERROR  
&lastUpdatedAfter=2025-02-05T23:45:00.000Z  
&issueLocale=en_US  
&includedData=issues  
&pageSize=20

Note

For full inventory retrieval, Inventory Reports such as GET_MERCHANT_LISTINGS_ALL_DATA are recommended.

🌍 FEATURE 2: Multi-Marketplace Deletes and Purchasable Offer Updates

Take advantage of operations that allow multi-marketplace updates to reduce the amount of overall submissions.

• deleteListingsItem Operation Enhancement:
  • Allow more than one marketplace_id value to be provided.
• UPCOMING patchListingsItem Operation Enhancement:
  • Allow more than one marketplace_id value to be provided only for purchasable_offer attribute updates. If any other attributes are provided (even if alongside purchasable_offer), the limit remains 1.
  • Please monitor SP-API announcement for the release of this feature.

📜 FEATURE 3: Use JSON_LISTINGS_FEED Processing Report to Get Listing Issues

The feed processing report includes any validation feedback from the Listings Items API. If you specify includedData in the feed header, you can retrieve details (for example, processing issues) about the listings items.

Example Feed Header for Retrieving Listings Issues after Processing

"header": {  
    "sellerId": "AXXXXXXXXXXXX",  
    "version": "2.0",  
    "feedId": "1234567890",  
    "report": {  
      "includedData":["summaries", "issues"],  
      "apiVersion" : "2021-08-01"  
    }

Schema ->

Conclusion

Effective SP-API Listings management requires a strategic approach to rate limits, updates, and API feature utilization. By implementing these optimization strategies, solution providers can build scalable, efficient listing management solutions.

Let us know what do you think! 👇 React or reply down below to share your feedback. Happy shopping!

• ❤️ Like what you see?

• 👍 Excited to try it out?

• 🎉 Want to see more of this?

Keywords: #amazon-sp-api #listing #rate-limit #optimization #listing-submissions #throttling #price-update #inventory-update #sync-product

Please note the publication date above. While we strive to keep our content current, the rapid evolution of this topic means some details may have changed since publication. For the most up-to-date information, we encourage readers to follow the announcements in SP-API developer documentation.

[informed-aaron]

How is deduplication handled if a PATCH call is made for a SKU that is already in a JSON feed in the queue? That seems like it could lead to out of order processing.

[weilinggu]

Hi @informed-aaron

Yes the timestamps are tracked per price field of the purchasable_offer attribute. Given that Amazon Catalog already contains the item_price with newer version from the Patch call, the item_price update with older version will be ignored and business price will get updates.

Thanks
Weiling
Amazon Selling Partner Services

[mariusbippig]

Thank you Aaron, for bringing up this interesting topic! I would like to attach another question related to this.

How does the Listings API handle the same case above with partial updates, but mixed with PATCH and PUT calls? As far as the PUT calls should contain the whole data set (because it replaces), all attributes could be treated as changed and would receive a newer timestamp in comparison to a previous PATCH call, which results into the PATCH call being discarded. Is this assumption correct?

[weilinggu]

Hi @mariusbippig

If the PUT call's submission time is more recent than the PATCH call, PUT call content will be processed after PATCH and overwrite the PATCH content. And yes, if you choose to use PUT to update listing, make sure you provide all information needed for the listing.

Thanks
Weiling
Amazon Selling Partner Services

[cmlkx]

PATCH with JSON_LISTINGS_FEED is no where near as fast as the XML based feeds were for simple operations like price changes. This should be looked into and reviewed by a senior level developer.

For price changes (even with de-deduplication and limiting frequency of transmissions) JSON_LISTINGS_FEED submissions pile up for extremely large sellers.

[weilinggu]

Hi @cmlkx

Thanks for the feedback. For the feed submissions that have piled up, can you submit a developer support case and share the case ID here so we can look into the reason behind the slowness?

In your JSON_LISTINGS_FEED submissions, do you submit relationship update data as well? Submitting child_parent_sku_relationship attribute for existing relationships causes delays for the JSON_LISTINGS_FEED processing. See here

Thanks
Weiling