Fehlercodes
HTTP-Statuscodes der Listings API, die SYxxxxx-Fehlercodes für Listings und Social sowie die drei Formate für Fehlerantworten, die die v4 API zurückgibt.
Die Listings API verwendet herkömmliche HTTP-Statuscodes, um das Ergebnis einer Anfrage anzugeben. Fehlercodes haben das Präfix SY und werden in der Fehlerzeichenfolge message im Format SYxxxxx: <human-readable reason> übermittelt.
HTTP-Statuscodes
HTTP status code summary
Drei Antwortformate
Die meisten Fehler enthalten ein errors-Array, entweder auf oberster Ebene oder verschachtelt im Ergebnis der Operation, wie die folgenden Abschnitte zeigen. Einige Fehler geben stattdessen ein einzelnes error-Objekt zurück: bei überschrittenen Ratenlimits (429) und bei einigen Fehlern auf Anfrageebene (400/500 mit einem code wie INTERNAL_SERVER_ERROR). Prüfen Sie auf beide Varianten: errors ist ein Array, error ist ein Objekt.
1. Anfrageebene: errors[] auf oberster Ebene
Fehler bei der Authentifizierung, der Autorisierung oder aufgrund fehlerhaft aufgebauter Anfragen brechen die Verarbeitung ab, bevor die Operation ausgeführt wird. Sie geben den passenden Status 4xx (siehe oben) mit dem Fehler auf der obersten Ebene der Antwort zurück.
{ "data": { "createLocation": null }, "errors": [{ "message": "SY90005: Invalid Token" }]}2. Schreibvalidierung: verschachteltes data.<operation>.errors[]
Eine ansonsten korrekt aufgebaute Anfrage zum Erstellen, Aktualisieren oder Veröffentlichen gibt HTTP 200 zurück. Verstößt die Eingabe gegen eine Geschäftsregel, wird der Fehler verschachtelt unter den eigenen Nutzdaten der Operation in data.<operation>.errors gemeldet. Bei Erfolg ist dieses Array vorhanden und leer ("errors": []).
{ "data": { "createLocation": { "errors": [ { "message": "SY10126: City is Mandatory" }, { "message": "SY10010: state_iso" } ], "location": null } }}3. Gateway-Ebene: ein einzelnes error-Objekt auf oberster Ebene
Überschrittene Ratenlimits und unerwartete Gateway-Fehler brechen die Verarbeitung vor der Übersetzung ab und geben ein error-Objekt mit einem code, einem message und einem correlation_id zurück. Den Antworttext für 429 finden Sie weiter unten unter rate_limited.
Lesen Sie bei einem Schreibvorgang immer data.<operation>.errors, auch bei einem 200 mit einem befüllten data.<operation>-Objekt: Ein Schreibvorgang kann teilweise fehlschlagen und dies hier melden.
Eine 402 Payment Required-Antwort hat keine error-Umhüllung: code, message, doc_url und, wenn eine Rechnung zu bezahlen ist, pay_url befinden sich auf oberster Ebene. Siehe weiter unten unter payment_required.
Die Wiederholung eines Schreibvorgangs bleibt nicht ohne Folgen
Die v4 API unterstützt Idempotency-Key nicht: Der Header wird ignoriert, und kein Endpunkt erkennt wiederholte Schreibvorgänge. Ein Aufruf zum Erstellen, Aktualisieren oder Veröffentlichen, bei dem eine Zeitüberschreitung auftritt oder der einen 5xx zurückgibt, kann auf dem Server dennoch bereits dauerhaft gespeichert worden sein, sodass eine blinde Wiederholung einen doppelten Standort, Beitrag oder eine doppelte Antwort auf eine Bewertung erzeugen kann.
Wiederholen Sie Lesevorgänge bei Bedarf mit zunehmenden Wartezeiten. Lesen Sie bei einem Schreibvorgang zuerst den gespeicherten Stand aus: Suchen Sie den Datensatz anhand eines Schlüssels, den Sie kontrollieren (storeId, ein Filialcode, die Antwortliste der Interaktion), und wiederholen Sie den Aufruf nur, wenn der Datensatz tatsächlich fehlt.
Häufige Codes
Common SY error codes
Validierungscodes im Bereich SY10xxx entsprechen einem bestimmten Eingabefeld; message benennt das Feld oder die Regel, deren Prüfung fehlgeschlagen ist. Authentifizierungs- und Autorisierungscodes im Bereich SY90xxx gelten auf Anfrageebene und werden auf der obersten Ebene mit dem passenden Status zurückgegeben.
Codes für verbundene Konten
Codes im Bereich SY810xx stammen von den Connected Accounts-Endpunkten, die einen Eintrag auf einer Plattform importieren oder verknüpfen. Sie werden bei einem HTTP 200 verschachtelt im Antworttext zurückgegeben (Antwortstruktur 2 oben), lesen Sie daher data.<operation>.errors auch dann, wenn der Status einen Erfolg anzeigt.
SY810xx connected-account and import codes
Social-Codes
Codes im Bereich SY950xx stammen von den Social-Endpunkten: Marken, Verbindungen und Social-Media-Beiträge. Wie die Codes für verbundene Konten werden sie bei einem HTTP 200 verschachtelt im Antworttext zurückgegeben. Lesen Sie daher data.<operation>.error (und data.<operation>.errors bei den Routen für Massenoperationen), auch wenn der Status einen Erfolg anzeigt.
SY950xx Social codes
SY95042 und SY95044 sind Fehler aufgrund fehlender Tarifberechtigungen, keine Eingabefehler: Ein erneuter Versuch ohne Tarifänderung schlägt auf dieselbe Weise fehl. SY95045, SY95046, SY95049 und SY95052 sind Eingabefehler, die sich in der nächsten Anfrage beheben lassen.
Berechtigungscodes für Listings
Listings plan codes
rate_limited
429 Too Many Requests: Das Konto hat das Anfragelimit seines Tarifs überschritten. Der Antworttext ist die standardmäßige Fehlerantwort mit einem Hinweis in retry_after_seconds, einem Wert in correlation_id, den Sie bei Supportanfragen angeben sollten, und einem Verweis in doc_url, der auf diesen Abschnitt zurückführt:
{ "error": { "code": "RATE_LIMITED", "message": "Too many requests. Slow down.", "retry_after_seconds": 30, "correlation_id": "9f2c1e64-2b1a-4b0e-9f1a-2c7d5e8a1b3c", "doc_url": "https://listingsapi.com/docs/error-codes#rate_limited" }}Warten Sie die in retry_after_seconds angegebene Zeit ab (oder die im Header Retry-After angegebene Zeit, falls dieser vorhanden ist) und wiederholen Sie dann die Anfrage mit exponentiellem Backoff. Die Limits pro Tarif und eine Referenzimplementierung für Backoff finden Sie unter Anfragelimits.
payment_required
402: Die letzte Zahlung für dieses Konto war nicht erfolgreich, daher sind alle /api/v4-Endpunkte ausgesetzt. Der Antworttext enthält pay_url, die Stripe-Seite für die unbezahlte Rechnung, sofern eine solche Seite verfügbar ist, und der Antwortheader X-Error-Code enthält denselben Wert für code. Sie können weiterhin die Abrechnungsseite im Dashboard öffnen, um die Zahlung vorzunehmen.
{ "code": "payment_required", "message": "This account has an unpaid invoice, so API access is paused. Pay the invoice to restore access.", "pay_url": "https://invoice.stripe.com/i/acct_123/test_abc", "doc_url": "https://listingsapi.com/docs/error-codes#payment_required"}Der Zugriff wird innerhalb einer Minute wiederhergestellt, nachdem die letzte offene Rechnung bezahlt wurde. Ist die Rechnung 3 Tage nach dem ersten fehlgeschlagenen Zahlungsversuch noch unbezahlt, wird das Listings-Abonnement gekündigt und die Standorte des Kontos werden archiviert. Hat das Konto auch ein aktives Social-Abonnement, behält es den Social-Zugriff; andernfalls wird das Konto geschlossen und seine API-Schlüssel funktionieren nicht mehr.
social_payment_required
402: Die letzte Zahlung für das Social-Abonnement war nicht erfolgreich, daher sind die Social-Endpunkte (/api/v4/social/*) ausgesetzt. Die Listings-Endpunkte funktionieren weiterhin. Der Antworttext enthält dieselben Felder wie payment_required, mit "code": "social_payment_required". Ist die Rechnung 3 Tage nach dem ersten fehlgeschlagenen Zahlungsversuch noch unbezahlt, wird das Social-Abonnement gekündigt und die Marken des Kontos werden archiviert. Ein Konto ohne Listings-Abonnement wird geschlossen und seine API-Schlüssel funktionieren nicht mehr.
Fehler der Steuerungsebene im Entwicklerportal
Die Endpunkte zur Konto- und Schlüsselverwaltung im Entwicklerportal (die eigenen API-Routen des Dashboards) geben eine einheitliche, strukturierte Fehlerantwort zurück, die sich von den oben beschriebenen REST-errors[]-Formaten unterscheidet. Jedes code enthält correlation_id sowie einen Verweis in doc_url, der auf den entsprechenden Abschnitt hier zurückführt.
{ "error": { "code": "AUTH_INVALID_KEY", "message": "Session is invalid or expired.", "correlation_id": "9f2c1e64-2b1a-4b0e-9f1a-2c7d5e8a1b3c", "doc_url": "https://listingsapi.com/docs/error-codes#auth_invalid_key" }}auth_missing_key
401: Es wurden keine Zugangsdaten angegeben. Melden Sie sich erneut an oder senden Sie Ihren Schlüssel als Authorization: API <your-key>.
auth_invalid_key
401: Die Sitzung oder der Schlüssel ist ungültig oder abgelaufen. Authentifizieren Sie sich erneut oder stellen Sie im Dashboard einen neuen Schlüssel aus.
auth_insufficient_scope
403: Die Zugangsdaten sind gültig, berechtigen jedoch nicht zu dieser Aktion. Ein Schlüssel mit Leseberechtigung kann keine Schreibendpunkte aufrufen; stellen Sie einen Schlüssel mit Schreibberechtigung aus, falls Sie einen benötigen.
not_found
404: Die angeforderte Ressource oder eine über ihre ID adressierte Ressource existiert nicht.
conflict
409: Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource (beispielsweise beim Widerrufen eines bereits widerrufenen Schlüssels).
validation_failed
422: Der Anfragetext hat die Validierung nicht bestanden. Die Felder field und details der Antwort benennen die fehlerhafte Eingabe.
internal_error
500: Ein unerwarteter serverseitiger Fehler. Wiederholen Sie einen Lesevorgang mit exponentiellem Backoff; lesen Sie bei einem Schreibvorgang zunächst den Datensatz erneut aus (siehe Das Wiederholen eines Schreibvorgangs ist nicht kostenlos). Geben Sie correlation_id an, wenn Sie den Support kontaktieren.
dependency_unavailable
503: Ein Dienst, von dem die API abhängt, ist vorübergehend nicht verfügbar. Wiederholen Sie die Anfrage mit Backoff.
Informationen zu 429 finden Sie oben unter rate_limited.
Fehler im Code behandeln
Prüfen Sie zuerst den HTTP-Status; durchsuchen Sie dann bei Schreibvorgängen den Antworttext nach einem verschachtelten errors-Array:
from listingsapi import APIError, ListingsAPI client = ListingsAPI(api_key=os.environ["LISTINGSAPI_KEY"]) try: location = client.locations.create(input=payload)except APIError as e: # Raised for a non-2xx status (AuthenticationError, ValidationError, and # so on) and for an error payload returned inside a 200 body. raise RuntimeError(f"Listings API error: {e}") from eBei direkter Verwendung der HTTP-API erfolgen dieselben beiden Prüfungen explizit: zuerst die Prüfung des Statuscodes und dann die der Antwortdaten:
resp = requests.post( "https://listingsapi.com/api/v4/locations", headers={"Authorization": f"API {os.environ['LISTINGSAPI_KEY']}"}, json=payload, timeout=30,)resp.raise_for_status()body = resp.json() op = (body.get("data") or {}).get("createLocation") or {}if op.get("errors"): messages = [e["message"] for e in op["errors"]] raise RuntimeError(f"Listings API error: {messages}")Das Python SDK übernimmt beides für Sie: Es ordnet jedem HTTP-Status eine typisierte Ausnahme zu und löst auch bei Fehlerdaten, die innerhalb eines 200-Antworttexts zurückgegeben werden, eine Ausnahme aus.