Zum Hauptinhalt springen
Neu bei der API? Beginnen Sie mit dem Schnellstart — Ihr erster erfolgreicher Aufruf in fünf Minuten. Danach zeigen die Empfohlenen Integrationsabläufe die Reihenfolge, die wir empfehlen.

Übersicht

Die Polygon One API ermöglicht Ihnen die programmatische Verwaltung Ihrer EUDR- und PPWR-Compliance-Daten. Sie ist für die Server-zu-Server-Integration mit Ihrem ERP-System (SAP, Oracle, Microsoft Dynamics, etc.) konzipiert. Was Sie mit der API tun können:
  • Artikel — Artikel erstellen, aktualisieren und abfragen. Die EUDR-Relevanz wird automatisch anhand des HS-Codes bestimmt.
  • Lieferanten — Lieferantendaten verwalten und Lieferanten mit Artikeln verknüpfen.
  • Parzellen (EUDR) — Produktionsparzellen mit Geometrie anlegen, auslesen, mit Lieferantenartikeln verknüpfen und löschen. Die Entwaldungsanalyse läuft nach dem Anlegen automatisch.
  • Parzellenbericht und Geometrieprüfung (EUDR) — Den Parzellenbericht als PDF laden und eine Geometrie prüfen, ohne eine Parzelle anzulegen. Siehe Geo-Analyse.
  • Nachweise (EUDR) — Nachweisdateien hochladen, an einen Lieferantenartikel hängen und auflisten.
  • Bestellungen — Einkaufs- und Verkaufsbestellungen importieren (einzeln oder im Stapel). Bestellungen können automatisch DDS-Erklärungen zugewiesen werden.
  • DDS-Erklärungen — DDS-Erklärungen für die TRACES-Einreichung erstellen und verwalten.
  • Verpackungsstammdaten (PPWR) — Komponenten, Verpackungseinheiten, deren Größen und die Verknüpfungen dazwischen im Stapel anlegen und aktualisieren; Einheiten und Komponenten lassen sich einzeln und als Liste wieder auslesen.
  • Mengen-Feed (PPWR) — die in Verkehr gebrachten Mengen je SKU, Markt und Jahr übermitteln, alternativ Tonnage je Materialart.
  • Mengenmeldung (PPWR) — Berichte für LUCID und die übrigen nationalen Register erzeugen, auflisten und die Datei abholen.
  • Dokumente (PPWR) — Prüfberichte, Erklärungen und Zeichnungen hochladen und an Verpackungseinheiten und Komponenten hängen.
  • Konformitätserklärungen (PPWR) — Den DoC-Status je Einheit lesen, die Erklärungen auflisten und das PDF herunterladen.
Die Seiten der Endpunkt-Referenz (Feldbeschreibungen) sind auf Englisch.

Authentifizierung

Alle API-Endpunkte erfordern einen Bearer-Token. Generieren Sie Ihren API-Schlüssel im Polygon One Dashboard:
  1. Navigieren Sie zu Einstellungen > API-Schlüssel
  2. Klicken Sie auf API-Schlüssel erstellen
  3. Wählen Sie die erforderlichen Berechtigungen (z.B. articles:read, orders:write)
  4. Kopieren Sie den generierten Schlüssel
Schlüssel beginnen aus historischen Gründen mit eudr_. Derselbe Schlüssel funktioniert für EUDR und PPWR, sofern er die Berechtigungen hat und der Benutzer, für den er handelt, das Modul aktiviert hat. Ein persönlicher Schlüssel handelt für den Benutzer, der ihn angelegt hat; ein Unternehmensschlüssel für den ranghöchsten aktiven Benutzer des Unternehmens (in der Regel den Inhaber). Bestellungen, DDS-Erklärungen und alle PPWR-Endpunkte setzen außerdem ein Kundenkonto voraus; sonst antworten sie mit 403. Fügen Sie den Schlüssel im Authorization-Header jeder Anfrage hinzu:
API-Schlüssel sind vertrauliche Zugangsdaten für die Server-zu-Server-Kommunikation. Speichern Sie diese in Umgebungsvariablen und geben Sie sie niemals in clientseitigem Code preis.

OAuth 2.1

