Competing for Featured Offer Using Expected Price (FOEP) 🏷️💰🎯

[MeenaAmz]

Building a repricing solution means responding to market changes, and knowing the expected price can unlock a competitive advantage. Featured Offer Expected Price (FOEP) is a computed listing price at or below which a seller's offer can expect to become the Featured Offer (this is the offer displayed with the "Add to Cart" button on the product detail page).

This guide covers how to integrate getFeaturedOfferExpectedPriceBatch into your pricing workflow, when to call it, and how to combine it with notifications for a complete repricing strategy. Use this when you are building or enhancing a repricing solution that targets Featured Offer placement.

Authored by: Meena P, Solutions Architect, Selling Partner Developer Services

Audience	Applicability
Sellers	Yes
Vendors	No
Solution Providers	Yes

---

Pricing signals at a glance

The following pricing signals are available

Signal	Type	What It Returns
getFeaturedOfferExpectedPriceBatch	Pull (on-demand)	Computed FOEP value for up to 40 SKUs
ANY_OFFER_CHANGED notification	Push (event-driven)	Fires when competing offers or the Featured Offer changes
PRICING_HEALTH notification	Push (event-driven)	Fires when an offer is disqualified from Featured Offer
getCompetitiveSummary	Pull (on-demand)	Competitive landscape data, reference prices, GVWP by location

---

How FOEP fits into a repricing workflow

FOEP is a pull-based pricing signal. You call getFeaturedOfferExpectedPriceBatch on demand, typically triggered by an ANY_OFFER_CHANGED or PRICING_HEALTH notification, and receive the computed price at or below which an offer can expect to become the Featured Offer.

Recommended pattern: Use ANY_OFFER_CHANGED or PRICING_HEALTH as a trigger → call getFeaturedOfferExpectedPriceBatch → evaluate the response → apply configured pricing rules → submit the price update via patchListingsItem.

---

Implementation steps

Step 1: Subscribe to notifications

ANY_OFFER_CHANGED

Set up ANY_OFFER_CHANGED subscriptions to get notified when the competitive landscape shifts for an ASIN you sell. Refer to Tutorial: Set up notifications for SQS setup.

Understanding OfferChangeTrigger in ANY_OFFER_CHANGED

When you receive an ANY_OFFER_CHANGED notification, the OfferChangeTrigger object in the payload tells you what changed and why the notification fired. The OfferChangeType field is key for deciding whether to call FOEP:

OfferChangeType	Description	Call FOEP?
Internal	The price of an offer on Amazon's retail website has changed (a change to one of the top 20 offers for the ASIN).	✅ Yes — competitive landscape shifted
Featured Offer	The Buy Box winner or Buy Box price has changed.	✅ Yes — directly relevant to Featured Offer competition
External	The CompetitivePriceThreshold in the Summary object has changed, triggered by a new offer from a non-Amazon retailer.	⚠️ Optional — may affect competitiveness thresholds

The OfferChangeTrigger also provides:

