Amazon is one of the highest-value ecommerce datasets on the web because it combines product discovery, pricing, reviews, seller activity, promotions, and category structure in one marketplace.
The problem is that these workflows usually fragment quickly. Search pages behave differently from product detail pages. Reviews have different pagination than seller data. Category browsing has its own structure. And teams often end up building separate scripts for each part of the journey instead of one clean integration.
This guide is about the Amazon endpoint surface that solves that problem. It keeps the request model simple while still exposing the parts of Amazon most teams care about first: search, product details, reviews, seller intelligence, deals, identifier conversion, and category browsing.
Why Amazon Is Hard to Scrape Reliably
Before you look at the endpoints, it helps to understand why direct Amazon scraping becomes messy so fast:
What Makes Amazon Workflows Messy
- ❌ Different page types have different structures: search pages, PDPs, reviews, seller storefronts, deal pages, and category pages all behave differently.
- ❌ One workflow often requires several page types: you search, shortlist ASINs, enrich PDPs, then open reviews or seller data next.
- ❌ Response shapes are not uniform: some endpoints return one object, others return arrays nested under different keys, and the pagination fields are not always identical.
- ❌ Teams usually care about business workflows, not pages: pricing intelligence, review mining, assortment tracking, seller research, and deals monitoring span several endpoints.
- ❌ Maintaining all of this yourself is expensive: even if one page is easy to parse, the full system is not.
The Core Request Shape
The Amazon API uses one body shape across the supported endpoints:
curl -X POST https://scrapingbot.io/api/v1/amazon \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"endpoint": "/search",
"params": {
"query": "wireless earbuds",
"country": "US"
}
}'
The only thing you usually change is the endpoint path and the params object. That means you can keep one client integration while switching from discovery endpoints to PDP endpoints, reviews, sellers, or deals.
Inputs you will reuse a lot
- query: best for catalog discovery by keyword.
- asin: best for product detail, reviews, offers, and identifier conversion.
- seller_id: best for seller profile, seller reviews, and seller products.
- category_id: best for browsing a known category with product collections.
- deal_id or promo_code: best for discount and promotions workflows.
- country and language: useful when you need marketplace-specific behavior and localization.
14 Amazon Endpoints That Cover Most Workflows
The public Amazon surface now focuses on the endpoints that returned usable data in testing and map well to real ecommerce workflows. The sections below are organized the way teams usually think about the problem: discovery first, enrichment second, then reviews, sellers, promotions, and category context.
1. Search the Amazon Catalog
/search is usually the first call. It gives you the marketplace view for a keyword and is the fastest way to get candidate ASINs for competitor research, assortment tracking, merchandising analysis, and price monitoring.
{
"endpoint": "/search",
"params": {
"query": "protein powder",
"country": "US",
"language": "en_US",
"page": "1",
"sort_by": "RELEVANCE"
}
}
Good use cases
- Discover competitors for a product category.
- Track which products surface for important keywords.
- Build a shortlist of ASINs to enrich later with PDP or reviews data.
2. Browse Products by Category
/products-by-category is useful when keyword search is too noisy and you already know the browse node or category area you care about. This is often a better choice for recurring catalog monitoring because it is closer to how merchandising teams segment the marketplace.
{
"endpoint": "/products-by-category",
"params": {
"category_id": "172282",
"country": "US",
"page": "1"
}
}
Use this when you want a cleaner group of products than a keyword search usually gives you.
3. Open the Product Detail Page
Once you have an ASIN, /product-details gives you the product page state you usually need next: title, brand, price context, attributes, media, marketplace signals, and related metadata.
{
"endpoint": "/product-details",
"params": {
"asin": "B07ZPKN6YR",
"country": "US"
}
}
What teams usually extract here
- Titles, brand names, and product attributes.
- Current pricing and pricing context.
- Media and visual merchandising details.
- Marketplace details you want to store before joining to other systems.
4. Pull Product Offers
/product-offers is the right choice when you care less about the marketing copy on the PDP and more about who is selling the product, how it is being fulfilled, and what the offer mix looks like.
{
"endpoint": "/product-offers",
"params": {
"asin": "B07ZPKN6YR",
"country": "US"
}
}
This is a strong companion to /product-details for pricing and seller intelligence workflows.
5. Extract Product Reviews
/product-reviews is the core endpoint for voice-of-customer analysis. If you are mining sentiment, complaint clusters, quality issues, or feature requests, this is one of the highest-value Amazon datasets you can store.
Review nuance worth knowing
Review endpoints often have the most provider-specific quirks. In our live testing, /product-reviews worked without a cookie for at least some ASINs, so the field is available as an optional passthrough rather than being forced into the main request path.
{
"endpoint": "/product-reviews",
"params": {
"asin": "B07ZPKN6YR",
"country": "US",
"sort_by": "TOP_REVIEWS",
"page": "1"
}
}
Common ways teams use reviews
- Measure satisfaction trends over time.
- Find recurring complaints or defect patterns.
- Compare the language customers use for competing products.
- Turn review text into feature, sentiment, or topic datasets.
6. Pull Top Product Reviews
/top-product-reviews is a narrower review surface that can be useful when you want a smaller, high-signal subset before you decide whether to collect a fuller review history.
{
"endpoint": "/top-product-reviews",
"params": {
"asin": "B07ZPKN6YR",
"country": "US"
}
}
7. Resolve the Seller Profile
Amazon monitoring often becomes seller monitoring very quickly. /seller-profile is where that workflow usually begins.
{
"endpoint": "/seller-profile",
"params": {
"seller_id": "A2L77EE7U53NWQ",
"country": "US"
}
}
The seller profile response is useful when you want storefront metadata, business identity information, seller context, and the starting point for more detailed seller workflows.
8. Pull Seller Reviews
/seller-reviews gives you the feedback side of seller monitoring. This is helpful when you want to compare marketplace reputation, shipping complaints, or customer trust signals across sellers.
{
"endpoint": "/seller-reviews",
"params": {
"seller_id": "A2L77EE7U53NWQ",
"country": "US",
"page": "1"
}
}
9. Enumerate Seller Products
/seller-products is the endpoint to use when you need the seller's current product catalog. This is especially useful for marketplace intelligence, policy checks, and catalog comparison work.
{
"endpoint": "/seller-products",
"params": {
"seller_id": "A2L77EE7U53NWQ",
"country": "US",
"page": "1"
}
}
Typical seller workflow
- Resolve the storefront with
/seller-profile. - Check seller reputation with
/seller-reviews. - Enumerate current inventory with
/seller-products.
10. Monitor Current Deals
/deals-v2 is the starting point for promotions and discount monitoring. It helps when you want a broader view of active deal activity rather than a single product page.
{
"endpoint": "/deals-v2",
"params": {
"country": "US",
"page": "1",
"deal_type": "LIGHTNING_DEAL"
}
}
11. Pull Products Inside a Deal
/deal-products lets you move from the deal listing to the products attached to that deal. This is the endpoint that turns a promotions feed into something you can actually analyze product-by-product.
{
"endpoint": "/deal-products",
"params": {
"deal_id": "deal-123",
"country": "US"
}
}
12. Inspect Promo Code Details
/promo-code-details is useful when promo pages matter to your workflow. You can resolve them by promo code or URL and inspect the discount metadata and attached products where available.
{
"endpoint": "/promo-code-details",
"params": {
"promo_code": "SAVE20",
"country": "US"
}
}
13. Convert ASIN to GTIN
/asin-to-gtin is useful when Amazon is only one part of your pipeline and you need to connect its identifiers to broader catalog systems, warehouse data, or downstream enrichment jobs.
{
"endpoint": "/asin-to-gtin",
"params": {
"asin": "B07ZPKN6YR",
"country": "US"
}
}
14. Enumerate Category Trees
/product-category-list helps when you need the browse structure itself, not just product collections. This is useful if you are mapping categories, building navigation-aware workflows, or exploring where products sit inside the marketplace.
{
"endpoint": "/product-category-list",
"params": {
"country": "US",
"language": "en_US"
}
}
What Can You Actually Build With This?
The biggest mistake people make is thinking in terms of endpoints instead of workflows. The better question is what business problem you are trying to solve, then which endpoint sequence supports that.
Competitive Pricing Monitor
Start with /search or /products-by-category to discover the relevant ASINs, then use /product-details and /product-offers to capture the fields that actually change over time.
// Example flow
1. /search -> shortlist ASINs
2. /product-details -> product-level context
3. /product-offers -> offer and seller state
4. store snapshots daily for diffing
Review Intelligence Pipeline
Use /product-reviews or /top-product-reviews when you want voice-of-customer insights, product feedback clusters, or competitor comparison data. This is a strong fit for sentiment analysis, support escalation, QA analysis, and PM research.
Seller Monitoring Dashboard
Use the seller endpoints together when you want to understand who is active in a market, how their storefront changes over time, and whether seller feedback or product mix shifts in a way that matters to your business.
Deals and Promotion Tracking
/deals-v2, /deal-products, and /promo-code-details are useful when discounts matter more than baseline product pages. This is especially relevant for merchandising teams, resellers, and promotional intelligence tooling.
Response Shapes and Pagination Notes
One important implementation detail: Amazon responses are not perfectly uniform across the entire surface. That is normal. You should design your ingestion layer around endpoint-specific parsers or schema variants rather than one giant universal response contract.
Useful mental model
- Search and category endpoints: usually return product collections plus counts or pagination fields.
- Product detail and identifier endpoints: usually return a single object or a single main object plus supporting fields.
- Review endpoints: usually return ratings context and one or more review collections.
- Seller endpoints: often return storefront metadata, seller stats, feedback rows, or seller-linked products.
- Deals endpoints: usually return lists of deals or deal-linked products.
The practical takeaway is simple: keep your endpoint metadata close to your parser. It is a cleaner architecture than forcing everything into one giant normalization step too early.
Practical Tips Before You Scale This Up
Smart moves
- Start broad, then enrich: use search or category endpoints to shortlist targets before you start hitting PDP, reviews, or seller calls.
- Store both raw and normalized data: raw payloads are useful when you need to revisit fields later without re-requesting everything.
- Think in workflows, not single requests: pricing, reviews, seller monitoring, and deals are all multi-step paths.
- Use the playground first: confirm the shape you care about before writing production ingestion logic.
Mistakes to avoid
- Do not assume every endpoint returns the same array key.
- Do not design your system around just one Amazon page type. Most real workflows span several.
- Do not wait until production to test example payloads. Validate the shape early in the playground.
- Do not build category and seller workflows as an afterthought. They often become core once the project matures.
How to Get Started
If you are evaluating the Amazon API for the first time, the fastest path usually looks like this:
Quick Start
- Create your ScrapingBot account and get your API key.
- Open the Amazon playground and load an example request.
- Start with
/searchor/product-detailsdepending on whether you have a keyword or ASIN. - Inspect the returned JSON and identify the exact fields your workflow needs.
- Add a second endpoint only after the first one is validated.
- Once the flow proves out, move it into your application or recurring jobs.
Closing Thoughts
Amazon data is powerful because it sits at the intersection of discovery, product enrichment, customer feedback, seller behavior, and promotions. But that same breadth is why direct scraping turns into an engineering project so quickly.
The most effective way to think about this API is not as a bag of unrelated endpoints. Think of it as a workflow surface for ecommerce research and monitoring. Search finds opportunities. Product endpoints enrich them. Reviews explain customer perception. Seller endpoints expose marketplace dynamics. Deals endpoints capture commercial activity.
If you start with the use case first, then map the endpoint sequence behind it, the integration tends to stay clean.
Try the Amazon playground
The dashboard ships with example requests for search, product details, reviews, sellers, deals, identifier conversion, and category browsing so you can validate the flow quickly.