There are hard limits to how fast a repricer can update prices on the marketplace, anybody who claims they can go faster is misleading you. Repricing speed is constrained by marketplace infrastructure, and many “instant” or “millisecond” claims measure only a small part of the process sellers actually care about.
What makes a repricer fast?
An Amazon repricer is fast when it responds quickly to a competitor’s offer change while efficiently managing the seller account’s shared, rate-limited capacity for price updates. The speed that matters to sellers is measured across the repricing path, not just the repricer’s internal processing. Informed Repricer’s high-speed Overdrive repricing architecture delivers sub-10-second repricing, measured from Amazon’s offer-change timestamp to marketplace acceptance of the new price. Solutions that don't measure the full lifecycle could be taking minutes to actually get a new price in front of shoppers. A repricer can advertise “under one second” or "react in milliseconds" while timing only its internal processing. That figure doesn’t capture anything sellers actually care about.
The speed limits fall into three broad categories
- API call limits: Hard ceilings on how frequently the marketplace allows a price change to be submitted.
- Processing time: The repricer calculating and submitting a new price to the marketplace.
- Latency: The one nobody talks about. The delay between a price changing on the marketplace and the repricer getting notified. Then the delay between submitting a price and having it ingested and displayed to buyers.
Why do sellers want to go fast?
There are a few reasons for wanting faster repricing
- The big one: maximize Time in Buy Box. Most sales go to the Featured Offer and longer delays translate directly to less time in the Buy Box.
- Price discovery, to converge on optimal pricing quickly. This is a process of testing many different price points and can take a long time, any part that can be sped up will get inventory moving profitably that much sooner.
- General responsiveness. If a price is ready to be changed, the sooner it can happen the better.
The overarching goal is to make the fewest price changes necessary to achieve the goals of your strategy but to make them as fast as possible after getting new data.
Going fast simply to crash prices and erode margins leads to poor outcomes. Often sharing the Buy Box results in higher revenue and profit for all sellers versus driving down the price by trying to own the Featured Offer exclusively. This is an example of a poor strategy that is made worse by speed.
Using smart strategies is just as important as executing them quickly, executing a bad strategy at warp speed is still racing toward going out of business.
How does Informed Repricer help sellers choose the right strategy? Combining AI and machine learning with more than 15 years of repricing expertise, Informed Repricer has developed powerful algorithms that continually optimize your prices based on your unique goals and respond to competitor price changes in seconds. Learn more about Informed Repricer's algorithms and strategies.
What are the marketplace speed limits?
Let's get into the technical details of the biggest speed limit: API call limits on submitting price changes.
The major marketplaces have two primary paths for third-party tools to submit price changes: bulk feeds and individual updates.
The bulk feeds can contain a large number of price changes submitted simultaneously, this is its own kind of speed. Submitting thousands of price changes one by one would take a very long time. However there are limits on how often a feed can be submitted and how big the feed can be.
In recent years the marketplaces have started offering APIs that allow for updating a single listing. Individual updates are the kind of speed sellers are talking about when they say "fast repricing". These API calls generally have much higher call limits than feeds but much lower throughput because each call is just one price change.
Being able to update a listing in isolation means there's no need to wait for the next batch but there are still very real limits on speed. Submit too many individual updates and subsequent changes will need to wait before being sent to the marketplace. The differing methods of updating a price is why a repricer might support enormous hourly volume while still taking longer to update to one listing.
Price changes for a selling account draw from a shared capacity pool.
Amazon and Walmart Batch Feeds
These are the classic feed files containing many changes submitted via the Feeds API. The workflow is asynchronous, the repricer submits a feed and waits for it to be processed, then retrieves a processing report once it completes.
Amazon Patches and Walmart Direct Updates
These are the modern individual updates that use the Listings API, the format is the same as the feeds but for a single listing instead of a batch.
The workflow is synchronous, the repricer submits a price change and gets an immediate response with the status and any errors that occurred.
In Amazon's case, the patch calls "jump the line" and are processed before any pending batch feeds that have already been accepted. Changes for the same listing in the bulk feed with an earlier timestamp are ignored during subsequent processing.
By the Numbers
Amazon price update limits
| Limit | Batch feeds | Patch API Calls |
|---|---|---|
| Batch size | 25,000 listings | 1 listing |
| Rate | 5 submissions per 5 minutes 1 | 5 requests per second |
| Burst | 15 2 | 5 |
| Maximum submissions per hour | 60 feeds | 18,000 calls |
| Maximum price changes per hour | 1,500,000 | 18,000 |
Walmart price update limits
| Limit | Batch feeds | Direct updates |
|---|---|---|
| Batch size | 10,000 listings | 1 listing |
| Rate | 10 submissions per hour | 100 requests per hour |
| Maximum submissions per hour | 10 feeds | 100 calls |
| Maximum price changes per hour | 100,000 | 100 |
Marketplace Latency: The Other Speed Limit
This brings us to the latency speed limit, where repricers have no control at all.
The catch: when the competitor's price changes is different from when the repricer gets notified. There is always a delay between the price changing and Amazon delivering the event. There is then another delay as it gets sent to the repricer and becomes available to process and then another delay as the message is retrieved from the queue and then yet another delay when a price change is submitted until Amazon accepts it. These delays are insurmountable and on average add up to a full second excluding any processing of the data by the repricer.
Even after getting the notification from the queue, the repricer still needs to calculate a new price and send it to the marketplace. This process has to respect the submission speed limits and manage the shared capacity across all listings.
Once a new price is submitted Amazon and Walmart have to process the change and show it to shoppers. Peak load times cause delays and listings with low glance views, low search volume or low sales volume can deprioritize an update by up to 8 hours. Delays this long are rare but shorter delays of several minutes are common.
These extra delays apply no matter how the price change was submitted.
So even if the API call limits have not been hit yet and there is available capacity to submit a price change, when you add up all the latency that is out of the repricer's control there will almost always be approximately 1 second of additional delays and then a brief wait for Amazon to publish the updated price.
Why do some repricers claim instant or millisecond repricing?
There's no sugarcoating it, this is a marketing claim that they hope you won't examine too closely. They are choosing what to measure and only sharing the timings that sound great. There is a minimum half-second delay after a price changes before Amazon emits the event, millisecond repricing is only possible if you just don't include that latency. Sellers obviously care about the true time it takes to respond to a competitor, not the internal processing time of their repricer.
Informed Repricer is the only solution that actually shows you right on the dashboard how long it takes from a competitor changing their price until the marketplace accepts the new price.
The processing step is the only part that can happen in milliseconds. The best repricers that invest in their infrastructure are able to perform this part quickly. Going faster here is a real advantage and most repricers simply don't have the power to actually calculate and submit a price change in milliseconds. Informed Repricer averages about 70 ms (seven-hundredths of a second) for this process, but it would be dishonest to say that we respond in milliseconds.
What is the value to a seller of a fast internal process if the price a buyer sees takes minutes to change?
Repricers that claim sub-second repricing are starting that timer after they retrieve the notification from the queue, not from when the price change occurred. They stop the timer as soon as the price submission is made, before it is accepted and confirmed. They are reporting the best timing they have ever gotten in testing, not the realistic response times you will see when using their service.
So how fast is Informed Repricer really?
At Informed Repricer we're very committed to always using real data and only making claims that we can back up transparently.
The Overdrive priority repricing path runs dedicated infrastructure that only processes the listings you select to ensure there are no delays from other listings. Overdrive consistently provides sub-10-second true end-to-end repricing from Time of Offer Changed to a confirmed acceptance of the new price by the marketplace. Best-case scenario timings are 0.6 to 1 second, however that is luck of the draw when the marketplace delivers a notification faster and the delivery latency happens to be near zero.
The Overdrive average speed metric on the dashboard always uses the Time of Offer Changed directly from Amazon so you know how long it actually takes to respond to your competitors, not some arbitrary timer deep within the repricer.
Non-Overdrive listings take 60-120 seconds to get included in the next batch feed.
Summary
After all of the technical details and timing information, what should you take away from this?
- Prioritize strategy over speed: know why you want to reprice faster. The goal is to respond quickly while making only the price changes a seller’s strategy requires.
- Marketplace repricing speed depends on more than how quickly a tool calculates a new price: API limits, notification delays, queue processing, and marketplace latency all affect the result.
- Always compare speed claims using the same start and end points. Internal processing time is not end-to-end repricing, be very skeptical of sub-second claims.
FAQ
Why does Overdrive allow only 500 listings?
The Overdrive limit might seem low at first. Why restrict direct submission to 500 listings if the theoretical maximum is 18,000 changes per hour?
This was something we studied at length and discovered that making a price change often results in other sellers on the listing responding, triggering immediate responses. When a price change for a single listing can be made every 5-10 seconds this cascade can take up a large amount of the capacity for each selected Overdrive listing. In reality not every enrolled listing needs an update continuously or simultaneously. The 500 listing limit provides enough room for all of the selected listings to be able to operate at full speed. In the worst-case scenario, if every single one of the 500 listings needs a price change every 10 seconds there would only be enough capacity for 36 price changes per listing per hour. This is still slightly faster than using bulk feeds but not by much. Increasing the number of Overdrive listings would create scenarios where Overdrive is actually slower than using bulk feeds.
The upper limit for actually submitting a price change every 10 seconds is 50 listings. As noted above, repricing should support a seller’s strategy. This level of churn does not serve a strategy.
Can native repricers go faster?
No, Amazon Automate Pricing and Walmart Repricer are subject to the same speed limits. They use the same APIs internally and do not have fast lanes or priority processing for their own changes.
In most cases they will be slower than the best third-party repricers, especially during peak times when speed is crucial.
Why are Walmart speed limits so much lower?
The focus of this data is Amazon because the rate limits are much higher and that is where the frontier of high speed repricing is occurring.
The Walmart marketplace has been steadily building out their API and the submission rate has increased greatly over time. We expect the rate to increase in the future but currently Walmart does not allow more frequent price changes.
Informed uses the same infrastructure for Walmart and Amazon. All of the stages of processing that are within our control happen in the same 70 ms for all marketplaces. Walmart submissions have to respect the marketplace limits but as the limits change our Walmart submission speed will always go as fast as the marketplace allows.
Footnotes
Footnotes
-
The rate sounds like one per minute but actually means that you get one call per minute added to the rate limiter bucket up to a maximum of five. You can make 5 submissions at once if it has been five minutes since the last submission. Sounds confusing? You're not alone, the "token bucket" rate limiting algorithm that Amazon uses drives developers nuts. ↩
-
The burst rate applies to submissions for all feed types but for the JSON feed type itself the stricter 5 per 5 minute rule applies. The burst is useful for working with multiple feed types without having to slow down the price feeds in order to make other submissions. ↩