How to Reduce Your SP-API Call Volume 🚀 📉

[MeenaAmz]

This guide provides a strategic approach to reducing Amazon Selling Partner API (SP-API) call volume through three key strategies: error rate reduction, event-driven architecture, and batch/bulk operations. By analyzing API usage, implementing targeted optimization techniques, and combining notifications with strategic data retrieval, developers can efficiently manage API interactions and prepare for upcoming API usage fee structures.

Authored by: Meena P, Solutions Architect, Selling Partner Developer Services

How to Reduce Your SP-API Call Volume 🚀 📉

When integrating with the Selling Partner API, building an efficient and well-architected integration is crucial. With the upcoming monthly API usage fee (see SP-API Fee announcement), optimizing API call patterns has become more important than ever. In Part 1 of our series "SP-API Integration Best Practices", we will explore effective ways to optimize your GET API traffic while maintaining your application's functionality.

📊 Step 1: Analyze Current Usage

Start by reviewing your API consumption in Solution Provider Portal:

• Open Solution Provider Portal and navigate to API Usage dashboard. (Not sure how to do this, refer to API Usage Metrics in Solution Provider Portal)
• Filter data by:
  • App
  • Time periods (Month to Date, Last 7 days, Last month, etc.)
• Focus on 🔵 blue operations (metered GET API usage)

Metered calls are GET API requests that are tracked and counted for billing purposes. Learn which API requests are excluded from billing

Key Metrics to Review

• Total call volume
• 200 (Successful calls)
• Errored calls (400, 403, 404, 429)

Tip

For comprehensive optimization guidance, check out:

• Optimize Calls to the Selling Partner API
• How to create a well architected SP-API application

⚡ Step 2: Choose Your Optimization Strategy

Strategy 1: Reduce Error Rates 🛠️

Focus on understanding and reducing errors by endpoint. The first step in reducing error rates is understanding what the errors mean and then implementing appropriate handling strategies.

HTTP Status Code	Causes
400	Bad Request - Malformed request syntax or invalid parameters
403	Forbidden - Insufficient permissions or access related
404	Not Found - Missing or Premature Resource Access
429	Not Found - Rate Limiting Exceeded

Our recommendation: Start with the top operations that have high call volume and elevated error rates. Insights gained from these improvements will accelerate resolution of similar issues across other endpoints.
For more detailed guidance on how to handle errors, check out:

• Getting Started with SP-API Error Handling
• Mastering SP-API 4xx Error Handling
• Optimize Rate Limits for Application Workloads
• Understand Usage Plans and Rate Limits

429 Specific Strategies ⚙️

• Understand and monitor usage plans across all APIs within your application's ecosystem. Make sure to adhere to rate limits and leverage SP-API prebuilt SDKs with a built-in rate limiter.
• Distribute API requests uniformly to prevent traffic spikes and concentrated call bursts.
• Implement retry and back-off mechanisms using exponential backoff and Jitter
• Implement throttling controls and effective caching mechanisms to minimize unnecessary requests.

Tip

• Implement comprehensive error monitoring and real-time alerting systems to swiftly identify issues and streamline debugging processes.
• Deploy a pre-flight validation mechanism within your CI/CD pipeline to intercept and block malformed requests before SP-API interaction.
• When encountering 400, 403, or 404 errors, address the underlying issue by correcting the payload before attempting subsequent retries.
• Integrate an automated token expiration checker that proactively refreshes LWA access tokens prior to initiating SP-API calls.

Strategy 2: Implement Event-Driven Architecture 🔄

Instead of constantly polling for information, implement an event-driven architecture where your application receives updates directly from Amazon when specific events occur. SP-API offers diverse notification types that you can leverage to reduce your call volume. For example:

• Use REPORT_PROCESSING_FINISHED notification instead of polling getReport API for report status
• Subscribe to ORDER_CHANGE notification to track important status changes to orders instead of polling orders API
• Leverage PRICING_HEALTH notification to know whenever a seller offer is ineligible to be the featured offer

Refer to Notification Type Values for a comprehensive list of SP-API notifications by use case.

For more guidance on implementing and using notifications, see:

• Mastering Amazon SP-API Notifications: Complete Implementation Guide
• How to create notifications for reports
• How to Setup SP-API Notifications using Amazon EventBridge

Tip

• Combine notifications with targeted GET operations to optimize call volume
• Implement data handling mechanisms to effectively process and manage notification streams.
• Design scalable architecture that intelligently ingests high-volume notifications while consuming only essential data.

Strategy 3: Use Batch\Bulk Operations 📚

Batch Operations 📦

Instead of making several individual GET requests, consolidate your API read calls. SP-API supports batching for the following use cases:

Catalog Operations:

• searchCatalogItems - Search for a list of Amazon catalog items
• searchListingsItems - Search for selling partner listings items

Pricing Operations:

• getCompetitiveSummary - Get featured buying options
• getFeaturedOfferExpectedPriceBatch - Get the computed listing price at or below which a seller can expect to become the featured offer (before applicable promotions)
• getItemOffersBatch - Returns the lowest priced offers for a batch of items based on Amazon Standard Identification Number (ASIN)
• getListingOffersBatch - Returns the lowest priced offers for a batch of listings by Stock Keeping Unit (SKU)

Fee Operations:

• getMyFeesEstimates - Returns the estimated fees for a list of products

Bulk Downloads 📥

If you are using individual GET requests to download large datasets, consider switching to bulk mechanisms:

