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-2-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 owning 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.
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 mean when they talk about "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 a single 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 a 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 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 most impressive timings. 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 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.
What competitors mean by "instant" or "real-time" (and why it isn't end-to-end speed)
When evaluating repricing software speed claims from tools like BQool, Aura, Repricer.com, and Seller Snap, it helps to understand exactly what each vendor's timer measures versus a true end-to-end measurement.
BQool "Instant Repricing" According to BQool's Help Center (updated October 2025), BQool's instant repricing is defined as completing the repricing calculation and sending the final price adjustment to Seller Central after receiving Amazon's notification. In other words, BQool's clock starts when their system picks up the SQS notification and stops when the submission is sent. Marketplace acceptance, propagation, and buyer-visible publication are outside that timer. That's a calculate-and-send definition, not an end-to-end definition.
Aura "Hyperdrive" Aura touts a high-speed repricing mode they call "Hyperdrive" tied to a prioritized repricing path. The claim is directionally accurate in that a prioritized path does process faster than a standard queue, but Aura's marketing copy doesn't specify whether the stated 10-second speed measurement includes notification delivery time, queue retrieval, or marketplace acceptance latency. Without those endpoints defined, any timing figure describes a portion of the journey.
Repricer.com "React in Milliseconds" Repricer.com makes one of the boldest speed claims in the category, stating that their repricer reacts to competitor price changes in milliseconds. As we've already established, the millisecond window is only achievable for the internal calculate-and-submission step, not the full end-to-end journey. Amazon's SP-API notification delivery alone introduces latency that makes a true millisecond response from offer-change timestamp to confirmed marketplace acceptance physically impossible. Repricer.com does not define where their millisecond timer starts or stops, which means the claim describes their internal processing performance, not the buyer-visible repricing speed a seller actually experiences.
Seller Snap Seller Snap positions its repricing as "real-time" and "instant", their speed story leans on their AI game-theory engine and data infrastructure. What's absent from their public documentation is a defined start/end timestamp for that speed claim, making it difficult for a seller to independently verify what "instant" means in buyer-visible terms.
The pattern is consistent across competitors. Every repricer is measuring something, and that something is certainly fast. The problem is that no competitor publishes a metric grounded in Amazon's offer-change timestamp through to confirmed marketplace acceptance. That gap is exactly what Informed Repricer's transparent Overdrive metrics closes.
Quick audit checklist: questions to ask any repricer about speed claims
- Where does your speed timer start? (Offer-change timestamp or internal queue pickup?)
- Where does it stop? (Price submission sent, or marketplace acceptance confirmed?)
- Is the stated time a best-case, average, or median?
- How is marketplace propagation latency accounted for?
- Can I see this metric live on a dashboard for my own listings? If a repricer can't answer questions 1 and 2 precisely, their speed claim isn't measuring the number you care about.
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-2-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.4 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.
We can confidently state that Informed Repricer is the fastest repricer in the world by any metric that matters to sellers.
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 are included in the next batch feed, typically within 60 to 120 seconds.
Which repricing speed tier do you actually need?
Not every listing you're competing on warrants Overdrive. The right choice depends on listing characteristics and strategy.
Use Overdrive for:
- Competitive listings where Buy Box ownership changes frequently throughout the day
- Products where even a 60-second delay means missing a Buy Box window
- Listings with multiple competitive sellers actively repricing against each other
For these SKUs, the difference between sub-2-second and 60-to-120-second response time translates directly into measurable time in the Buy Box.
Standard bulk repricing works well for:
- Large catalogs where the majority of listings see infrequent competitive activity
- Products with stable pricing environments where a 60-second response cycle is more than sufficient
- Situations where your strategy calls for deliberate, less frequent price changes rather than continuous reaction
Utilizing Overdrive on your most competitive listings gives them all room to operate at full speed without competing against each other for capacity.
The ideal setup: Identify your 50 to 500 highest-churn listings, the ones where Buy Box position changes hands regularly, and put those on Overdrive. Let bulk feeds handle the rest of the catalog efficiently.
Overdrive Pro can automate this process for you by selecting daily top sellers or using a custom filter to match any conditions that are meaningful to you. That way your most important listings are always in the fast lane without having to manually update the selection.
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 your 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 skeptical of sub-second claims that don't define their metrics.
- Press every repricer on the five audit questions above before accepting a speed claim at face value.
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?
We studied this at length and found 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 few 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. Increasing the maximum number of Overdrive listings would create scenarios where Overdrive is actually slower than using bulk feeds.
Can native marketplace repricers go faster?
No, Amazon "Automate Pricing" tool in Seller Central and Walmart's Repricer in Seller Center 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 those 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. ↩

