Why price update speed matters for Featured Offer eligibility
Amazon's Featured Offer (formerly the Buy Box) sits at the top of every product detail page. According to the Amazon Selling Partner Blog (April 2026), the offers displayed there reflect a combination of price, condition, shipping speed, free-shipping threshold, and other attributes. The algorithm doesn't pick a winner once and leave it. It rotates and re-evaluates continuously as competitive conditions shift.
That creates a timing problem most sellers misunderstand. There are actually two separate latencies at play:
- Submission latency: The delay between when your repricer decides to change a price and when that change clears Amazon's API, gets processed, and is indexed as a live offer signal.
- Algorithmic re-evaluation latency: Once your new price is live in Amazon's catalog, how quickly the Featured Offer rotation considers it.
The second is often near-instant once data is live. The first can take anywhere from a few seconds to a few minutes depending on your integration method, queue depth, and API rate limits. Your repricing strategy needs to account for both. Getting only one right still costs you Featured Offer share.
One more constraint: Featured Offer eligibility can be revoked entirely if you're out of stock, if your price is too high relative to Amazon's reference points, or if it's too low and triggers a suspected pricing error review (Amazon Selling Partner Blog, April 2026). Speed is irrelevant if your offer isn't eligible in the first place.
Target cadences by competitive scenario
There's no official Amazon threshold that says "update every X seconds to win." What exists instead is a practical relationship: the faster competitors move their prices, the faster your repricer needs to detect the change, decide on a response, submit it, and have it indexed.
High-competition listings (multiple active FBA sellers, frequent price changes, thin margins): Target a full monitor-decide-submit cycle of 10 to 30 seconds. At this cadence, you're responding to competitor moves before Featured Offer rotation cycles past your stale price. The risk here is margin erosion if your repricer responds to every micro-move. Mitigate that by requiring a minimum price delta before triggering an update (more on this below).
Medium-competition listings (two to five active sellers, moderate price volatility): A 30 to 120 second cadence is practical and sufficient. Use hard min/max price guardrails and margin floor rules. Faster than this rarely produces measurable Featured Offer share gains at this competition level.
Low-competition or private-label listings: Update every two to five minutes. At low competition levels, aggressive update frequency introduces more margin risk than it resolves. The priority here is protecting price integrity, not reaction speed.
A practical decision rule for assigning a cadence class to an ASIN: look at the number of active competing offers, the historical Featured Offer rotation volatility for that ASIN, and how frequently competitors change their landed price. Those three signals tell you which bucket a listing belongs in.
Informed Repricer's instant repricing engine is built specifically for high-competition scenarios, detecting competitor price changes and submitting responses in seconds while keeping user-defined margin floors active throughout the cycle.
How to measure whether your cadence is working
Amazon doesn't publish a Featured Offer share metric in real-time. Your repricing dashboards also lag behind live decisioning, sometimes by 15 to 60 minutes. That means you can't evaluate cadence effectiveness by glancing at a dashboard right after a price change.
Run a structured test instead:
- Select a set of comparable ASINs and split them into cadence buckets (e.g., 15-second, 60-second, 5-minute update cycles).
- Hold all other variables constant: price strategy, min/max bounds, fulfillment method.
- Run each bucket for 7 to 14 days and track Featured Offer share percentage, time-to-return to Featured Offer after a competitor undercut, and conversion rate per session.
- Compare outcomes across buckets.
The key metric is time-to-return: how many minutes elapse between a competitor undercutting your price and your offer reclaiming the Featured Offer position. A faster cadence should compress that window. If it doesn't, the bottleneck is more likely API processing lag or offer eligibility rather than your polling interval.
Trade-offs: margin risk, API rate limits, and inventory sync
Faster repricing is only beneficial inside guardrails. Without minimum margin floors, a 10-second cadence in a competitive category can trigger a race-to-the-bottom spiral where multiple repricers push prices down in response to each other, often within seconds, until everyone is near cost.
The API constraint is equally concrete. Amazon's SP-API Listings Items API limits patchListingsItem (the operation used to update a listing's price) to 5 requests per second per account-application pair, with a burst capacity of 500. Exceeding that rate returns HTTP 429 errors. The x-amzn-RateLimit-Limit response header specifies the applied limit per account-application pair when available (Amazon Developer Docs). A repricer that hammers the API without respecting these limits will get throttled, ironically making its effective update speed slower than a properly queued system running at a lower frequency.
Inventory sync is the third constraint. An offer with zero available inventory is ineligible for the Featured Offer entirely, regardless of price. If your repricing system operates on stale inventory data, you can submit the perfect price at the perfect moment and still not win the Featured Offer because Amazon sees your item as out of stock. Inventory correctness and repricing speed must be synchronized.
Implementation: event-driven updates and throttling
The most efficient repricing architecture is event-driven rather than time-driven. Instead of submitting a price update every N seconds unconditionally, submit only when a competitor's landed price crosses your decision band. This approach conserves API quota and avoids unnecessary catalog churn.
Pair that with a delta threshold: only trigger a submission if the required price change exceeds a defined minimum (for example, $0.02 or 0.5% of current price). Small movements below the threshold don't justify a submission and won't meaningfully change Featured Offer eligibility.
An example rule stack for a high-competition ASIN:
- Monitor competitor prices every 10 seconds.
- Trigger update only if the new target price differs from current submitted price by more than $0.05.
- Submit via
patchListingsItem, respect the 5 rps limit, queue excess changes. - On HTTP 429, back off with exponential retry starting at 1 second.
- Never submit a price below the margin floor (cost + target margin %).
For medium and low-competition ASINs, the same logic applies with longer polling intervals and wider delta thresholds.
Starting defaults and pre-launch checklist
Use these presets as a starting point, then adjust based on your test results:
| Competition class | Polling interval | Delta threshold | Min/max guardrails |
|---|---|---|---|
| High | 10-30 seconds | $0.02-$0.05 | Required |
| Medium | 30-120 seconds | $0.05-$0.10 | Required |
| Low / private-label | 2-5 minutes | $0.10+ | Required |
Before going live, confirm all five conditions are in order:
- Cadence matches your ASIN's competition class.
- Decision band and delta threshold are configured to prevent noise-triggered submissions.
- Margin floors are set and enforced for every SKU.
- Inventory data feeding your repricer is current (confirm sync frequency with your inventory source).
- A monitoring process is in place to track Featured Offer share recovery time after competitor price events, using 7-day rolling windows rather than real-time snapshots.
Speed alone won't win the Featured Offer. Speed inside a well-configured rule stack, with clean inventory data and API-compliant submission handling, will.