What data is Amazon hiding from your favorite seller software tools? A guide to what Amazon hides (and doesn’t hide) with your scouting app, listing tool, and repricer.
The is the first article go in depth into the hidden world of Amazon data, what data Amazon is hiding from software tools, and how it affects sellers.
This is going to be very practical and non-technical. And it impacts every single person selling on Amazon.
What I’m going to cover:
- How Amazon shares data with software tools (scouting apps, listing tools, etc)
- How Amazon sellers are unknowingly dependent on Amazon’s “APIs”
- What data Amazon hides from software tools
- How these “blindspots” are costing every seller both sales and profits
How a simple Amazon seller was forced to understand “APIs”
I’m not a technical person. I can’t write a line of computer code. I’ve even tried to sign up for Inventory Lab a couple times and got hopelessly confused. So “analyzing data” is not my forte. But I was forced to understand Amazon’s APIs by using tools that depend on them in my Amazon business. And its necessary for all Amazon sellers to do the same.
My journey into this fringe subject started in 2012. On September 1st of that year, I noticed the “FBA” column of my scouting app went (mostly) blank. As in, there were no FBA prices visible for a large percentage of books I was scanning. I thought that was weird, so I started to click over to the Amazon page and notice that my app was wrong: There were FBA offers for most of these books, even if the app showed there were no offers.
It wasn’t just me seeing this. On that day in 2012, all Amazon sellers watched many (most?) FBA prices vanish from their apps, repricers, and anywhere pricing data was displayed. And this was the first time myself and many sellers became aware of how dependent we were on something called “Amazon’s API.”

