Zum Hauptinhalt springen

Statuscodes

Fehlerformat

Fehler sind JSON mit einem error-Feld. Je nach Endpunkt kommen weitere Felder hinzu:
Die einzige Ausnahme: Beim 429 des Rate-Limits ist error ein Objekt, kein String — siehe Rate-Limit.

Schlüssel oder Sätze

  • Stabile Schlüssel. An diesen Stellen steht ein stabiler, nicht lokalisierter Schlüssel: 413 batchTooLarge, 409 overwriteRequired, failed[].error und invalid[].error in den Ergebnissen der synchronen PPWR-Endpunkte, failed[].error.key in den Ergebnissen asynchroner Jobs sowie error des Jobs (ein Schlüssel oder ein JSON-String, dessen Feld key der stabile Teil ist). Die Parzellen-Endpunkte senden bei Geometrie- und Annahmefehlern neben dem Satz einen stabilen code. Werten Sie diese aus. Fehler im Format der Anfrage und Validierungs-400 tragen einen englischen Satz, auch bei Stapelimporten und PPWR — entscheiden Sie dort anhand des Statuscodes. Die Listen: Fehlerschlüssel Stapelimport, Fehlerschlüssel PPWR, Fehlercodes Parzellen.
  • Sätze. Bei den übrigen Endpunkten (z. B. beim Anlegen eines einzelnen Artikels, Lieferanten oder einer Bestellung) ist error ein englischer Satz. Sein Wortlaut kann sich ändern — entscheiden Sie anhand des Statuscodes (und warnings[].type) und protokollieren Sie den Satz.

Rate-Limit

Alle /api-Pfade teilen sich ein Limit: 1000 Anfragen pro 60 Sekunden je Client-IP-Adresse (festes Zeitfenster). Es greift, bevor die Anfrage die Anwendung erreicht. Ein separates Limit je Schlüssel gibt es nicht. Über dem Limit erhalten Sie 429 mit einem JSON-Body, dessen error ein Objekt ist:
  • Ein Retry-After-Header ist nicht garantiert. Warten Sie bis zur nächsten Minute und wiederholen Sie dann mit exponentiellem Backoff und Jitter.
  • Das Limit zählt je IP-Adresse, nicht je Schlüssel. Alle Aufrufe von einer Büro- oder Server-IP teilen es sich — auch Personen, die die Web-App aus demselben Netz nutzen.
  • Verteilen Sie geplante Jobs über die Zeit, und nutzen Sie Stapel-Endpunkte statt einer Anfrage je Datensatz.

Anfragen ohne API-Schlüssel

Eine Anfrage ohne Authorization: Bearer …-Header erreicht die API nie. Der Bot-Schutz antwortet mit einer HTML-Prüfseite und Status 429. 429 mit HTML-Body beim ersten Test bedeutet also fast immer: Der Header fehlt oder ist fehlerhaft. Der Wert muss mit Bearer beginnen. Nicht wiederholen — den Header korrigieren.

Wiederholungen

Ein 500 bedeutet meist einen Fehler auf unserer Seite. Scheitert dieselbe Anfrage immer wieder, liegt die Ursache wahrscheinlich in der Anfrage selbst — hören Sie auf und prüfen Sie sie. Ein einzelnes POST /api/v1/orders, dessen orderNumber bereits existiert, antwortet mit 409, ebenso ein PATCH /api/v1/orders/{id}, der die Bestellnummer auf eine bereits vorhandene ändert. Ob eine Wiederholung ein Duplikat erzeugen kann, hängt vom Endpunkt ab:

Anfrage-Referenz (x-vercel-id)

Jede Antwort trägt einen x-vercel-id-Header. Er bezeichnet genau diese eine Anfrage. Wenn Sie den Support unter help@polygon-one.eu kontaktieren, nennen Sie:
  • den Wert von x-vercel-id,
  • den Zeitpunkt der Anfrage (mit Zeitzone),
  • Methode und Pfad (z. B. POST /api/v1/orders).
Protokollieren Sie den Header bei jedem fehlgeschlagenen Aufruf, damit Sie ihn im Bedarfsfall haben.

Limits

Zeitstempel sind ISO 8601 (z. B. 2026-10-05T08:00:00.000Z). Datensatz-ids sind UUIDs. Listen sind reine JSON-Arrays, außer bei GET /api/v1/evidence ({ "evidence": [...] }).

Nicht in v1

Folgendes ist in v1 nicht verfügbar. Jede inkompatible Änderung erscheint als /api/v2/ mit mindestens sechs Monaten Parallelbetrieb (siehe Versionierung).
  • Cursor-Paging und Gesamtzahlen — blättern Sie mit limit und offset.
  • Webhooks — Integrationen fragen ab (z. B. changedSince bei Bestellungen, Status von Import-Jobs).
  • Eine Sandbox-Umgebung — jeder Aufruf wirkt auf Ihren Live-Arbeitsbereich.
  • Offizielle SDKs — erzeugen Sie einen Client aus der OpenAPI-Spezifikation.