Die API akzeptiert außerdem OAuth-2.1-Zugriffstoken, die Polygon One für eine autorisierte Anwendung ausstellt, die im Namen eines Benutzers handelt. Das Token trägt die Rolle und die Berechtigungen dieses Benutzers (keine Schlüssel-Berechtigungen). So erhalten Sie eines: Registrieren Sie die Anwendung (Dynamic Client Registration wird unterstützt) und durchlaufen Sie den üblichen Authorization-Code-Flow mit PKCE gegen den Autorisierungsserver, den /.well-known/oauth-protected-resource nennt. Für KI-Assistenten siehe Claude, ChatGPT und Copilot verbinden.

Basis-URL

Alle API-Anfragen werden an folgende URL gerichtet:

Versionierung

Die öffentliche REST-API ist als Version 1 unter /api/v1/<Ressource> eingefroren (Artikel, Lieferanten, Bestellungen, DDS-Erklärungen, Import-Jobs, Parzellen, Nachweise, PPWR). Pfade ohne Version (/api/…) bleiben ein dauerhafter Alias von v1 — bestehende Integrationen funktionieren unverändert weiter.
  • Vertragsumfang: Nur die in dieser Referenz dokumentierten Endpunkte gehören zu v1. Andere Pfade unter diesen Präfixen können sich ändern. API-Schlüssel sind nicht Teil der API — Sie legen sie unter Einstellungen > API-Schlüssel an.
  • Nur additive Änderungen: Innerhalb von v1 werden bestehende Felder nie entfernt oder umbenannt. Neue Antwortfelder können hinzukommen — Ihr Client muss unbekannte Felder ignorieren. Unbekannte Felder in Anfragen werden angenommen und ignoriert.
  • Fehler: Der Body ist { "error": string } (optional mit details bzw. warnings), die HTTP-Statuscodes bleiben stabil. Einzige Ausnahme ist das 429 des Rate-Limits, siehe Fehler & Limits.
  • Breaking Changes erscheinen ausschließlich als /api/v2/ — mit mindestens 6 Monaten Parallelbetrieb.

Berechtigungen

Jedem API-Schlüssel werden spezifische Berechtigungen zugewiesen, die den Zugriff steuern: Im Dialog Einstellungen > API-Schlüssel sind die Berechtigungen nach Bereichen gruppiert; im EUDR-Modul gehört dazu die Gruppe Nachweise (evidence:read, evidence:write). Löschen und erneutes Analysieren von Nachweisen sind für API-Schlüssel nicht verfügbar (403). Schreibberechtigungen schließen die jeweilige Leseberechtigung ein. Ein Schlüssel mit articles:write darf also sowohl schreibende Operationen als auch GET-Anfragen für Artikel ausführen.

Antwortformat

Erfolgreiche Antworten liefern JSON-Daten direkt zurück. Listen-Endpunkte geben Arrays zurück, Einzelressourcen-Endpunkte geben Objekte zurück. Jeder Listen-Endpunkt liefert höchstens 100 Zeilen, solange limit nicht gesetzt ist (max. 1000); blättern Sie mit offset, bis eine Seite kürzer ist. Eine Ausnahme: GET /api/v1/evidence?supplierArticleId=… liefert { "evidence": [...] } mit allen Dokumenten dieses Lieferantenartikels, solange Sie weder limit noch offset senden. Mit limit/offset blättert er wie die übrigen Listen; fields wirkt wie bei jedem anderen GET. Einzelne Ressource erstellen (POST /api/v1/articles, /api/v1/suppliers, /api/v1/orders mit einem Objekt ohne rows) antwortet synchron mit HTTP 201. Die PPWR-Stapel-Endpunkte (components, units, formats, links, article-links, tonnage, quantities) erwarten immer ein Array bzw. rows — ein Einzelobjekt ist dort 400:
Stapelimporte (Array oder {"rows": [...]}) gibt es in zwei Formen — das Zeilenlimit ist das einzige Unterscheidungsmerkmal. Endpunkte mit 5.000-Zeilen-Limit (/api/v1/articles, /api/v1/suppliers, /api/v1/orders, /api/v1/ppwr/quantities) laufen asynchron und geben HTTP 202 mit einer Job-Referenz zurück:
statusUrl ist host-relativ (/api/import-jobs/…, ohne Version) — hängen Sie ihn nur an den Ursprung https://app.polygon-one.com an; er bleibt gültig. Den Fortschritt und das Ergebnis (importierte, aktualisierte, übersprungene und fehlgeschlagene Zeilen) liefert GET /api/v1/import-jobs/{jobId} — Details im Leitfaden Stapelimport (asynchron). Endpunkte mit 1.000-Zeilen-Limit (PPWR-Stammdaten /api/v1/ppwr/components, /units, /formats, /links, /article-links sowie /api/v1/ppwr/tonnage) antworten synchron mit HTTP 200 und dem Ergebnis im Body; components und units antworten mit 409 overwriteRequired, wenn ein Überschreiben bestätigt werden muss. Details auf der PPWR-Seite.

