Standard Amazon product page scraping tools focus entirely on the buy-box winner. While the buy box captures the vast majority of sales, it hides a critical layer of marketplace intelligence. On high-volume listings, dozens of third-party merchants compete on price, fulfillment methods, and shipping speeds behind the "See All Buying Options" button.
To monitor actual price elasticity, audit unauthorized resellers, or build dynamic repricing software, you need access to the complete order book on a listing. Extracting this data at scale requires scraping the Amazon All-Offers-Display (AOD) panel.
The Amazon Offers Scraper (All Offers Display) targets this specific interface. Instead of grabbing only the pinned product details, it extracts every active offer for one or more ASINs, including granular seller ratings, condition notes, and delivery promises.
Why standard product page scraping misses the full market picture
When scraping a standard product detail page (/dp/{ASIN}), you only receive the data for the current buy-box winner. This creates several blind spots for inventory analysts and brand protection managers:
- Hidden Price Spreads: A product might have a buy-box price of $29.99, but five other sellers might be offering the same item new for $24.99 with longer shipping delays, or used for $18.00.
- Reseller Identity Leakage: Unauthorized grey-market sellers often price their inventory just slightly above or below the buy box to avoid detection while still capturing secondary sales.
- Fulfillment Disparities: The buy box might be held by a merchant using Fulfilled by Merchant (FBM) shipping, while Fulfilled by Amazon (FBA) inventory sits lower in the offer queue.
By targeting the AOD panel, this scraper bypasses the single-seller view. It extracts structured records for every merchant listing the item, mapped to explicit data fields like isBuyBoxWinner, fulfillmentType, and shippingPrice.
Managing destination-specific shipping rates and inventory
One of the largest hurdles in ecommerce data collection is that Amazon dynamically changes visible offers and shipping costs based on the viewer's location. If you scrape a US listing from a European IP address, you will see a restricted set of sellers who ship internationally, paired with inflated shipping fees.
To get accurate localized data, you must pass destination parameters to the scraper. The input schema supports this through two key fields:
-
deliveryCountry: A 2-letter country code (such asUS,GB, orDE) that sets the target marketplace and filters out sellers who do not ship to that region. -
postalCode: A specific zip or postal code (like10001) to force Amazon to calculate exact delivery estimates and localized shipping fees.
When these fields are configured, the scraper returns exact delivery promises in the deliveryEstimate field and shipping costs in the shippingPrice object.
Here is an example input configuration targeting new offers on specific ASINs for a Manhattan-based delivery address:
{
"asins": ["B0DXXYS4BJ", "B0DCH8VDXF"],
"conditions": "NEW",
"deliveryCountry": "US",
"postalCode": "10001",
"maxOffersPerProduct": 20
}
Isolating conditions and merchant fulfillment types
Amazon categorizes alternative offers into four distinct top-level condition buckets: New, Used, Collectible, and Renewed.
When configuring the conditions input, the scraper maps directly to these buckets. If you set conditions to USED, the scraper will target the Used panel and ignore Collectible or Renewed items. This strict mapping prevents data pollution in your repricing database. If you require every single available offer regardless of state, setting the parameter to ALL extracts all active buckets.
Furthermore, the scraper parses the complex "Ships from" and "Sold by" DOM elements to output a clean fulfillmentType string. This field is classified into three distinct values:
-
FBA(Fulfilled by Amazon): The item is stored and shipped by Amazon, but sold by a third-party merchant. -
AMAZON: The item is both sold and shipped directly by Amazon. -
FBM(Fulfilled by Merchant): The third-party merchant handles their own logistics and shipping.
If the seller-shipper combination is highly unusual or ambiguous, the scraper omits the field entirely rather than guessing, preserving data integrity.
Handling scrapability failures with explicit status records
In web scraping, a missing result is ambiguous. Did the product actually have zero alternative offers, or did the scraper hit a CAPTCHA, a rate limit, or a 504 error?
To solve this, when a page cannot be successfully parsed as a standard offer list, the actor does not simply return an empty dataset. Instead, it generates a structured status record containing a page.classification field. This classification will flag the specific failure mode, such as NOT_FOUND, INVALID_ASIN, CAPTCHA, RATE_LIMITED, or NO_OFFERS. Downstream data pipelines can easily ingest these status records to trigger retries or log catalog issues.
Step-by-step implementation
To extract alternative offer data using this scraper on the Apify platform, follow these steps:
- Gather your target identifiers: Collect the list of ASINs or complete product URLs you need to monitor.
-
Define your location and filtering rules: Determine if you need to restrict results to a specific condition (like
NEW) or a specific delivery location to reveal accurate shipping costs. -
Configure the input JSON: Write your input payload, utilizing the
maxOffersPerProductparameter to cap your results and control processing depth. - Execute the run: Start the actor on the Apify platform.
- Consume the dataset: Download the resulting JSON dataset containing the structured offer records.
Analyzing the transactional costs of running the scraper
Using this scraper on the Apify platform incurs predictable event-based costs, alongside standard platform usage. Every run is billed under a pay-per-event model with two primary charges:
- Actor Start: A flat price of $0.005 per GB of memory allocated to the run, charged when the run initializes.
- Dataset Results: Each successfully scraped offer record written to the default dataset is charged as a "result" event. The base price is $0.005 per result.
This result fee scales down automatically based on your Apify account discount tier:
- FREE / BRONZE: $0.005 / $0.00433 per result
- SILVER: $0.00367 per result
- GOLD / PLATINUM / DIAMOND: $0.003 per result
The final cost of a run depends directly on the number of ASINs processed, the number of active offers found per ASIN, and the maxOffersPerProduct limit you define. Platform usage consumed during the run is billed separately at your specific Apify plan rates.
Structural limitations of the All-Offers-Display scraper
While this tool is highly optimized for retrieving complete seller lists, it has a built-in architectural limitation regarding extremely long seller lists.
The scraper is designed to expand Amazon's client-side toggle ("See N more options") to extract all offers rendered in the initial page session. However, on listings with a massive number of competing merchants (e.g., popular books with 100+ third-party offers), Amazon splits the list across multiple server-side pages. This scraper does not perform subsequent page-2 server requests. To detect if you are missing offers due to this limit, always inspect the page.moreOffersAvailable boolean field returned in the output metadata. If it is true, it indicates that additional pages of offers exist on Amazon's servers which were not retrieved.
Runs in this article used Amazon Offers Scraper (All Offers Display). Its README is the reference for input fields and output structure; this post is only one path through them.
Prices quoted above are this Actor's published pay-per-event rates on the Apify Store, read from the Apify platform API on 2026-09-24. Check the Actor page for the current rates.
Top comments (0)