Select only the marketplaces you want to collect data from.
If you want a report for US, CA, MX and BR, in most cases this will increase the number of GET calls. For example, selecting all NA region markets: GET report X for US, GET report X for CA, GET report X for MX, and GET report X for BR. For report X, that will be on average 8-12 GET calls for all 4. If you repeat that process across 50 reports, the counts can add up quickly.
Amazon does provide the ability to request multiple markets in a single request which we support. The report document's contents will contain data for all of the specified marketplaces.
However, per Amazon the ability to combine markets will vary by report type, which means it is not a universal technique. As such, this is a case by case basis. Also, there are long standing documented “bugs” where Amazon may not honor these types of requests. Here is an example of the behavior https://github.com/amzn/selling-partner-api-docs/issues/1404 and https://github.com/amzn/selling-partner-api-docs/issues/2953. This touches on the "Optimizations Limits” section below, where your and our ability to optimize relies on the operation of the SPAPI.
Select only the data you need
Let’s use Amazon inventory as an example. There are 14 data sets (reports).
sp_active_listings
sp_all_listings
sp_inactive_listings
sp_inventory
sp_open_listings
sp_fba_reserved_inventory
sp_fba_stranded_inventory
sp_inventory_ledger_detailed
sp_fba_manage_inventory_health
sp_inventory_ledger_summary
sp_referral_fee
sp_fba_bulk_fix_stranded_inventory
sp_inventory_ledger_summary_by_fc
sp_suppressed_listings
If you decide to select all of them for every market in NA, that is 56 total report variations (4 markets x 14 reports). That will be approximately 112 to 168 requests for a report date (i.e. July 10th). If you only needed the Inventory Ledger detail report for the US, you are 100x reducing your call volumes. In the EU region, the issue is compounded given the large number of markets (14+). Being selective in your markets can help reduce the number of GET calls.
Example: Amazon Sales Data
Here is another example. The UNOPTIMIZED configuration is selecting all markets and all report types. The OPTIMIZED configuration selects only the US market and two report types. The OPTIMIZED configuration reflects an 90% reduction in GET requests.
Avoid Scheduling Collisions
In our Inventory example above, if you attempt to schedule requests to occur at 1AM for all reports across all markets, GET requests will fail. Why? The volume of requests occurring in the same window will exceed Amazon’s limits. Amazon will charge for all GET requests, this includes rate limit requests.
If you are attempting to run too many requests at once, Amazon will throttle the request for a “retry later”. That is 56 total report variations (4 markets x 14 reports) requested at the same time will no longer be 112 to 168 requests spread over hours, they can balloon to well over 1000 GET requests if they are put into API throttle loop. Amazon will count these requests as billable. (see Advanced Dataset Scheduling)
Amazon Charges For All Types Of GET Requests (Except One)
Amazon Will Charge for Historical GET Requests: Amazon will charge for all GET requests, this includes any historical data requests. If you are attempting to run backfills operations, Amazon will count these requests as billable.
Amazon Will Charge for GET Request Errors: Amazon will charge for all GET requests, this includes rate limit requests (429 Too Many Requests). This can be a complicated topic in the SPAPI, which is why we have detailed a large number of use cases where Amazon will issue a 4xx response to what should be a valid request. See Amazon Selling Partner API Data Feed Limits, Errors, And Constraints: Why NO_DATA and CANCELLED responses are sent from the Amazon Selling Partner API
Amazon NOT charge for GET requests with 5xx Errors: 5xx server responses are HTTP status codes indicating that the server failed to fulfill a valid request due to an error on its end. Common examples include 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout). These errors signal problems like server misconfigurations, overload, or communication failures between servers, and can only be resolved by fixing the server-side issue.
Optimization Limits
While Amazon talks about areas of optimization, these optimizations are ultimately constrained by the SPAPI itself. Take our SQP example, the API requires distinct GET requests for every ASIN. If you have 1000 ASINs, you must make 1000 GET requests for those reports.
Amazon could offer a single ASIN level report, which includes all the applicable ASINs for the seller. Like the Orders Report example, this would be 2-3 GET requests. Only Amazon can solve how the API works for SQP ASIN reports, what Openbridge can do is ensure we are optimized for the required 1000 GET calls for each ASIN SQP report.
The takeaway is that optimizations outlined by Amazon, and additional ones employed by Openbridge, operate within the constraints of how the API itself is designed.