Is kwery an Alternative to PriceAPI?
Yes. PriceAPI and kwery have substantial workload overlap and are legitimate alternatives for many multi-source marketplace-pricing workflows. Both provide structured marketplace and price-comparison data without requiring customers to operate every collector themselves, both cover sources such as Amazon, Google Shopping, Idealo and billiger.de, and both support GTIN-oriented workflows and programmatic integration.
The main difference is therefore not scraping versus API. It is which sources matter to the customer, how product identity is handled, how data quality becomes visible to the consuming system, how observations enter production, and how usage maps to an actual dataset.
Where they overlap
Where they diverge
Source priority
Wide long tail, DACH-leaning
Core marketplaces, DE/EU plus US and Asia
Product identity
Resolved in a separate step
Resolved inside the request
Data quality
Inferred from the payload
Data-health score per observation
Provenance
No comparable public model verified
Source, method and timestamp per record
Billing unit
Per request, page and parameter
Per complete SKU dataset
Source priority
PriceAPI
Wide long tail, DACH-leaning
kwery
Core marketplaces, DE/EU plus US and Asia
Product identity
PriceAPI
Resolved in a separate step
kwery
Resolved inside the request
Data quality
PriceAPI
Inferred from the payload
kwery
Data-health score per observation
Provenance
PriceAPI
No comparable public model verified
kwery
Source, method and timestamp per record
Billing unit
PriceAPI
Per request, page and parameter
kwery
Per complete SKU dataset
Different Coverage Priorities
The two source libraries are built around different priorities. PriceAPI's portfolio leans into a wide long tail of retailer, comparison and specialist sources, including several DACH and category-specific ones. kwery prioritizes a core set of high-volume marketplaces and comparison engines across German and international markets, all returning the same fields.
PriceAPI focus
- Amazon
- Google Shopping
- Idealo
- billiger.de
- Geizhals
- Galaxus
- PriceRunner
- Medizinfuchs
- Bol.de
- eBay
A wide long tail of retailer, comparison and specialist sources, extended over time.
kwery focus
- Amazon
- Google Shopping
- Idealo
- billiger.de
- guenstiger.de
- Otto
- Kaufland
- Lidl
- eBay
- Walmart
- AliExpress
- Rakuten
Core high-volume marketplaces returning the same fields, spanning DE/EU plus US and Asia-Pacific.
Neither mix is broadly better. Which one is right depends entirely on the catalog and the markets the pricing system competes in.
Google Shopping Matching Is a Real Engineering Problem
Both products support GTIN-oriented Google Shopping workflows, and both had to respond after Google changed GTIN search behaviour in late 2023. The practical difference is when matching happens.
PriceAPI's documented feed-based Google Shopping matching runs as a separate workflow with a turnaround documented at up to three business days, and its own per-value credit charge. Matched identifiers are then used in subsequent data requests.
kwery resolves the product inside the same request. Identity resolution and the observation return together, with match confidence attached, so the consuming system can decide how far to trust the match at read time.
PriceAPI, matching as a separate workflow
Matched IDs, then a second call for the observation
Time to usable match · Up to 3 business days (documented)
kwery, matching inside the request
Matched observation with confidence, same response
Time to usable match · Same response, one round trip
kwery resolves product identity within the requested source per request. It does not link one product's identity across marketplaces, for example, mapping a Google Shopping ID to an ASIN, Idealo ID or Walmart ID. Mapping observations across sources to your own catalog remains your responsibility.
What Does One PriceAPI Credit Actually Buy?
PriceAPI's pricing page describes one credit as a simple lookup for one product from one source, which sounds straightforward. Its documentation also explains that actual credit consumption can vary with how the request is made. Headline credit pricing does not necessarily describe the cost of a complete marketplace observation, so it is worth reading the documented mechanics before designing an integration.
- Pagination
- If product_and_offers requires several offer pages, each requested page can consume another credit. A request with up to three available pages can therefore consume up to three credits.
- Parameter changes
- Changing parameters away from defaults can double credit consumption. PriceAPI's own example shows 90 successfully looked-up products consuming 180 credits after changing max_age.
- Source multipliers
- Some sources have their own credit multipliers. Idealo currently consumes 1.5 credits per request.
- Product matching
- Dedicated matching can have its own cost. Google Shopping feed matching is currently documented at 10 credits per processed item.
PriceAPI effective cost
- Simple lookupBase
- Offer pages× pages
- Parameter change× parameters
- Source multiplier× source
- Product matching where required+ charge
Effective cost of one complete dataset
What one complete SKU dataset actually consumed
What One kwery Credit Covers
kwery is designed around the marketplace observation as the billing unit. For a normal fresh request, one SKU on one source with one fresh fetch is one credit, and product resolution, product data and offers are part of that observation.
Cache responses do not consume another credit under the current product model, and unused credits on paid subscriptions roll forward while the subscription remains active. The customer can model usage around the thing the application actually consumes: a marketplace observation for one SKU. Parameters such as the number of pages requested still increase consumption, on both sides of the comparison.
Compare Cost per Usable Dataset, Not Cost per Credit
A credit is an internal billing unit and has no standard meaning across providers. One provider may charge a credit for a page, an endpoint, a lookup, a product, a source or a matching step, while another credit covers several of those operations at once.
The meaningful commercial question is what it costs to obtain the complete marketplace dataset your application actually needs.
One Complete SKU Dataset
One complete SKU dataset = one product, on one source, at one point in time:
- Finding the right product
- Product data
- All required offers
- Sellers
- Shipping
- Availability
- Quality context
kwery bills one credit for that complete dataset; each vendor comparison places that unit next to the provider’s own billing unit.
Billing unit
- PriceAPI
- One credit is described as a simple lookup for one product from one source, but the number of pages requested, non-default parameters and dedicated matching each add units, and the documentation states the credit price can differ at source level.
- kwery
- One credit per complete SKU dataset: one SKU, one source, fetched fresh. Matching the product, the product data and the offers are all included.
Page count raises consumption on both sides: more requested pages means more units for PriceAPI and more credits for kwery. Run the same basket of SKUs through both and compare the cost of the complete dataset your application needs, not the headline credit price.
Where PriceAPI Has Genuine Strengths
Broader Coverage in Selected Specialist Sources
PriceAPI documents sources such as Geizhals, Galaxus, PriceRunner and Medizinfuchs that kwery does not currently expose. For a pharmacy catalog, a DACH electronics assortment or a Nordic comparison workflow, that source fit can decide the evaluation on its own.
Broad Reviews Coverage
PriceAPI exposes reviews across a wide set of sources. kwery provides reviews on selected sources, so when broad reviews coverage across many sources is a hard requirement, PriceAPI currently holds that ground.
Where the Two Products Are Simply Comparable
A large part of both products is the same category of capability. These are table stakes on either side and should not decide the comparison.
- API access
- Structured output
- Multiple formats
- Product information
- Marketplace pricing
- Offers and sellers
- Search workflows
- History on selected sources
- Reviews on selected sources
- Asynchronous processing
- Polling
- Webhooks
The dimensions that do decide it:
- Relevant source coverage
- Dataset completeness
- Product matching
- Trust score
- Normalization
- Observation provenance
- Detected change
- Integration model
- Effective cost per complete observation
What Comes Back With Each Record
Both products return prices and offers. The rows below show what else is attached to a record when it reaches your system, which question each concern answers, and which side provides it.
Coverage
Which marketplaces can I read?
BothPriceAPI
Broad long-tail source list including specialist price-comparison engines
kwery
Amazon, Google Shopping, Idealo, eBay, Walmart, Otto, Kaufland and further supported sources
Broad long-tail source list including specialist price-comparison engines
Amazon, Google Shopping, Idealo, eBay, Walmart, Otto, Kaufland and further supported sources
Collection
Who runs the retrieval?
BothPriceAPI
Managed retrieval through job-based requests
kwery
Managed retrieval from the requested marketplace
Managed retrieval through job-based requests
Managed retrieval from the requested marketplace
Product matching
Is this the right product?
BothPriceAPI
A dedicated matching request, made separately from the offer request
kwery
Give a barcode (GTIN/EAN), ASIN or marketplace ID and get the matching product on that marketplace, with a match confidence
A dedicated matching request, made separately from the offer request
Give a barcode (GTIN/EAN), ASIN or marketplace ID and get the matching product on that marketplace, with a match confidence
Response format
Does one integration read every source?
kwery onlyPriceAPI
Fields differ by source and request topic, so your system maps each one
kwery
The same response format for every source
Fields differ by source and request topic, so your system maps each one
The same response format for every source
Can you trust the data?
Should my system act on this price?
kwery onlyPriceAPI
Not offered, the response carries the data, not a confidence signal
kwery
A trust score and data-health flags come back with every record
Not offered, the response carries the data, not a confidence signal
A trust score and data-health flags come back with every record
Where the data came from
Can I see where and when this was collected?
kwery onlyPriceAPI
Not offered, no source, method or timestamp details documented
kwery
Every record says which source, which country, how it was collected and when
Not offered, no source, method or timestamp details documented
Every record says which source, which country, how it was collected and when
What changed since last time
What changed since the last reading?
kwery onlyPriceAPI
Compared downstream from stored responses
kwery
A structured change record when the next reading differs from the previous one
Compared downstream from stored responses
A structured change record when the next reading differs from the previous one
Application layer
Where does the pricing logic live?
BothPriceAPI
None, API and spreadsheet workflows, the pricing logic stays with you
kwery
None, the pricing logic stays in your systems
None, API and spreadsheet workflows, the pricing logic stays with you
None, the pricing logic stays in your systems
Source-native extras
What can I read beyond price and offers?
PriceAPI onlyPriceAPI
Reviews coverage and specialist sources such as Geizhals or PriceRunner
kwery
Not offered, marketplace price and offer data only
Reviews coverage and specialist sources such as Geizhals or PriceRunner
Not offered, marketplace price and offer data only
Design emphasis, not quality ranking
If the underlying layers are still unclear, the marketplace data infrastructure guide describes what sits between a marketplace and a production record.
Job Completion and Detected Changes Are Different
PriceAPI supports webhooks, and its documented webhook workflow tells the customer that a requested job has finished and the data is ready. That is useful production integration.
kwery also uses webhook-oriented delivery, and can additionally expose a structured difference when a subsequent observation detects a material change. The external marketplace may have changed at any point between the two observations; kwery detects the difference at the next observation.
Detected Change Event
- Observation T1€129,90
- Marketplace changesunknown
- Observation T2€119,90
kwery detects
€129,90 → €119,90
kwery discovers a change when the next marketplace observation differs from the previous one. It does not know the exact instant the marketplace changed. The structured delta is then emitted through the configured delivery workflow.
PriceAPI vs kwery
Feature lists and prices move. These rows describe how each product is currently documented, which is more useful in an evaluation than a feature count.
- 01
Multi-source ecommerce data
PriceAPI
Yes
kwery
Yes
- 02
Amazon
PriceAPI
Yes
kwery
Yes
- 03
Google Shopping
PriceAPI
Yes
kwery
Yes
- 04
Idealo
PriceAPI
Yes
kwery
Yes
- 05
Otto
PriceAPI
Not in current core DE coverage docs
kwery
Yes
- 06
Kaufland
PriceAPI
Not in current core DE coverage docs
kwery
Yes
- 07
Lidl
PriceAPI
Not in current core DE coverage docs
kwery
Yes
- 08
Specialist sources such as Geizhals
PriceAPI
Stronger
kwery
Not current focus
- 09
GTIN workflows
PriceAPI
Yes
kwery
Yes
- 10
Google Shopping matching
PriceAPI
A dedicated matching request, separate from the data request
kwery
Matched in the same call, with a match confidence
- 11
Same fields across sources
PriceAPI
Fields differ by source and request topic
kwery
Every source returns the same fields
- 12
Can you trust the data?
PriceAPI
Not offered, the response carries the data, not a confidence signal
kwery
A trust score and data-health flags come back with every record
- 13
Where the data came from
PriceAPI
Not offered, no source, method or timestamp details documented
kwery
Every record says which source, which country, how it was collected and when
- 14
What changed since last time
PriceAPI
Not offered, no change feed in the documented API
kwery
A structured change record when the next reading differs from the previous one
- 15
Polling
PriceAPI
Yes
kwery
Yes
- 16
Webhooks
PriceAPI
Yes, when a job finishes
kwery
Yes, for results and for detected changes
- 17
Manual exports
PriceAPI
Yes
kwery
Yes (JSON, CSV; other formats on request)
- 18
Billing unit
PriceAPI
Request, pages, parameters and source can affect credits
kwery
One credit per complete SKU dataset, per source
- 19
Credit rollover
PriceAPI
Not clearly documented publicly
kwery
Yes, while the subscription remains active
| Dimension | PriceAPI | kwery |
|---|---|---|
| Multi-source ecommerce data | Yes | Yes |
| Amazon | Yes | Yes |
| Google Shopping | Yes | Yes |
| Idealo | Yes | Yes |
| Otto | Not in current core DE coverage docs | Yes |
| Kaufland | Not in current core DE coverage docs | Yes |
| Lidl | Not in current core DE coverage docs | Yes |
| Specialist sources such as Geizhals | Stronger | Not current focus |
| GTIN workflows | Yes | Yes |
| Google Shopping matching | A dedicated matching request, separate from the data request | Matched in the same call, with a match confidence |
| Same fields across sources | Fields differ by source and request topic | Every source returns the same fields |
| Can you trust the data? | Not offered, the response carries the data, not a confidence signal | A trust score and data-health flags come back with every record |
| Where the data came from | Not offered, no source, method or timestamp details documented | Every record says which source, which country, how it was collected and when |
| What changed since last time | Not offered, no change feed in the documented API | A structured change record when the next reading differs from the previous one |
| Polling | Yes | Yes |
| Webhooks | Yes, when a job finishes | Yes, for results and for detected changes |
| Manual exports | Yes | Yes (JSON, CSV; other formats on request) |
| Billing unit | Request, pages, parameters and source can affect credits | One credit per complete SKU dataset, per source |
| Credit rollover | Not clearly documented publicly | Yes, while the subscription remains active |
“Not verified” means no equivalent capability was found in publicly available documentation at the verification date. It does not claim that PriceAPI cannot have internal capabilities that are not publicly documented. Last verified: September 2026.
When PriceAPI or kwery Is the Better Fit
The two products overlap heavily: kwery covers the same core workflows as PriceAPI and adds the value layer — identity, data-health, provenance and detected change — together with more predictable, lower-complexity billing and faster in-request matching. The genuine reasons to prefer PriceAPI are narrow: specific smaller sources kwery does not yet expose, and broad reviews coverage.
When PriceAPI may be the better fit
- specialist PriceAPI sources such as Geizhals, Galaxus, Medizinfuchs or PriceRunner are required
- broad reviews coverage across sources is required
- the existing per-source, per-topic request model already fits internal infrastructure
When kwery may be the better fit
- pricing data is primarily consumed machine-to-machine
- Otto, Kaufland, Lidl or other kwery-native sources matter
- the pricing system needs explicit data-health flags
- every record must say where and when it was collected
- change records simplify downstream automation
- usage should map predictably to complete SKU datasets
Before You Switch
A provider migration is not only an API-key change. These considerations are specific to moving between PriceAPI and kwery:
Topics Become One Request
Requests organized by source and topic become one request per SKU and source in kwery. Inventory which topics you actually consume before mapping fields.
Job Polling to Webhooks
Batch polling loops can usually be replaced by webhook delivery, which changes how your scheduler and retry logic are structured.
Quality Handling
Logic that currently guesses whether a result is usable can often be replaced by reading the data-health flags returned with each record.
General migration checklist
- Identifier Compatibility
- Can existing GTINs, EANs, UPCs, ASINs or source URLs be reused as request inputs?
- Schema Migration
- Which fields change name, type or meaning, and which consumers read them today?
- Source Parity
- Are all required marketplaces and countries available on both sides of the move?
- Freshness Semantics
- Does "fresh" mean the same thing in both systems, and is the observation timestamp explicit?
- Offer Modeling
- Are seller, shipping and availability represented in equivalent ways?
- History
- Will historical records need to remain in the existing system, and for how long?
- Failure Handling
- How should the application interpret unresolved products and partial results?
- Billing Unit
- Are you paying by request, credit, record, product/source lookup or another unit?