• MarketplaceId — the marketplace where the change occurred
• ASIN — the item that had the offer change (map this to your seller's SKU before calling FOEP)
• ItemCondition — the condition (New, Used, and so on) of the offer that changed
• TimeOfOfferChange — when the change occurred (ISO 8601)

Tip: Filter for OfferChangeType values Internal and Featured Offer to reduce unnecessary FOEP calls. These are the events most likely to affect your seller's Featured Offer eligibility. External changes may also warrant a FOEP call if you track competitiveness against non-Amazon retailers.

PRICING_HEALTH

PRICING_HEALTH fires when your offer loses Featured Offer eligibility due to an uncompetitive price. Treat this as an urgent signal to call FOEP and reprice immediately. While ANY_OFFER_CHANGED helps you stay ahead, PRICING_HEALTH helps you recover.

Step 2: Call getFeaturedOfferExpectedPriceBatch

Request FOEP for the seller's SKU(s):

POST /batches/products/pricing/2022-05-01/offer/featuredOfferExpectedPrice

{
  "requests": [
    {
      "marketplaceId": "ATVPDKIKX0DER",
      "sku": "MY_SKU",
      "method": "GET",
      "uri": "/products/pricing/2022-05-01/offer/featuredOfferExpectedPrice"
    }
  ]
}

Batch up to 40 SKUs per request.

Step 3: Evaluate resultStatus

The response indicates whether Amazon returned an FOEP value:

Result Status	Meaning
VALID_FOEP	Amazon returned a valid FOEP value. Proceed to price comparison.
NO_COMPETING_OFFER	No competing offers exist. The offer may already be eligible.
OFFER_NOT_ELIGIBLE	The offer does not qualify for Featured Offer. Check eligibility requirements.
OFFER_NOT_FOUND	The offer may be unbuyable or the seller is not qualified.
ASIN_NOT_ELIGIBLE	The ASIN cannot return an FOEP value.

Step 4: Compare FOEP to current price

Check if the current listing price is above the returned FOEP value. If it is, a price adjustment may improve Featured Offer eligibility.

Step 5: Validate before submitting

Call patchListingsItem with mode=VALIDATION_PREVIEW to preview any pricing issues before the actual submission.

Step 6: Apply pricing rules

Confirm the price change against your configured pricing rules (for example, minimum price thresholds, maximum discount limits). The seller retains final control over pricing decisions.

Step 7: Submit the price update

Call patchListingsItem to update the offer price. Inspect the response to confirm the submission is ACCEPTED. If not, correct validation issues and resubmit.

---

Alternative approaches: Using FOEP without notifications

If your application does not subscribe to ANY_OFFER_CHANGED or PRICING_HEALTH, you can still use FOEP effectively with a pull-based approach:

Option A: Periodic polling

• Call getFeaturedOfferExpectedPriceBatch on a scheduled cadence (for example, every 15–60 minutes) for your seller's active SKUs.
• Batch up to 40 SKUs per request to optimize API usage.
• Compare returned FOEP to current prices and submit updates as needed.

Option B: On new listing creation

• When a seller creates a new listing and wants to target the Featured Offer, call FOEP immediately to inform the initial price.

Option C: Combined with getCompetitiveSummary

• Use getCompetitiveSummary on a schedule to monitor the competitive landscape.
• When reference prices shift (for example, CompetitivePriceThreshold changes), call FOEP to determine the updated target.

⚠️ Note: The notification-based approach (Step 1 above) is recommended for integrations, it is more efficient and responsive than polling. Use these alternate flows when notification infrastructure is not feasible or as a backup option.

---

Best practices

• Batch your requests — Group up to 40 SKUs per call to minimize API usage and stay within rate limits.
• Use notifications as triggers — Do not poll FOEP excessively. Let ANY_OFFER_CHANGED or PRICING_HEALTH tell you when the competitive landscape has shifted or a disqualification occurred, then call FOEP.
• Combine with location targeting — For sellers fulfilling to specific regions, pass sampleLocation (postal code) in the request to get regionalized FOEP. Use getCompetitiveSummary first to identify high-traffic locations via GVWP.
• Use getCompetitiveSummary for additional context — Before or alongside your FOEP call, call getCompetitiveSummary to retrieve reference prices. This gives you a fuller picture of the competitive landscape so you can validate the FOEP target against external benchmarks and make more informed pricing decisions.
• Validate before submitting — Call patchListingsItem with mode=VALIDATION_PREVIEW to catch pricing policy violations before the actual submission.
• Implement retry logic — Use exponential backoff when you encounter throttling (HTTP 429) to maintain reliable repricing cadence without exceeding rate limits.

---

Common pitfalls

• No FOEP returned for eligible SKUs — If there are no competing offers shipping nationwide, Amazon may not return an FOEP value. This is expected behavior (NO_COMPETING_OFFER), not an error.
• Using FOEP as a guaranteed price — FOEP is a computed estimate. Featured Offer status depends on additional factors including fulfillment capabilities. Always verify calculated values before submitting price changes.
• Ignoring non-VALID statuses — Each resultStatus provides actionable information. Handle all five statuses in your workflow rather than discarding non-VALID_FOEP responses.

---

Related resources

• 📖 Product Pricing API v2022-05-01 Reference — Complete API reference for request/response schemas
• 📖 Price Adjustment Automation Workflows Guide — Notification-based pricing workflows for end-to-end automation
• 🌍 Integrating Location-Based Pricing Using Amazon SP-API — Advanced location-based FOEP use case with sampleLocation
• 📖 Notifications API Use Case Guide — Setting up SQS subscriptions for notifications
• 📖 Pricing errors validation - Preview any pricing issues before the actual submission

---

Content governance

Content Owner: Meena P.
Last Reviewed: August 30, 2026
Next Review Date: February 28, 2027

---

Feedback

Let us know what you think! 👇
React or reply below to share your feedback.

❤️ Like what you see?
👍 Excited to try it out?
🎉 Want to see more of this?

---

Keywords: #FOEP #FeaturedOffer #Pricing #Repricing #AnyOfferChanged #PricingHealth #BuyBox #SPAPINotifications #amazon-sp-api #optimization

---

Please note the publication date above. While we strive to keep our content current, the rapid evolution of this topic means some details may have changed since publication. For the most up-to-date information, we encourage readers to follow the announcements in SP-API developer documentation.