Feldauswahl (fields)

Jeder JSON-GET-Endpunkt (Listen und Einzelressourcen, EUDR und PPWR; ausgenommen Datei-Downloads wie …/mengenmeldung/{reportId}/xml) akzeptiert den optionalen Query-Parameter fields: eine kommagetrennte Liste von Top-Level-Feldern der Ressource. Die Antwort enthält dann nur diese Felder — bei Listen pro Element. Werte werden nie verändert, nur Felder weggelassen; ein optionales Feld, das an einer Ressource fehlt, bleibt auch mit fields weg.
ddsReferences lässt zurückgezogene (withdrawn) und abgelehnte (rejected) DDS-Erklärungen weg; jeder andere Status bleibt gelistet, auch Entwürfe, die noch keine referenceNumber haben. Eine zurückgezogene oder abgelehnte DDS-Erklärung fällt aus dem Array heraus, und die Bestellung passt nicht mehr auf hasDdsReference=true. Der Statuswechsel zählt für changedSince als Änderung — der Delta-Poll liefert die Bestellung erneut, mit leerem ddsReferences. Kombinieren Sie einen Delta-Poll nicht mit hasDdsReference=true: Der Filter würde genau diese Bestellung ausblenden, und Sie würden den Widerruf nie sehen. Geben Sie Ware nie auf eine Referenz frei: Die Freigabe richtet sich nur nach status bzw. danach, dass lines[].article.eudrRelevant und lines[].article.needsManualCheck im aktuellen Abruf beide false sind (siehe Bestellstatus). Regeln, alle als 400 statt stillschweigend ignoriert:
  • fields darf nur einmal übergeben werden (kommagetrennt, nicht wiederholt).
  • Die Liste darf nicht leer sein (?fields= allein wird abgelehnt).
  • Jedes Feld muss ein dokumentiertes Top-Level-Feld der Ressource sein; unbekannte Namen werden in der Fehlermeldung genannt, zusammen mit der erlaubten Liste. So kann ein später hinzukommendes Feld eine bestehende Anfrage nie unbemerkt verändern.
  • Leerzeichen um Namen werden ignoriert, Duplikate zählen einmal. Verschachtelte Auswahl (supplier.id) gibt es nicht.
Ohne fields ist die Antwort unverändert — der Parameter ist additiv innerhalb von v1.

Fehlerbehandlung

Die API verwendet Standard-HTTP-Statuscodes: Rate-Limit, Wiederholungen und Größenlimits finden Sie unter Fehler & Limits. Fehlerantworten enthalten ein error-Feld und optional details:
Bei einem Validierungsfehler ist details eine Liste von Problemen, eines je fehlerhaftem Feld: path (das Feld, als Liste von Schlüsseln), message und code, je nach Problem mit weiteren Schlüsseln.

Duplikatwarnungen

Beim Erstellen eines Artikels führt die API beratende Prüfungen durch, die statt der Erstellung ein 409 zurückgeben können:
  • Harter Konflikt (nicht überschreibbar): Ein Artikel mit derselben internalArticleNr existiert bereits. Die Antwort ist 409 mit einer error-Meldung.
  • Weiche Warnungen (überschreibbar): ein doppelter Artikelname (duplicateName) oder eine doppelte ean (duplicateEan). Die Antwort ist 409 mit einem maschinenlesbaren warnings-Array:
Um aus einer nicht-interaktiven Integration trotzdem fortzufahren, senden Sie die Anfrage erneut mit acknowledgeWarnings: true. Harte Konflikte werden durch dieses Flag niemals überschrieben.