ParseShelf Amazon API Documentation.

Core job model

A ParseShelf job starts with a marketplace, input type, input value, mode and target count. The same contract works for Amazon search URLs, category URLs, product URLs and ASIN lists, so a developer can switch sources without rewriting downstream export logic.

The dashboard and API share the same job lifecycle. Operators can create and inspect jobs in the web product while engineers automate recurring runs with API keys.

Output contract

Completed jobs expose normalized rows with fields such as product_id, asin, title, brand, price, currency, rating, reviews_count, stock_status, category_path, images and product_url. The exact fields depend on what Amazon renders for a page, but exports keep a predictable schema.

Each export format is generated from the same normalized rows. JSONL is best for pipelines, CSV and XLSX are best for analysts, and Markdown is useful for internal reports.

Next steps

Start with the API overview if you need the complete endpoint map. Use the Python or JavaScript quickstart when you are wiring ParseShelf into a backend. Use the Google Sheets and Postman guides when the first user is an operator or analyst.

For SEO and research workflows, pair these docs with the public sample dataset and benchmark page so buyers can evaluate the data shape before signing up.

Evaluation and rollout notes

A useful Amazon data page should help a buyer decide what to do next, not only define a keyword. When evaluating this workflow, start from the business question: discover products, enrich ASINs, monitor competitors, audit a catalog, prepare a spreadsheet or feed an internal data pipeline. The right ParseShelf mode and export format depend on that question.

For early research, keep the first run small and easy to inspect. Use one keyword, one category, one competitor set or one ASIN list, then compare delivered rows against the fields your team actually needs. Price, currency, rating, review count, stock status, source URL and product URL are usually the minimum useful fields. Product details, bullets, variants, images and seller signals become important when the workflow moves from discovery to enrichment.

For production, treat every Amazon job as an auditable dataset. Store the job ID, input source, mode, run date and export format next to the downstream report. This makes it possible for developers and operators to debug the same result from the dashboard, the API status endpoint and the downloaded files.

When a page links to docs, examples, samples and pricing, the visitor can move from research to implementation without guessing which product surface to use. That path is important for both conversion and search intent satisfaction.

This is also how the page supports organic search quality. The content is tied to a concrete product workflow, includes examples, links to related resources and exposes the same schema that users see after signup. That creates a stronger page than a generic scraper keyword page with no data shape, no implementation detail and no clear next action.