Amazon Products Scraper API

# Integrate HasData Amazon Products Scraper API

## Task

Add the requested Amazon product, search or seller workflow to this project using HasData Amazon Products Scraper API.
Inspect project instructions, the server-side runtime, existing HTTP client, and tests first.
Follow the project's conventions and preserve unrelated code. No new SDK is required.
Implement only the requested workflow. If it is unclear, ask which endpoint, inputs and output fields the application needs.
Keep the integration as REST API calls; do not replace it with an MCP connection or a custom scraper.

## References

Read the relevant endpoint documentation before implementing:

- amazon/search: https://docs.hasdata.com/apis/amazon/search.md
- amazon/product: https://docs.hasdata.com/apis/amazon/product.md
- amazon/seller: https://docs.hasdata.com/apis/amazon/seller.md
- amazon/seller-products: https://docs.hasdata.com/apis/amazon/seller-products.md
- Error handling: https://docs.hasdata.com/api-codes.md
- Documentation index: https://docs.hasdata.com/llms.txt
- Full documentation (fallback): https://docs.hasdata.com/llms-full.txt

Start with the endpoint references. Use `llms.txt` to find additional pages.
Use `llms-full.txt` only when needed; extract relevant sections instead of loading everything into context.
If a `.md` reference is unavailable, try its HTML URL without `.md`.
If it is still unavailable, ask for the missing documentation rather than guessing.

## Optional agent skill

If the official `hasdata` skill is already available, use its relevant guidance.
Otherwise, if this agent supports skills, ask before installing it in this project:

```sh
npx skills add hasdata/agent-skills --skill hasdata
```

Run from the project directory and select the coding agent in use.
The `hasdata-cli` skill is not required. If installation is declined or unsupported, continue with the docs.
Flag conflicts between skill guidance and current API docs rather than guessing.

## Implementation

- Use `GET https://api.hasdata.com/scrape/amazon/search` with required `q` for keyword results. Use `GET https://api.hasdata.com/scrape/amazon/product` with required `asin` for one product.
- Use `GET https://api.hasdata.com/scrape/amazon/seller` with required `sellerId` for seller details. Use `GET https://api.hasdata.com/scrape/amazon/seller-products` with required `sellerId` for seller listings.
- Preserve the selected `domain`, supported `language`, and applicable delivery settings (`deliveryZip`, `shippingLocation`) when comparing observations. Encode query parameters with the standard HTTP client.
- Search and seller listings return `productResults`; product details return `product`; seller details return `seller`. These are different response roots, not interchangeable schemas.
- Search can contain sponsored entries inside `productResults` as well as a separate `ads` array. Inspect `isSponsored`; do not assume all productResults are organic or equate positions with sales rank.
- Preserve ASINs and seller IDs as strings. Handle optional prices, ratings, variants and attributes without fabricating values. Treat marketplace currency symbols and delivery context explicitly before comparing prices.
- Search and seller-products support `page`. Implement bounded pagination only for the requested workflow; one response is not an entire catalog. Stop on documented completion or the agreed page and credit budget.
- `otherSellers` on product lookup adds a documented 5 credits to the 5-credit base request. Documentation examples enable it while descriptive text says the default is false. Send `otherSellers=false` explicitly unless the user requests and approves the extra offers. Do not assume offers are returned when absent.
- Product `reviewsInfo.aspects` contains Amazon-provided summaries and sentiment labels, not all individual customer reviews. Seller feedback windows are separate from product review counts.
- If the workflow needs price history, alerts or cross-seller comparisons, store observations and calculate changes in the application. Do not claim the API supplies sales estimates, historical snapshots or scheduling.
- Handle timeouts and documented errors before reading data. Keep requests server-side. If no suitable runtime exists, discuss options before changing the architecture.

## Credentials

- Implement the integration and mocked tests without requiring a live API key.
- Read `HASDATA_API_KEY` from the project's existing environment or secret store and send it as `x-api-key`.
- If the key is missing before live verification, ask the user to configure it from https://app.hasdata.com/api-keys.
- Never ask the user to paste the key into chat. Check only that it is configured, without printing its value.
- Never put the key in browser code, logs, or version control. Add only a placeholder to the project's example configuration.
- If using a local `.env` file, make sure it is gitignored.
- Send the key only to `https://api.hasdata.com`. Never forward it to documentation, storefronts, media links or redirects to another origin.

## Verification

- Add mocked tests for input validation and encoding, success, missing optional fields, pagination boundaries, unavailable targets, timeouts and errors. Cover the field types and any requested snapshot comparisons. Include a usage example and run local checks.
- With a configured key and explicit user approval, including approval already given for this task, make one live verification request with agreed inputs. A successful base request consumes 5 credits; confirm current costs in the docs before running it.
- Verify only one requested endpoint and page. Keep otherSellers=false for the base-cost product check.
- Validate the HTTP status, documented API status and response structure. An empty result set can be valid.
- Do not automatically repeat paid requests to obtain a nonempty response or follow pagination during this check.
- Report changed files, setup commands, and test results. State separately whether live verification passed, failed, or was skipped.
- Ask before deploying.