• Reports API - SP-API offers extensive reporting capabilities for various business use cases, including inventory monitoring, order fulfillment tracking, tax information retrieval, returns and seller performance tracking, and Fulfillment by Amazon (FBA). For available report types by use cases, refer to Report Type Values.
• Data Kiosk - Provides dynamic reporting capabilities where you can request and receive exactly what you need. It currently supports sales and traffic, SKU economics and vendor analytics datasets. Check Data Kiosk Schema Explorer for available datasets

Tip

• Optimize bulk data retrieval by implementing precise filtering mechanisms, ensuring streamlined post-processing and efficient subsequent API calls.
• Customize data collection strategies per seller, accounting for their unique marketplace participation, program enrollment, and specific business requirements.
• Design intelligent data retrieval systems that align with data availability patterns rather than continuously polling. Schedule reports when possible.
• Execute historical data backfills strategically through incremental retrieval, focusing on essential data points to minimize system load.
• Maximize efficiency by leveraging batch operations at their full capacity (max batch size)

🎯 Step 3: Combine Strategies for Maximum Impact

In most cases, implementing one strategy might not be enough. Consider combining multiple approaches like Notifications, Batch, Reports and API to effectively reduce call volume. See below for some implementation examples:

• Price Adjustment Automation Workflows Guide - Optimize competitive pricing through notification-driven updates, minimizing API calls. Monitor PRICING_HEALTH notifications for featured offer disqualification events and utilize ANY_OFFER_CHANGED notification for immediate price update reactions. Enable dynamic pricing strategies based on market changes.
• Building Listings Management Workflows Guide - Enhance listing operations by combining notifications with strategic API usage. Monitor LISTINGS_ITEM_STATUS_CHANGE and LISTINGS_ITEM_ISSUES_CHANGE notifications to track processing status and address listing issues promptly.
• Orders API Best Practices Guide - Implement hybrid order management systems that maximize order visibility while optimizing API consumption. Use order reports for bulk processing, leverage orders API for real-time orders, and implement ORDER_CHANGE notifications for immediate status updates.

Other Best Practices

• Eliminate redundant data fetching by designing systems that retrieve information only when necessary
• Implement strategic caching with metadata for frequently accessed, stable data points
• Develop interconnected systems that efficiently share entity level information to prevent duplicate API calls across processes

Use case specific Best Practices

• Listings
• Orders
• Pricing
• Order and Inventory Management
• MFN

✅ Your Optimization Checklist

Before you start:

• Review current API usage patterns
• Identify high-volume operations
• Review and handle high error rates
• Configure notifications where applicable
• Select appropriate batch operations
• Plan bulk download implementation
• Test in staging environment

Important

These are strategies based on general best practices. Always conduct your own evaluation before implementation to ensure they align with your business needs.

⏭️ Next Steps

• Start with analyzing your current API usage
• Pick the most impactful strategy for your use case
• Implement and monitor improvements
• Iterate based on results

🚨 Looking to tackle Errors first, review Part 2 - Getting Started with SP-API Error Handling

Let us know what do you think!

Having trouble implementing these optimizations? Drop your questions below! Share your success stories too - we'd love to hear how you optimized your API calls.👇 React or reply down below to share your feedback. Happy optimization!

• ❤️ Like what you see?

• 👍 Excited to try it out?

• 🎉 Want to see more of this?

Keywords: #amazon-sp-api #error-handling #exception-handling #logging #monitoring #alerting #automation #fees #optimization #event-driven #batch #bulk #well-architected

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.

[ezfrag2021]

I am successfully pulling data using all the different types of API queries but I am struggling a lot with 429 throttling. I have implemented a system whereby I increment the pause on each subsequent 429 but after three successive 429s the system pauses for 10 minutes to allow the token bucket to refill. However I am still hitting regular 429s and each query takes between 5 and 10mins to return data. I am strictly adhering to a rate limit of 65s per query for Data Kiosk.

This seems far too restrictive. Is this really how it is supposed to work? The header value that is supposed to return the correct pause time is empty on a 429 response which is unhelpful. Any suggestions?

[leonardonakagawa]

Hi @ezfrag2021,

Thanks for you question.

The x-amzn-RateLimit-Limit header does not return the remaining rate or pause time. It only returns the rate-limit specified for that operation.

To deal effectively with Data Kiosk APIs we recommended following the Building Data Kiosk workflows guide
which has a diagram leveraging the DATA_KIOSK_QUERY_PROCESSING_FINISHED notification which is sent when a Data Kiosk query finishes processing, so you can avoid keep pooling the getQuery endpoint and go straight to the getDocument one.

Also, we highly recommend you to Implement retry and back-off techniques to o avoid impact on your workloads and increase the reliability of your application.

If the information available in the documentation link provided above does not fully resolve your inquiry, please open a support case with us.

Thanks,
Leonardo Nakagawa
Solutions Architect, Selling Partner API

[ezfrag2021]

Hi Leonardo,
Thanks for your reply.

After a lot of trial and error I concluded that the best method is to create the queue on my side and only submit one query at a time. I wait for the SQS response, download the data and then submit the next query.

I have no idea how to make use of the 15 burst limit for Data Kiosk which should allow for concurrency. Every time I submit a query while one is already being processed by the API I receive a 429 and have to manage resubmission of the failed query on my side. It's easier just to assume there is no concurrency and submit each query consecutively.

Sadly it means that my nightly queries take 6hrs to complete.