Amazon Scraper API vs Proxy: Choose a Product Data Source
Compare seller APIs, licensed Amazon product data and proxy page checks by record, access scope and reuse rights.
Read guideVerify a storefront’s language, currency, and catalog against fixed browser, cookie, and route inputs; find which input changed when a field fails.

Test an owned storefront by holding account, cookie, browser, and page inputs constant while changing the regional proxy route. Accept the result only when the page shows the expected language, currency, catalog, or delivery fields. An observed Internet Protocol (IP) address or browser locale alone does not prove which storefront variant the site served.
Audience: Developers or quality engineers who can define a storefront test case and inspect its application-owned fields.
Warning: A proxy context sends its configured credentials to the proxy endpoint. Use only an authorized test environment and endpoint, load credentials from a secret store, and keep them out of browser logs and reports. Close the context after the scenario; rotate credentials if they appear in captured output.
Write the expected result before opening the browser. Name the product or catalog slice, entry URL, account state, consent state, selected store or delivery address, expected language, currency, and the field that proves the page is the intended variant.
Use a test account and an address authorized for quality checks. Do not copy a real customer's cookies, delivery details, or account state into the test.
| Example scenario | Inputs to hold or set | Accepted page evidence |
|---|---|---|
| French product page | fr-FR, selected market, test cookie state, fixed product |
French language marker, product identifier, displayed currency and final path |
| Canadian price display | en-CA, approved route, fixed product code and delivery state |
Product code, currency code, displayed amount, selected market and final path |
| Regional delivery option | Test account, approved address, fixed product and route | Expected delivery method and the store or market marker |
These rows describe test designs, not observed storefront behavior. Replace each expected field with a marker supplied by the owned site. A formatted price alone does not prove that the correct price source, tax rule, or catalog was selected.
Playwright's BrowserContext creates an isolated browser session. Its emulation settings can set locale and time zone; the context can also use a proxy route.
The locale option affects browser language signals, including navigator.language and the Accept-Language request header. That header expresses a language preference; the server may select another language based on an explicit choice, account, URL, or site rules. See the Accept-Language reference before overriding it manually.
// Not runnable: add this to a test that creates and closes the browser context.
const context = await browser.newContext({
locale: 'fr-FR',
timezoneId: 'Europe/Paris',
proxy: {
server: process.env.PROXY_SERVER,
username: process.env.PROXY_USERNAME,
password: process.env.PROXY_PASSWORD,
},
});
browser must be an already launched Playwright browser. Load proxy credentials from a secret store or protected local environment. Do not print them, include them in URLs, or add them to source control. If the test needs a market cookie, seed the same approved test state into each scenario. Cookie domain and path determine where a browser sends that cookie; the cookie guide explains those rules.
Do not set Accept-Language independently when the test is measuring Playwright's locale behavior. If the application has a header override, test that as a separate scenario. Intl.NumberFormat formats a number for a locale; it does not verify the catalog, tax basis, or server-side price source. The number-format reference describes its output behavior.
Close the context after each scenario so storage from one market does not carry into the next. If the site uses a login or cart across multiple pages, keep the same authorized context for that sequence and label the test account; do not reuse it for a separate market case.
Keep one row per planned scenario, including failures and cells that were not run. The values below are schema placeholders, not a test result:
{
"scenario": "<SCENARIO_ID>",
"requested_route": "<COUNTRY_OR_NOT_REQUIRED>",
"observed_exit": "<COUNTRY_OR_UNKNOWN>",
"browser_locale": "<LOCALE_TAG>",
"time_zone": "<TIME_ZONE_ID>",
"cookie_state": "<CONTROLLED_STATE_LABEL>",
"product_id": "<SITE_PRODUCT_ID>",
"final_url": "<REDACTED_FINAL_URL>",
"language_ok": "<BOOLEAN_RESULT>",
"currency_ok": "<BOOLEAN_RESULT>",
"catalog_ok": "<BOOLEAN_RESULT>",
"delivery_ok": "<DELIVERY_RESULT>",
"outcome": "<OBSERVATION_OUTCOME>",
"first_failure": "<ROUTE_LANGUAGE_COOKIE_CATALOG_CURRENCY_DELIVERY_REDIRECT_OR_NONE>"
}
Replace each quoted BOOLEAN_RESULT placeholder with JSON true or false. Use a boolean or "not_tested" for DELIVERY_RESULT, and one of the outcome labels below for OBSERVATION_OUTCOME. Keep untested fields distinct from failed checks.
Do not store raw page bodies, customer data, passwords, or session tokens in a shared report. Keep exact URLs only in access-controlled evidence when they contain non-public query values. Record the exit-lookup source and check time when route country or city is relevant; an IP database observation does not prove the storefront's market decision.
| Outcome | Meaning | Follow-up |
|---|---|---|
| Accepted | Every required site field matches the scenario | Keep the controlled inputs with the result |
| Rejected | A required field mismatches | Record the first failing field and change one input |
| Inconclusive | Consent, authentication, challenge, or unavailable content prevents the check | Resolve the authorized test setup before interpreting locale or route |
| Untested | The scenario did not run before its planned end | Preserve the gap; do not count it as a pass or failure |
A matching exit addresses only the route check. A language header addresses only a browser preference. A formatted currency string addresses only what the page displayed. None proves that every visitor in a location sees the same catalog or price.
For a route mismatch, use the proxy geotargeting guide and proxy IP and browser diagnostics. Keep the conclusion tied to this account, page, route, and test time. Do not generalize one storefront check to a population or use it as proof of legal or tax compliance.
Scale your workflows with the tools you already use. Rotating or sticky sessions up to 72 hours.
Compare seller APIs, licensed Amazon product data and proxy page checks by record, access scope and reuse rights.
Read guideChoose the right anti-detect browser proxy guide, map the shared verification steps, and keep account access separate from the network route.
Read guideOur picks for market research: ProxyLane for small, intermittent projects, plus options for regional tracking, monthly collection and managed extraction.
Read guide