API WB Ozon: Behandlung von 429- und 50x-Fehlern

Umgang mit 429- und 50x-Fehlern in Wildberries- und Ozon-APIs

Beim Scrapen von Daten aus den Wildberries- und Ozon-APIs stoßen Entwickler häufig auf 429-Fehler (zu viele Anfragen) und 50x-Fehler (Serverfehler). Diese treten durch hohe Belastung der Endpunkte auf. Die Standardlösung des Supports sind Retries. Wir stellen drei bewährte Strategien vor: einfache Retry-Behandlung, Optimierung des Anfragevolumens und Monitoring mit partiellen Nachläufen.

Einfache Retry-Behandlung

Beginnen Sie damit, 429- und 50x-Fehler als normale Störungen zu behandeln. Implementieren Sie Retry-Logik mit exponentiellem Backoff und parsen Sie Header wie X-Ratelimit-Retry. Das reduziert Bans und steigert die Robustheit.

Hier ein Beispiel für eine POST-Anfrage mit Retries:

def get_oz(url, heads, params, max_retries=5, timeout=30):
    result = {}
    for retries in range(1, max_retries + 1):  
        
        try:
            response = requests.post(url, headers=heads, json=params, timeout=timeout)
        except requests.RequestException as e:
            print(f'!!! Netzwerkfehler beim Versuch {retries}: {e}!!!')
            time.sleep(2 * retries)
            continue  
                
        # 200 bedeutet Erfolg    
        if response.status_code == 200:
            return response.json()
            
        # 429 - Zu viele Anfragen, smarte Pause und Retry
        elif response.status_code == 429:    
            pause_time = 2 ** retries
            
            # X-Ratelimit-Retry - Wildberries-Trick, Ozon könnte das nachholen
            if 'X-Ratelimit-Retry' in response.headers:
                pause_time = int(response.headers['X-Ratelimit-Retry']) + 5
            print(f'get_oz: ! -Zu viele Anfragen- beim Versuch {retries}. Pause {pause_time} Sek.')
            time.sleep(pause_time)
        
        # 5xx-Fehler - Pause und Retry                    
        elif 500 <= response.status_code < 600:
            pause_time = 2 ** retries
            print(f'get_oz: ! -Fehler {response.status_code}- beim Versuch {retries}. Pause {pause_time} Sek.')
            time.sleep(pause_time)
        
        # Andere Fehler - abbrechen!                
        else:
            print(f'get_oz: !!! API-Datenabruf fehlgeschlagen! Code: {response.status_code}')
            return None


    print(f'get_oz: !!! Alle {max_retries} Versuche fehlgeschlagen')
  
    return None

• 5 Retries reichen für die meisten typischen Belastungen.
• Behandeln Sie Pagination-Loops (Offset/Seite) auf höherer Ebene.
• Bei Totalausfall: Stunde oder länger pausieren.

Das passt nahtlos in jede ETL-Pipeline für APIs.

Optimierung des Datenvolumens

Große Anfragen (z. B. Transaktionen einer Woche) lösen Fehler auf späteren Pagination-Seiten aus. Zerlegen Sie sie in kleine, unabhängige Batches: nach Tag, Kategorie oder Filtern. Speichern Sie jeden Batch sofort in Ihrer DB – ein Verlust löscht nicht den gesamten Fortschritt.

Vorteile:

• Weniger Seiten pro Anfrage (1–3 statt 20).
• Unabhängige Retries pro Batch.
• Partielle Speicherungen bei Fehlern.

Beispiel: Ozon-Transaktionen nach Tag laden:

date_from = today() - timedelta(days=7)
date_to = today() - timedelta(days=1)
current_date = date_from
delta = timedelta(days=1)

# Schleife durch Tage von date_from bis date_to
while current_date <= date_to:  
    transactions_oneday = pd.DataFrame([])           
    url = "https://api-seller.ozon.ru/v3/finance/transaction/list"
    ipage = 1
    all_pages_data = []
    while True:
        data = {
            "filter": {
                "date": {
                    "from": str(current_date) + "T00:00:00.000Z",
                    "to": str(current_date) + "T23:59:59.999Z"
                }
            },
            "page": ipage,
            "page_size": 1000
            }
        dd = []
        apioz_response = get_oz(url, headers, data, 5)
        if len(apioz_response) > 0 :
            dd = apioz_response['result']['operations']
            all_pages_data.extend(dd)
        else:
            print(f'!!! Leere API-Antwort')    

        # Wenn Seite <1000 Zeilen hat, ist es die letzte - break    
        if len(dd) < 1000: break

        ipage +=1
            
    transactions_oneday = pd.DataFrame(all_pages_data)        
    # Sofort in DB exportieren, was von API kam
    export_to_db('oz_transactions', transactions_oneday)

    # Nächster Tag
    current_date += delta    

Verschachtelte Schleifen wirken chaotisch, aber die Zuverlässigkeit explodiert.

Monitoring und partielle Nachläufe

Für volle Automatisierung: Sicherheitsnetz mit Hintergrund-Monitoring. Nach dem Hauptlauf (z. B. 6–7 Uhr) stündlich Logs/DB prüfen (8–12 Uhr).

• Letzten Task-Status überprüfen.
• Datenintegrität kontrollieren (Datums-Lücken).
• Gezielte Retries nur für fehlende Stücke auslösen.

Das minimiert manuelle Korrekturen, besonders bei täglichen Updates.

Wichtige Erkenntnisse

• Exponetiellen Backoff mit Retry-Headern für 429 nutzen.
• Große Anfragen in tägliche/Filter-Batches mit Sofort-Speicherung zerlegen.
• Stündliches Monitoring nach Sammlung für Lückenfüllerung.
• 5 Retries decken 95 % der Fehler ab; Totalflops bekommen Stunde+ Verzögerung.
• In ETL ohne enge Pagination-Kopplung integrieren.

— Editorial Team