Statuscodes
Fehlerformat
Fehler sind JSON mit einemerror-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[].errorundinvalid[].errorin den Ergebnissen der synchronen PPWR-Endpunkte,failed[].error.keyin den Ergebnissen asynchroner Jobs sowieerrordes Jobs (ein Schlüssel oder ein JSON-String, dessen Feldkeyder stabile Teil ist). Die Parzellen-Endpunkte senden bei Geometrie- und Annahmefehlern neben dem Satz einen stabilencode. Werten Sie diese aus. Fehler im Format der Anfrage und Validierungs-400tragen 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
errorein englischer Satz. Sein Wortlaut kann sich ändern — entscheiden Sie anhand des Statuscodes (undwarnings[].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 ohneAuthorization: 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).
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
limitundoffset. - Webhooks — Integrationen fragen ab (z. B.
changedSincebei 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.