September 1st 2012 was the day everything changed.
So what happened? It wasn’t a bug or glitch of any kind. Amazon simply quietly changed a small detail in what pricing data it would share via their API – specifically, that no FBA prices will be shared unless they are positioned in the lowest 20 (this is covered in Blindspot #2, below). This tiny change could have gone missed by developers, and anyone who didn’t scour obscure Amazon technical docs. But it’s impact on sellers would be massive.
Later, I would be forced to become even more acquainted with Amazon’s APIs through founding several software tools for Amazon sellers (notice I said “founding,” not “building” – like I said, I can’t write a line of code).
The most fundamental thing to understand about this entire subject is this:
The data you see in apps represents a selective view of reality.
Amazon shares the data it wants to share, and hide’s the data it doesn’t. And when it hides something, you probably won’t even notice.
The point of this article is to reveal what you probably didn’t even know you were missing.
How to use this article
You have two options:
- Read everything. I’m going into detail on what Amazon’s APIs are, and why they matter. Then, I go into specifics on how your scouting apps and repricing tools (and more) aren’t showing the pricing data you think they are.
- Skip to learn what data you’re missing. Aka the “API blindspots” that affect every seller. Skip to that here.
What is an “API”?
API stands for “application programming interface.”
In the context of Amazon, the simplest way to look at an API is like a giant hose that data passes through. A software application connects to the API (the “hose”) and requests certain data. It could be pricing data, sales rank data, or anything. Amazon then grants access and returns that data through the API.
Companies like Amazon create APIs to encourage software developers to build applications on thei. APIs make developing software applications much easier, by providing a simple way for two tools to work together.
The API that Amazon created for tools that help sellers (like Scoutly, Scanlister, etc) is called the “Selling Partner API.”

APIs are a big part of software development, and are used by tens of thousands of tools.
Why do tools depend so heavily on Amazon’s API?
We’re here to talk about important data Amazon hides from it’s APIs. So if Amazon’s APIs have such severe limitations, why do software tools depend on them so heavily? Why don’t they simply find another way to get the data?
There’s a couple answers to this.
#1: A lot of data is not accessible any other way. For example, if you want detailed sales history of your account, there’s probably not a way to obtained that programically. You need direct access to Amazon’s internal data via the API.
#2: It’s a lot harder to build software without APIs. The difference between obtaining data via an API and getting it another way is like the difference between filling your car with gas at a gas station, and drilling a well yourself. Even if drilling your own well meant higher quality gasoline, you’re going to choose the gas pump every time. Going to the source yourself is simply too much work.
#3: Most software tool don’t even know all of Amazon API limitations. I released my first software tool for sellers nine years ago. I still have no understanding of 99% of API “requests” (requesting data from Amazon), or what their limitations are. I know developers who have worked with Amazon’s APIs for years and have no idea about much of what I’m going to talk about here. It’s very easy to work with Amazon’s APIs and never learn of their limitations.
#4: Many software tools don’t think the API limitations are a big deal. Sometimes they’re right. Other times, they grossly underestimate the impact of API limitations on Amazon sellers. And other times, they understand the impact, but downplay them out of fear of losing subscribers.
Even seasoned developers have major problems with Amazon’s APIs
The one thing you’ll hear from any developer who tries to build an Amazon-based software tool is how terrible Amazon’s developer documentation is.
“Documentation” refers to the instructions provided to developers on how to make data requests, what data is returned in those requests, possible errors that can be made, and more.
Having hired over a dozen developers over the last nine years, every single one who reviews Amazon’s API documentation for the first time inevitably comes back flabbergasted at how poorly explained everything. Have you ever submitted a help request to Seller Central support and come away thinking “how is it possible for a company this big to be this terrible at everything?” That’s how developers respond to trying to make sense of Amazon’s API documentation.
For this reason, it’s very common for even seasoned Amazon application developers to be unfamiliar with countless details of Amazon’s APIs. It’s just too much to hack their way through.

Common complaint from a developer about Amazon’s Selling Partner API documentation.
So what APIs do common tools for Amazon sellers use?
Amazon has over a dozen APIs, all of which provide different data for different functions. Each API exists under the broader “Selling Partner API.” The majority of these will never be used by any tool that would be used by sellers like you and I. What follows is a list of APIs that might be used by some of the more common software tools.
For the purpose of this article, I’m going to focus on a few API issues that impact the tools that have the biggest impact on your business:
- Scouting / inventory sourcing apps.
- Listing tools.
- Repricing tools.
Not being a developer myself, the technical details and nuances of these APIs may not be entirely clear to me. But I will explain each to the best of my understanding.

Feeds API
This is an API used by tools that let you bulk upload changes to your seller account, such as condition notes, prices, etc.
Amazon says:
“With the Selling Partner API for Feeds (Feeds API), you can build applications that enable sellers to upload information to Amazon that helps them manage their selling businesses. There are feeds for a wide variety of use cases, such as creating listings, managing inventory and prices, acknowledging orders, and more.”
Catalog Items API
This API lets software retrieve detailed item information about items in the Amazon catalog, such as product dimensions, images, sales rank, and more.
Listings API
Used by listing software to create submit listings to Amazon on your behalf.
Orders API
Used by tools to create reports based on a seller’s order history.
Amazon says:
“Use the Orders API to programmatically retrieve and submit order information. This API is designed to help Selling Partners develop fast and flexible custom applications that facilitate order synchronization, order research, and demand-based decision support tools.”
Product Fees API
This API is used to calculate selling fees. Commonly used by listing tools and scanning apps.
Amazon says:
“The Selling Partner API for Product Fees lets you programmatically retrieve estimated fees for a product. You can then account for those fees in your pricing.
The Product Fees API retrieves product fees for multiple products. You can use the
getMyFeesEstimatesoperation to get product fee estimates for a list of products and marketplaces, and then set prices based on those fee estimates. You must specify your products by ASIN or SKU (not UPC, ISBN, or other identifiers).”
Product Pricing API
This is the API used by repricing tools to optimize prices.
Amazon says:
“The Product Pricing API enables apps to automate updating and managing prices on behalf of sellers, and reduces the manual effort and time required to keep prices competitive.”

Reports API
A general API that returns many metrics from an Amazon seller’s account.
Amazon says:
“Use the Selling Partner API for Reports (Reports API), to build applications that get reports from Amazon to help selling partners manage their business. The API provides reports for a variety of use cases including: monitoring inventory, tracking orders for fulfillment, getting tax information, tracking returns and seller performance, managing a selling business with Fulfillment by Amazon, and more.”
Sales API
It’s not entirely clear how the Sales API is different than the Orders API, but this is another way for software to obtain sales information.
Amazon says:
“The Selling Partner API for Sales (Sales API) provides sellers with sales performance information. This is achieved through returning aggregated order metrics for a given period of time, broken down by granularity, and buyer type.”
Understanding software “Roles”
I promised not to make this technical, and I’m going to keep that promise. But one final boring technical detail about Amazon’s Selling Partner API is the “Roles” that each application is granted.
You’ll notice when you link any Amazon selling software tool to your account, you are first taken to a page with a list of “permissions” (aka Roles) that you are granting to each tool. They look like this:

“Roles” are to APIs what tickets are to concerts. The Role determines what data you can access from what API.
None of this is necessary to understand as an Amazon seller, but it will help inform what’s to come.
Examples of API roles different Amazon tools have
If you ever wonder what data any Amazon software tool is accessing, you can always confirm by going to Apps and Services -> Manage Your Apps -> Reauthorize.

Scoutly
- Selling Partner Insights
-
Amazon Fulfillment
-
Pricing
-
Product Listing
Accelerlist
- Selling Partner Insights
-
Amazon Fulfillment
-
Pricing
-
Finance and Accounting
-
Product Listing
-
Inventory and Order Tracking
Go2Lister
- Selling Partner Insights
-
Amazon Fulfillment
-
Pricing
-
Finance and Accounting
-
Product Listing
-
Inventory and Order Tracking
-
Buyer Solicitation
-
Buyer Communication
-
Brand Analytics
RepriceIt
- Notifications in Seller Central
-
Selling Partner Insights
-
Amazon Fulfillment
-
Pricing
-
Product Listing
-
Inventory and Order Tracking
Which APIs have the biggest impact on Amazon sellers?
You can divide Amazon data into data that directly impacts your profits, and data that indirectly impacts your profits.
When you think about it, there’s only two behaviors any Amazon seller engages in that directly translates to profits:
- Sourcing inventory.
- Repricing inventory.
Nothing else directly converts to money in your pocket.
With this in mind, the highest-impact data is anything that impacts sourcing or repricing. This means that far and away the most sensitive data is anything that can result in:
- Making a poor purchasing decision.
- Repricing your inventory incorrectly.
So I’m going to focus on the blindspots that impact each of these, since they actually mean money stolen out of your pocket as a seller.
Here they are: three examples of major blindspots in Amazon’s Selling Partner API (and #2 is by far the most serious)…
Amazon API limitation #1: You can’t see all FBA offers
It’s true: Your sourcing app and repricer cannot access many FBA offers. It’s telling you that you’re seeing everything, but you’re not.
Amazon’s APIs will not share any FBA offer unless it’s priced among the lowest 20.
Because FBA offers are most often priced higher than non-FBA offers, and very often outside the lowest 20, that means that a lot of FBA offers are not being dispalyed in Amazon applications.
This blindspot is almost totally unknown outside small pockets of the Amazon selling world, and most software developers are totally unaware of it.

How this blindspot impacts scouting apps
The quality of your purchasing decisions correlates to your profits as an Amazon seller. And that’s where the FBA blindspot can have a severe impact on your profits.
The blindspot will manifest in your sourcing app in one of two ways:
- The FBA column will be blank (meanwhile, this item does have FBA offers, they are just invisible to the app due to the API blindspot).
- The FBA column will display only one or two FBA offers (meanwhile, there are numerous over FBA offers, but they are invisible because they are in the blindspot).
Let’s take a relatable example of finding a textbook when you’re sourcing for used book inventory. You scan it, and your app lights up. You get a green “Accept” screen, meaning your app triggers are telling you to “buy this book.” You look at the screen, and the FBA column is blank. This is significant, because it means that as an FBA seller, you can price that book as high as you want. Textbook season is coming up, so you think you’ll price it at $99. That’s around $80 profit. You’re ecstatic.
Then you get home and go to list the textbook. You’re confused, because while the app showed there were no FBA sellers selling this book, you see something very different on the Amazon product page. There are over a dozen FBA offers, all of them around $14 to $16. It’s a huge heavy textbook, so at $14 your payout is only $1.90. And you paid $2 for the book, which means you’re losing money on this purchase.
The book you thought was going to net you around $80, is actually a dud. You’ve just become a victim of the FBA blindspot.

How this blindspot impacts Amazon repricing tools
The biggest impact of this API blindspot isn’t on scouting apps, it’s actually repricing tools. That’s where this “lowest 20 offers only” limitation gets really expensive.
If you have any FBA-based pricing rule in your Amazon repricer right now, here’s is what’s happening to you (again, this isn’t theoretical – this is happening to you right now). For any listing that has its lowest FBA offer in the blindspot, your repricer will either:
- Reprice that item too low (it uses some fallback option like “if lowest FBA price doesn’t exist, match the lowest Merchant Fulfilled price.”)
- Not reprice that item at all (since it has no FBA price to price against, the repricer simply ignores that item completely.)
Both of these are extremely costly mistakes.
What’s even worse: Your Amazon repricer doesn’t even tell you this is happening. You won’t get an error message. No alarm bells will go off. Your inventory will quietly be mispriced (or not repriced at all), and you’ll never notice. This could happen for years (and likely has been), and you will simply never notice.
To make the impact of this on your repricing crystal clear, here is a common hypothetical:
- Let’s say you’re an FBA seller, and you have a simple pricing rule to reprice your inventory to match the lowest FBA price.
- Let’s say you have an item that has 40 other sellers.
- Let’s say that the lowest 20-priced offers range from $5 to $10.
- And let’s say the lowest price FBA offer is higher (as often happens), at $11.
Your repricer will have not idea how to reprice this item. Since the API isn’t sharing that $11 FBA offer, the reprice doesn’t even know it exists.
And your profits suffer accordingly.

How the FBA blindspot impacts Amazon listing software
The impact on listing tools is minimal – unless you don’t reprice your inventory often.
If you rely on listing software to set your initial price – and then don’t reprice once your inventory goes live – then the impact will be the same as the impact on repricers. In other words, if you apply any automatic pricing rule in your listing tool where you are comparing to other FBA offers, then sometimes your listing tool won’t be able to see the lowest competing FBA offer.
However for any pricing rule that calls for comparing to the lowest overall price, or the Buy Box price, you won’t have any issues.
Proof of this API blindspot
Here is a collection of documentation of the FBA blindspot, from Amazon directly, and other sources:

Amazon API documentation. Only 20 pricing results are returned, which inadvertently reveals the FBA blindspot

Amazon explaining that their API only shares 20 results

Note Amazon says “the top 20 offers” aka the lowest-priced 20 offers.

A screenshot from Scoutly, with their statement on the FBA blindspot

A discussion from a repricing tool on the impact of Amazon’s API blindspot. Personally, I do not believe the impact is as severe as is stated here, but is still serious.


A chart from Scoutly showing comparing what prices would be displayed without the FBA blindspot, and then with the blindspot. Big difference.

Typical complaint from a software developer, confused about why Amazon’s API is not returning all pricing data
How seriously does this blindspot impact Amazon sellers?
The impact of the FBA blindspot is serious, but very difficult to quantify.
We can only calculate what data Amazon does show, not the volume of what it doesn’t show. And getting specific numbers on how many FBA offers are in the “blindspot” can only be assessed anecdotally.
Specifically, you can better understand the scope of the problem two ways:
- Comparing data displayed in your app to the actual prices displayed on the Amazon product page.
- Comparing FBA price changes made by your repricer to what the correctly updated price should be, based on live prices displayed on the Amazon product page.
Both of these have to be done manually. But when you start doing this, you’ll quickly start to see concerning discrepancies.
What is my opinion about how much this impacts Amazon sellers? I think some of the biggest doomsday estimates about the impact of this blindspot (see the screenshot above estimating “86% of all books are affected”) may have been true at one time, but the impact has diminished somewhat in recent years.
Years ago, it was more common to see FBA offers priced $10, $20, and $30 or more above non-FBA offers. In recent years, FBA prices have come down. That means lots of products that would have had competing offers in the blindspot, have been brought down into the lowest 20 offers.
With that said, there is no such thing as a small data discrepancy when it comes to sourcing and pricing. Your profits as an Amazon seller are in direct proportion to both your inventory purchasing decisions, and your repricing decisions. Any data that causes errors with either of these creates losses that compound over time.
There is no such thing as a small data discrepancy when it comes to sourcing and pricing. Your profits as an Amazon seller are in direct proportion to both your inventory purchasing decisions, and your repricing decisions. Any data that causes errors with either of these creates losses that compound over time.

Does the FBA blindspot affect certain categories more than others?
Yes. This API blindspot has a serious impact on some product categories, while it’s impact on most categories is actually minimal.
The reason is this: Remember that the problems only happen when there is an FBA offer priced above the lowest 20 Merchant Fulfilled offers. That means that only products that have at least 20 individual listings are at risk.
Only Amazon product categories that frequently see more than 20 offers for items are at high risk.
If you look at a variety of product categories, you’ll notice that in some it is very common for certain ASINs to have more than 20 sellers, while in other categories its actually very rare.
One one end of the spectrum: the Books category. Probably the majority of books for sale on Amazon have more than 20 sellers. That doesn’t mean the majority of books can’t be repriced or will have errors in your scanning app, just that there is the potential for that. 20+ sellers creates the opportunity for blindspots.
On the other end, the Grocery category. It’s pretty uncommon to see an ASIN in Grocery with more than 20 sellers. So the Grocery category is largely unaffected.
In the middle, a category like Toys. It’s not common for a product to have 20+ sellers, but it’s no uncommon either.
The categories with the highest average number of sellers on a listing are the media categories: Books, CDs, DVDs, and so on. If you’re selling used media on Amazon, you are losing money this blindspot daily.

Sample math on the impact of the FBA blindspot on repricing
Since we can’t know the true degree of FBA offers in the blindspot, I’m using some hypothetical numbers. I think these estimates are conservative, but feel free to adjust up or down based on your personal estimates.
- Let’s say your Amazon repricer is only missing 10 offers a day. That’s 10 offers out of your entire inventory that have the lowest FBA offer outside the bottom 20, and in the blindspot. In this instance, your reprice will either skip that item, or reprice it too low.
- (If your inventory is in the high hundreds or thousands, I think this estimate is going to be extremely low, and you should adjust accordingly.)
- Let’s say of those 10 items, one would have sold today – if it had been repriced correctly.
- Let’s also assume your average selling price is $15 (pretty low).
That means the blindspot is costing you $450 in sales every month.
And we’re only counting lost sales. This doesn’t include inventory priced too low – where you could have gotten an extra $1 or $3 or $10 if it had been repriced correctly.
And this is only if your inventory is relatively small.
And these losses compound month after month, year after year.
Any way you run the numbers, the impact of this API blindspot on your Amazon business is significant.

Amazon API limitation #2: You can’t see every competing offer, in order
This is the most significant blindspot of all, and impacts every Amazon seller.
Amazon does not show the price for every listing, in order.
You think your scanning app is showing you the lowest 5 offers. It’s not.
You always wondered why your repricer wouldn’t let you reprice against the 2nd, or 3rd lowest competing offer (or beyond). That’s because it can’t.

Here’s what this means:
When your repricer or sourcing app goes to Amazon’s API and says “show us lowest offers for (any product),” Amazon does not share the lowest offers, individually, in order.
You are never seeing a continuous list of prices, from lowest to highest. You just think you are.
Instead, Amazon shares “bundles” of offers in what they call “offer groups.” These bundles can represent between one and several offers, grouped by condition. These “bundles” represent listings that are similar in price, but are not necessarily individual listings. That means that while your app might show you this:
- Lowest price: $11
- 2nd lowest price: $12.50
- 3rd lowest price: $12.75
- 4th lowest price $13
- 5th lowest price: $16
If you click over to Amazon, you might see this:
- Lowest price: $11
- 2nd lowest price: $11
- 3rd lowest price: $12.10
- 4th lowest price $12.50
- 5th lowest price: $12.51
- 6th lowest price: $12.75
- 7th lowest price: $12.75
- 8th lowest price: $12.75
- 9th lowest price: $12.99
- 10th lowest price $13
- 11th lowest price: $13.02
- 12th lowest price: $16
In this example, your app indicates there are only four offers between the lowest offer and $14. If this was a high-demand book, you might purchase it with the expectation you can list it for $15.99, and get a few extra dollars above the lowest price. But since the offers are grouped together, the reality is that there are 10 offers between the lowest price and the $16 offer.
What is displayed in your app and the reality on Amazon are completely different.

The reality is that each of the prices shown in your app could represent between one and several offers, each “bundled” with other listings, and displayed as one offer. Those five lowest offers could represent 15 offers (maybe more).
This makes it impossible for any application to ever conclusively say what the first, second, third (and so on) lowest offers are for any item.
- This impacts your purchasing decisions (when using an app like Scoutly).
- Even more seriously, this limits your repricing options (when using a repricer like Bqool).
This is by far more serious than the FBA blindspot, for three reasons:
- It impacts every Amazon seller (not just FBA sellers).
- It impacts every category equally.
- It impacts ever product (not just products with 20 or more listings).
Proof of the “Bundle Blindspot”
Amazon is more open about this blindspot than the FBA blindspot. You’ll see talk about this both in the API documentation, and this is mentioned by at least one of the major sourcing apps (specifically, Scoutly).
Here are some screenshots:


Another example of developers confused by missing pricing data in amazon’s api
How this blindspot impacts scouting apps
This “bundle blindspot” prevents you from making informed purchasing decisions, because your app is not showing you all prices (only “bundles” of prices).
When you scan an item to resell (using an app like Scoutly or ScoutIQ), you are expecting to see a list of current, competing offers for that item. Sellers use this information to make an informed purchasing decision. Among the questions you’re trying to answer when reviewing product prices is: “Is there any opportunity to price above the current lowest price?”
If you’re an FBA seller, we’ve already discussed how Blindspot #1 prevents you from seeing the lowest FBA offer in many instances. This is one way Amazon’s APIs prevent you from answering this crucial question.
But the “Bundle Blindspot” impacts all sellers, and prevents you from answering this question in a different way: You are unable to see a continuous list of all offers, from lowest price to highest price. Amazon’ simply won’t share this data.
This makes it impossible to ever confidently trust any price you see, other than the lowest priced offer (which is always accurate).
Example: Your app might be showing you prices indicating the lowest price if $12, and the 2nd lowest is $20. The book has only moderate demand, so you’re comfortable pricing above the lowest price, but not too much higher. This book isn’t profitable at $12, but based on the prices you’re seeing, you’re comfortable pricing this book at $19.50.
Then you get home, and you see there are 3 listings for $12, and that $20 offer is the fourth listing. This is a totally different scenario. Now three offers have to sell out before you’ll get a sale, instead of just the one that you expected. What happened? Amazon “bundled” those three $12 listings into one, so they appeared as one offer in your app.
This blindspot means the only price you can ever trust in your app is the lowest price Merchant Fulfilled offer. Everything else is subject to Amazon’s API blindspots.




How the “Bundle Blindspot” impacts Amazon repricing tools
There is no way to overstate the seriousness of this blindspot on repricing. No matter what size of a seller you are, this blindspot is costing your thousands of dollars a year.
The Bundle Blindspot quite simply prevents your repricer from raising prices, resulting in a profit-destroying “race to the bottom.”
This turns Amazon repricers from tools that should optimize your prices (setting the best price to get maximum profits) to tools that instead chase the lowest price downward (because Amazon’s API won’t share an exact list of all listings).
This blindspot means that no repricer (except one) gives you the opportunity to compare your price to the 2nd or 3rd (or beyond) lowest offer – only the lowest.


The magnitude of the impact on your profits may not be something you’ve never considered, because you never thought about what you’re missing. Sellers take for granted that they can’t raise their prices above the lowest offer, but never considered why.
Right now in your inventory are dozens, or hundreds, or thousands of opportunities to raise prices and extract more profit from existing inventory. These pricing opportunities can range between increases of a few cents, to increases of $10 or $20 (or more). Same inventory, more profits.
The ability to price above the lowest price would allow you to extract more profit from the same inventory, with no additional work.
And right now, the Bundle Blindspot makes that impossible.
When it comes to Amazon prices, there is nothing sacred about the “lowest price.” That lowest price just happens to be the lowest price right now. Over a single week, the lowest price for an item might fluctuate between $10 and $13 then down to $12 then $20 then $14 then $25. Your repricer (that works under the tyranny of the Bundle Blindspot) can only reprice based on that lowest price. This means you have an item that sells for $10 on a Monday, when it could have sold for $25 on a Friday. You’ll never know, because you surrendered your inventory to a tool that can only chase that lowest price.
Choosing to tolerate the Bundle Blindspot also ignores that products sell for prices above their lowest price all the time. Maybe the lowest priced offer is in Acceptable condition, while yours is Very Good. Too bad: your repricer won’t let you factor this in. You are simply forced to chase that Acceptable offer, even though your offer is “worth” more.
The inability for Amazon repricers to raise prices (only lower them) due to the Bundle Blindspot is the single most expensive problem with Amazon software today.
How this blindspot impacts Amazon listing tools
Similar to the FBA blindspot, the impact is minimal unless you use your listing tool to set the price you will be selling your item for.
In other words, if you don’t reprice your inventory (or don’t reprice it often), then the Bundle Blindspot will impact you the same way it does if you were using a reprice: You will unable to confidently price against anything other than the lowest price offer.
How seriously does this blindspot impact Amazon sellers?
The Bundle Blindspot is the most expensive blindspot of all.
- It has medium impact on scouting apps.
- It has maximum, critical impact on repricers.
When it comes to sourcing, it is certainly causing consistent purchasing errors.
When it comes to repricing, it is impacting literally every item in your inventory, forcing your prices downward in a race to the bottom.
Sample math on the impact of the Bundle Blindspot on repricing
Let’s take a sample inventory size of 1,000 items.
Let’s say 25% of that inventory is low-demand, so match the lowest price might make sense.
Now let’s saw the other 75% will very realistically sell at a price higher than the current lowest price. The demand is high enough that there are frequent price fluctuations that make this likely.
Now let’s say that for the majority of those, the price difference between the lowest price and higher prices averages to be only 10 cents. Not a big deal. Prices tend to bunch up, and you don’t expect any giant gaps that will yield multiple dollars in extra profit. Let’s say of those 750 items, 600 of them average only a 10 cent increase.
Now let’s say that of the 150 items that remain, the ability to raise prices means a significant boost in profits. Let’s say (round numbers) it averages to be $1. For lots of inventory, you might be getting several extra dollars. And for others, only 50 cents. But let’s assume for those 150 items, it averages to $1.
I’m using what I think our conservative numbers here, but you just extracted an extra $210 in profit from existing inventory, with no extra work.
Using this conservative math, your repricer is costing you $200 a month in lost sales even with a small inventory.
That’s profit that’s currently being wasted, because your current reprice is under the tyranny of the Bundle Blindspot. It simply can’t raise prices.
Amazon API limitation #3: You can’t compare used condition items to new condition items
This is sort of a “bonus” blindspot, included as an example of the numerous small blindspots that Amazon imposes on software.
While the impact of all these “smaller” blindspots can be significant, they are too numerous to list in full. So I’m using this as an example of the abundant ways Amazon limits the range of options in software used by sellers.
Amazon’s “Product Pricing API” (used by repricers) does not allow you to compare the price of a Used offer to a New offer, or a New offer to a Used offer.

Conversation with Bqool support, confirming the existence of this API blindspot
Ever notice this? No repricer (except one) lets you set a pricing rule like this:
“Match the lowest Used price, unless it’s higher than the New condition price, in which case price $1 below the New condition price.”
Repricers do not allow you to compare the price of your Used condition listing to the price of competing New condition listing, or vice versa.
What is the impact of this? It’s not uncommon for New condition prices to dip below Used condition prices. If your Used offer is priced about competing New offers, that’s costing you sales. But this will be invisible to your current repricer. Again, costing you sales.
Likewise – particularly for low-demand items – you may want to match your New condition offer to competing Used condition offers. Unfortunately, this is impossible.
Again, this is just one example of the many ways Amazon limits on what can do when you use tools that depend on their APIs.
How secretive are these blindspots?
Is Amazon actually covering up these blindspots? And what about the software tools themselves? Is there a conspiracy of sorts to keep this information from you? Why is this the only serious look at this issue that’s been published? Why is no one talking about this?
We can address the question of a “coverup” in two parts: Amazon covering up these blindspots, and the software tools who use Amazon’s APIs covering them up.
Does Amazon cover up their API blindspots?
The answer to this, mostly, is no. Amazon engages in omission, but not outright lies.
They certainly don’t advertise the blindspots to sellers, but Amazon didn’t create APIs for sellers. They exist for software developers. And Amazon communicates these blindspots to developers in the Selling Partner API documentation. The documentation is not written for sellers, so it feels like obfuscation. But for any developer who takes the time to understand the API functions and read the documentation, these limitations are there.
What is not made clear is the impact of these limitations on the users of the software. Since the people writing the software code are rarely sellers themselves, its extremely unlikely they understand the impact of these API limitations on the end user – even if they are spelled out in the documentation.
Are software companies covering up these API blindspots?
The answer is most definitely “yes.”
When we talk about software companies, we’re talking about hundreds of tools that depend on Amazon’s Selling Partner API. And a full audit of each one would be a big challenge.
What we can do more thoroughly is look at the three main “pillars” of Amazon selling software: Sourcing apps, listing tools, and repricers.
Are scanning apps covering up Amazon API blindspots?
Two of the larger sourcing apps – Scoutly and ScoutIQ – have both acknowledged the FBA Blindspot and the Bundle Blindspot to varying degrees. Which is good.
Outside those two apps, I was unable to find full disclosure about these blindspots from any other tool.
Are listing tools covering up Amazon API blindspots?
While I couldn’t find any mention of these blindspots on any listing tool websites, as covered above, the impact is less severe with listing tools than scanning apps or repricers. So I understand why listing tools are shouting these blindspots from the rooftops. Unless you’re never repricing, the stakes are pretty low and the impact is not significant.
Are repricing tools covering up the Amazon API blindspots?
A massive, massive “yes.”
The majority of Amazon repricers will deny these blindspots exist, even when asked directly.
The coverup is so severe I did an entire article documenting most major repricing tools denying the existence of these blindspots.
As part of a mini “sting operation,” I contacted every major repricer and asked them point blank if they had any blindspots (specifically around FBA data). The results were worse than I expected.

The final tally went like this:
- Repricers I contacted: 22
- Repricers who did not admit they had blindspots: 15
- Repricers who were honest: 2
- (Repricing companies who didn’t respond: 5)
Only two repricers – RepriceIt and Sellery – admitted to the FBA blindspot.
Read the full results. (with screenshots)
What about the Bundle Blindspot? This isn’t something repricers need to “confess” to, since they can’t hide it – they openly don’t allow the option to raise prices above the lowest. So the whole world knows this isn’t an option, and repricers aren’t making any false promises. What’s never explained is why repricers don’t offer this crucial option. But there are no overt lies repricers are guilty of in regards to Blindspot #2.
What other blindspots don’t we know about?
What we’ve covered is probably just the tip of the iceberg. In this article, I’ve documented the two highest-impact API blindspots. There are certainly many more.
Amazon’s documentation is so dense, and there are so many functions, parameters, and “use cases,” that impossible to hack your way through it all to a definitive list of the data Amazon won’t show us, and the things it won’t let us do.
The actionable takeaways
We just learned that your sourcing app isn’t seeing all pricing data. Your repricer isn’t comparing your offer to all competing offers.
Understanding these facts destroys a powerful illusion that our software tool provide us a window to reality, instead of the map of reality that Amazon wants us to see.
Your options are:
- Accept the limitations of existing software, and the expensive mistakes they produce.
- With apps, reduce your depedency on API-sourced data and verify prices independently as needed
- Use tools that don’t rely on Amazon’s API (when available).
-Peter Valley



Leave a Reply