Walmart-Preise für eine Produktliste mit Python überwachen

Repricing und Wettbewerbsbeobachtung starten beide mit derselben Frage: Wofür verkauft sich dieses Produkt gerade auf Walmart. So ziehst du das als strukturierte Felder mit Python, so sieht die Antwort tatsächlich aus, sobald du über die erste Ebene hinauskommst, und das ist der eine Credit-Spar-Trick, den du kennen solltest, wenn du dasselbe Produkt auch auf Amazon trackst.

Der Endpoint will eine URL, keinen Query-String

/v1/walmart nimmt keinen query-Parameter. Er nimmt url, und diese URL muss eine echte Walmart-Such-URL sein, die Art, die du in die Adressleiste tippen würdest. Du baust sie selbst:

from urllib.parse import urlencode

def walmart_search_url(query):
    return "https://www.walmart.com/search?" + urlencode({"q": query})

Das ist der ganze Trick: Walmarts eigene Suchseite nimmt einen q-Parameter, also funktioniert hier auch jeder Produktname, jede Marke oder UPC, die du normalerweise in die Suchbox tippen würdest. Übergib die fertige URL als url, und FastAF holt und parst sie. Weil es eine echte, gewöhnliche URL ist statt eines erfundenen Query-Formats, wirkt jede Sortierung oder jeder Filter, den du auf Walmarts eigener Suchseite von Hand setzen kannst, genauso durch, weil die URL das ist, was tatsächlich abgerufen wird.

Die Version, die funktioniert

import requests

API_KEY = "faf_live_..."  # dein FastAF-Key

resp = requests.get(
    "https://api.fastaf.co/v1/walmart",
    params={"url": walmart_search_url("web scraping api")},
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=60,
)
resp.raise_for_status()

for group in resp.json()["search_results"]:
    for item in group["item"]:
        print(f'{item["current_price"]:>10}  {item["seller_name"]:<20}  {item["usItemId"]}  {item["title"][:50]}')

Das kostet 5 Credits und gibt eine Zeile pro Produkt aus: aktueller Preis, Verkäufer, die usItemId, mit der du genau dieses Listing trackst, und der Titel.

Erst Gruppen, dann Produkte innerhalb der Gruppen

search_results ist keine flache Liste von Produkten. Es ist eine Liste von Gruppen, jede mit eigenem title, description, totalItemCount und einer item-Liste, und die Produkte stecken innerhalb von item. Als wir die Query oben laufen ließen, kam die Antwort als zwei Gruppen zurück: eine Gruppe “Results for …” mit null Items, und eine Gruppe “Other options to consider” mit 40 der gemeldeten 54 Items. Code, der nur die erste Gruppe liest, würde nichts ausgeben und kaputt wirken. Loop über jede Gruppe, wie das Beispiel oben es tut, und du bekommst alle 40.

Preise kommen als Anzeige-Strings an, nicht als Zahlen: normalerweise "$19.59", "Now $18.61", wenn before_price den Preis vor dem Rabatt enthält. Ein kleiner Helper übernimmt beides:

def clean_price(raw):
    if not raw:
        return None
    return float(raw.replace("Now $", "").replace("$", "").replace(",", ""))

Speichere usItemId als stabilen Key. current_price, seller_name und availability_status sind die drei Felder, die sich zwischen Checks tatsächlich ändern; alles andere an einem Listing (Titel, Marke, canonicalUrl) ist für die Anzeige da und selten das Diffen wert.

Zwei Felder, die du kennen solltest, bevor du dich auf sie verlässt: rating und reviews kommen bei den meisten Suchergebnissen in der Praxis als null zurück, bau dein Monitoring also um Preis und Verfügbarkeit herum, nicht um Rezensionszahlen, außer du hast bestätigt, dass ein bestimmtes Listing sie führt. seller_name lohnt sich ebenfalls zu prüfen: Eine Walmart-Suche mischt Listings, die direkt von Walmart.com verkauft werden, mit solchen von Marketplace-Verkäufern, und das Sample oben brachte beides plus eine Handvoll Drittanbieter-Buchhändler zutage, jeder Eintrag mit eigenem seller_name und current_price. Wenn deine Repricing-Regel speziell Walmarts eigenen Preis treffen soll statt jeden Reseller, der in der Suche auftaucht, filtere auf seller_name, bevor du irgendetwas diffst.

Über die Zeit tracken, dann gegen Amazon prüfen

Ein Repricing-Job ist einfach dieser Call nach Zeitplan: speichere clean_price(item["current_price"]) pro usItemId, vergleiche mit dem zuletzt gespeicherten Wert, und alarmiere jenseits welcher Schwelle auch immer für dich zählt. Drei Checks am Tag pro SKU sind 15 Credits am Tag, oder etwa 450 Credits im Monat pro getracktem Produkt.

Wenn du denselben Artikel an mehr als einem Ort verkaufst, beantwortet der Amazon-Endpoint (1 Credit, gegenüber 5 hier) die andere Hälfte der Frage:

def amazon_price(query):
    resp = requests.get(
        "https://api.fastaf.co/v1/amazon",
        params={"query": query, "domain": "com"},
        headers={"Authorization": f"Bearer {API_KEY}"},
        timeout=60,
    )
    resp.raise_for_status()
    for item in resp.json()["results"]:
        if item["type"] == "search_product":
            return item["extracted_price"]

Sechs Credits geben dir den Preis desselben Produkts auf beiden Marktplätzen in einem Durchgang, was normalerweise genau das ist, was eine Repricing-Regel braucht: nicht nur „hat sich unser Preis bewegt”, sondern „sind wir noch wettbewerbsfähig gegenüber dem anderen Kanal”. Lass das Paar nach demselben Zeitplan laufen und speichere beide Preise nebeneinander, damit eine Lücke zwischen den Marktplätzen als Zeile in deinen eigenen Daten auftaucht, statt etwas zu sein, das du zufällig Wochen später bemerkst.

Was das kostet

Volumen	Credits (30 Tage)	Paket, das das abdeckt	Kosten
300 SKUs, einmal am Tag geprüft	45.000	Growth, $29	~$17,40 vom Paket
1.000 SKUs, zweimal am Tag geprüft	300.000	Scale, $99	das ganze Paket
5.000 SKUs, einmaliger Sweep	25.000	Growth, $29	~$9,67 vom Paket

Fehlgeschlagene Anfragen werden nie berechnet, Credits werden reserviert, wenn eine Anfrage startet, und zurückgegeben, wenn nichts zurückkommt. Starte mit dem Free Tier: 500 Credits, keine Karte, genug, um das auf deinen eigenen Katalog anzusetzen und zu sehen, wie die Antwort aussieht, bevor du einen Zeitplan dafür festlegst.