Marketplace analysis

Check the Kaufland Buybox: Compare offers, prices and delivery times with AI

Compare your Kaufland offer in the Buybox: identify your own listing, compare price plus shipping, and interpret delivery times and data gaps correctly.

To assess your Kaufland offer in a Buybox comparison, you need the reported rank and offer terms for the same product, country marketplace and condition. Identify your own offer first, then compare the item price plus shipping and the delivery time range. AI can use the Backlane Kaufland integration to place these details side by side. A price difference or a longer delivery time alone does not establish why your offer holds a particular rank.

This workflow takes you from a specific product identifier to a reasoned checklist. The example is entirely fictional; the prompts are templates for read-only queries. The Backlane documentation explains how to connect your Kaufland account and AI tool.

Which offers belong in the same Buybox comparison?

Compare offers on the same product page. The regular Kaufland query, GET /buybox, requires the Kaufland product ID id_product, a storefront and a condition filter. For Kaufland.de, the storefront is de. You can first use a product query to map an EAN to a Kaufland product ID. Check the product title too, so that you do not accidentally analyse a different variant. The queries are described in the Kaufland endpoint reference.

Choose the condition as precisely as possible: new means a new item, while used - good specifies a particular used condition. The group filters used and refurbished can include several subconditions. Have the actual returned condition displayed for each offer. A used item with substantial signs of wear is not a fair price comparison for a new one.

A storefront identifies the country marketplace, not just the language of the output. Kaufland explains this in its REST API basics. Results from different countries belong in separate comparisons.

How does AI identify your own offer?

The most reliable approach is to match your known offer identifier id_offer or the Kaufland offer ID id_unit. In the Buybox response, these two fields are only visible for your own offers; id_offer may also be empty. A similar seller name alone is therefore not enough to establish a match. The fields are described in the endpoint reference.

Include your identifier in the prompt and ask the AI to state the evidence for the match. If several of your offers appear, for example with different terms, they must remain on separate rows. Kaufland explains the distinction between a product and your own offers in its inventory documentation.

If the match remains uncertain, the result should be “own offer not uniquely identified”. The AI should neither assume that the cheapest result is yours nor invent a rank for your offer.

Which figures should you compare side by side?

Show the reported rank, the individual price components and the full delivery time range. An additional sort by combined price is your own analysis and must not replace the reported Buybox rank.

DetailField or calculationWhat it contributes to the check
Buybox rankbuybox_rankReported position of the offer
SellersellerHelps with visual checks and matching
Item pricepriceAssess the price separately from shipping
Shipping chargeshipping_rateA missing value does not mean free shipping
Combined priceItem price + shipping chargeYour own calculation using confirmed units
Delivery time rangedelivery_time_min and delivery_time_maxShow both limits, not just the more favourable value
Condition and fulfilmentcondition, fulfillment_typeRecord comparability and fulfilment method

These fields are provided by the regular Buybox schema. Confirm the currency and units before calculating anything. If the scale is unclear, the AI must neither label raw values as euros nor automatically divide them by 100. The unit of delivery time must also be confirmed before displaying it.

Initially label the calculated sum item price plus shipping. The addition alone does not establish whether a customer will actually pay that exact amount when additional discounts or different shipping terms apply. If either component remains unclear, the comparison amount remains unknown too.

How do you start a read-only check in chat?

Start with one product and a known identifier for your own offer. This lets you check the match and the displayed values against the Seller Portal before examining several products.

The library also provides a compact Kaufland Buybox comparison prompt for this first check.

Check the regular Kaufland Buybox for [EAN or id_product]
on storefront de, condition new, in my connection [Connection].
Use read-only queries. My id_offer is [Identifier].
Resolve an EAN to the product ID first and check the title.

Show up to ten available offers with their reported rank,
seller, condition, item price, shipping charge, combined price,
delivery time range and fulfilment method. Confirm the units;
flag unclear values instead of guessing a conversion.

Mark my offer and show the evidence for the match. Also state
the retrieval time, the number of returned offers and num_units.
Then give three reasoned points to check. Do not change any offers.

What does the limit of ten offers mean?

The regular query returns at most ten of the highest-ranked offers. This is a fixed endpoint limit, not an instruction to fetch more pages: the endpoint does not provide an offset. Kaufland documents the maximum and default value of ten in its API release notes.

Distinguish the number of returned rows from num_units, the reported total number of offers for the product. Ten returned rows do not prove that only ten offers exist.

If your offer is missing, this establishes neither its exact position nor that it is invisible. First check the product, storefront, condition and offer identifier. Then inspect your own offer separately in the Seller Portal. The Buybox excerpt alone does not replace that check.

What does a useful comparison look like in practice?

Suppose you are checking a table lamp on Kaufland.de. Your own offer has been confirmed using id_offer, and all four offers belong to the same product and the new condition. In the following entirely fictional example, monetary values are already in euros and delivery times are in days. These are not raw API values or merchant data.

OfferReported rankItem priceShippingItem price + shippingDelivery time
Seller A1€36.90€0.00€36.902–3 days
Your offer2€34.90€2.00€36.904–6 days
Seller B3€33.90€3.90€37.803–5 days
Seller C4€38.50€0.00€38.502–4 days

Your item price is lower than Seller A’s; including shipping, the two sums are equal. Seller B has the lowest item price but costs €0.90 more once shipping is added. Comparing item prices alone would therefore lead you in the wrong direction.

Your offer’s longer delivery time is a specific point to investigate. It does not yet prove why rank 2 was reported. For example, Kaufland names faster delivery as a deciding factor for Smart Pricing Standard when minimum prices are equal. You must not apply that specific rule to every observed ranking without knowing the pricing rules involved. Kaufland: Smart Pricing

Your next step would be to compare the configured handling and transit times with what your operation can actually achieve. A shorter stated delivery time only makes sense if you can meet it. At the same time, check that the price and shipping details in the Seller Portal match the comparison. Only then decide whether to make a change.

Analyse the comparison just created for my offer [id_offer].
Use only confirmed values and perform read-only queries only.

Show the difference in item price plus shipping against the
offer ranked first, and the differences at both ends of the
delivery time range.
Separate observation, possible explanation and next check.
Do not infer a guaranteed rank improvement or a target price.

Is the “Virtual Buy Box” the same comparison?

No. GET /similar-products/buybox looks at a group of similar products with different EANs, such as comparable private-label products. These separate product pages do not share a regular Buybox. Kaufland explicitly explains this distinction in its Virtual Buy Box documentation.

Use the regular Buybox to answer “How does my offer rank on this product page?” The question “Which similar products compete for the same buyers?” is a separate analysis. Do not mix their ranks in one table.

How do you check later whether your offer has changed?

Compare two recorded observations with identical filters. A single retrieval does not show a trend or retrospectively explain the previous month’s sales.

Check the same product ID, storefront and condition again,
using read-only queries. Compare with the previous observation
in this chat; if it is missing, state the gap.

Show both retrieval times, my verified rank, item price plus
shipping, delivery time range and the coverage of each result.
State changes and open questions. Do not claim cause and effect
based solely on the sequence of events.

To answer the follow-up question of whether order volumes have also changed, you need a separate analysis with a fixed period and unambiguous product matching. The practical guide to analysing marketplace data with AI explains that workflow.

Ask your own data the next question.

Connect your seller accounts with Backlane and use the available data in your AI assistant.

Set up Backlane