Zum Hauptinhalt springen
Innerhalb von v1 sind Änderungen nur additiv: neue Endpunkte, neue Felder und neue optionale Parameter. Bestehende Felder werden nicht entfernt oder umbenannt (siehe Versionierung). Ihr Client muss unbekannte Felder ignorieren. Inkompatible Änderungen erscheinen ausschließlich als /api/v2/. Mit Geändert markierte Einträge beschreiben eine Verhaltensänderung, auch eine, die eine bisher angenommene Anfrage ablehnt; lesen Sie diese, bevor Sie eine Integration aktualisieren.

​
2026-10-20

  • Neu: ccEmails (max. 10) wird jetzt auch beim einzelnen Anlegen eines Lieferanten mit POST /api/v1/suppliers unterstützt. Diese Kontakte stehen bei jeder E-Mail an den Lieferanten in Kopie; eine Adresse, die mit email übereinstimmt, wird ignoriert, eine ungültige Adresse lehnt die Anfrage ab.
  • Geändert: Produktionsländer an Artikel-Lieferanten-Verknüpfungen werden beim Schreiben aus ISO-2-/ISO-3-Codes und lokalisierten Ländernamen aufgelöst und als kanonischer englischer Ländername zurückgegeben. Nicht auflösbare Alt- oder Freitextwerte bleiben unverändert erhalten.

​
2026-10-19

  • Neu: PPWR-Verpackungseinheiten liefern das optionale Feld recyclabilityReference: die Freitextquelle, auf der die Recyclingfähigkeitsklasse beruht.
  • Geändert: POST /api/v1/dds-statements teilt Lieferungen oberhalb der TRACES-Grenzen automatisch in eine DDS-Gruppe. Die 201-Antwort enthält memberIds; alle Mitglieder müssen eingereicht und validiert sein, bevor der Gruppenkopf eingereicht werden kann.
  • Neu: Nicht aufteilbare DDS-Lieferungen antworten mit 422 und dds_partition_producer_too_large oder group_volume_too_small. Die optionale manuelle Compliance-Prüfung kann ebenfalls mit 422 compliance_blocked und den blockierenden Artikeln ablehnen; dabei wird nichts geschrieben.

​
2026-10-18

  • Neu: Lieferdatum pro Position. POST /api/v1/orders (Einzelobjekt und Stapel), PATCH /api/v1/orders/{id} und GET /api/v1/orders / GET /api/v1/orders/{id} tragen lines[].deliveryDate. Ohne Datum gilt für die Zeile das deliveryDate der Bestellung (null beim Lesen).
  • Geändert: Zeilen einer Bestellung mit verschiedenen deliveryDate (Teillieferung) schlagen im Stapelimport nicht mehr mit conflictingDuplicateOrderRows fehl. Jede Position behält ihr eigenes Datum; das deliveryDate der Bestellung ist das früheste Positionsdatum.
  • Geändert: Sobald eine Position ein eigenes Datum hat, wird das deliveryDate der Bestellung aus den Positionen abgeleitet. Ein im selben PATCH gesendetes deliveryDate wird dann ignoriert (die Antwort bleibt 200). Eine Zeile ohne Datum im PATCH behält ihr gespeichertes Datum.
  • Geändert (App, EUDR): Der Bestellimport akzeptiert Teillieferungen mit einem Lieferdatum pro Zeile; der Bestell-Dialog hat ein optionales Datum pro Position.

​
2026-10-15

  • Neu: GET /api/v1/suppliers?externalSupplierId=<Nr> sucht einen Lieferanten über Ihre ERP-Lieferantennummer (exakt, Groß-/Kleinschreibung beachtet, Leerzeichen am Rand ignoriert). Die Antwort enthält höchstens einen Lieferanten.
  • Geändert: supplierName auf Artikeln wird ohne Rücksicht auf Groß-/Kleinschreibung und Leerzeichen mit Ihren Lieferanten abgeglichen; erst wenn keiner passt, entsteht ein neuer. Senden Sie nach Möglichkeit supplierId.
  • Neu: ccEmails (max. 10) im Lieferanten-Stapelimport: weitere Kontakte, die bei jeder E-Mail an den Lieferanten in Kopie stehen. Additiv — vorhandene Adressen bleiben. Das Job-Ergebnis (kind: suppliers) meldet sie in contactsAdded.
  • Veraltet: Das Lieferantenfeld status (data_incomplete, data_complete, dds_submitted) wird nicht mehr gepflegt und in der App nicht mehr angezeigt. Das Feld bleibt in v1 erhalten; lesen Sie für den Compliance-Status articles[].complianceResults.
  • Geändert: Eine DDS, die gelöscht wurde, bevor sie bei TRACES eingereicht war, gibt ihre Bestellungen frei: hasDds=true liefert sie nicht mehr, hasDds=false schon, und ihre ddsReferences sind leer.
  • Geändert: heavyMetalsValueKind kennt den Wert measured_upper_bound: eine Obergrenze, die aus den Einzelmetall-Ergebnissen eines Prüfberichts berechnet wurde (ein Messergebnis, keine Lieferantenerklärung).
  • Geändert: importFormat an Parzellen kann kml oder kmz sein. degradation bedeutet ein offenes Degradationsrisiko (nur Holz), nicht mehr jeden erkannten Befund.

​
2026-10-13

  • Geändert: GET /api/v1/dds-statements und GET /api/v1/dds-statements/{id}: articles[].volume, articles[].remainingVolume, totalVolume und totalRemainingVolume können null sein. Das betrifft nur externe (vorgelagerte) Erklärungen, deren Referenz ohne Menge angegeben wurde. Eine Gesamtsumme null bedeutet: Mindestens eine Zeile hat keine Menge. Ihre eigenen Erklärungen tragen immer eine Menge. Behandeln Sie null als „nicht angegeben“, nie als 0.
  • Geändert (App, EUDR): Lieferanten geben eine vorgelagerte DDS nur mit Referenz- und Verifizierungsnummer an; eine Referenz gilt für alle ausgewählten Artikel. Die Menge pro Artikel ist optional, im Lieferantenportal und unter „Externe DDS verknüpfen“.
  • Neu: Die Komponenten in GET /api/v1/ppwr/units/{id} tragen heavyMetalsValueKind, wie GET /api/v1/ppwr/components.
  • Geändert: heavyMetalsValueKind kennt den Wert below_detection: Alle vier Schwermetalle wurden nicht nachgewiesen. heavyMetalsMgPerKg ist dann null (nie 0), und der Wert gilt als konform. Behandeln Sie null zusammen mit heavyMetalsValueKind, nicht als „unbekannt“ allein.
  • Geändert (App, PPWR): Schwermetalle: „alle vier nicht nachgewiesen“ wird als „nicht nachgewiesen — konform“ angezeigt, nie als 0.
  • Geändert (App, PPWR): Masse, Abmessungen, Prüfmethoden und ein gedrucktes „n.d.“ für die Schwermetallsumme werden aus einem Dokument automatisch übernommen, wenn das Dokument sie eindeutig druckt (beschriftet, mit Einheit und Achse); alles andere wartet auf Ihre Prüfung. Eine Gesamtmasse, die den Inhalt enthalten kann, wartet; eine Verpackungsart aus einem Dokument braucht immer einen Klick.
  • Geändert (App, PPWR): Eine einfache PFAS-Erklärung („PFAS-frei“, „enthält keine PFAS“, „PFAS werden nicht absichtlich zugesetzt“, „… bestätigt, dass …“) wird automatisch übernommen. Eine Ausnahme, eine Fußnote, ein genannter Stoff, eine Einschränkung („weitgehend“, „nach bestem Wissen“) oder ein Laborergebnis wartet weiter auf Ihre Prüfung.
  • Geändert (App, PPWR): Eine gedruckte Prüfmethode (z. B. „IEC 62321-5:2013“) wird für sich übernommen — auch neben einem Schwermetallwert, den der Lieferant selbst eingetragen hat; der Wert selbst wird nie überschrieben.
  • Korrigiert (App, PPWR): Lange Laborberichte werden vollständig gelesen, statt an der Antwortlänge zu scheitern. Ein Grenzwert einer anderen Vorschrift (z. B. RoHS, Blei 1000 mg/kg) wird nicht mehr als PPWR-Schwermetallgrenzwert vorgeschlagen.
  • Geändert (App, EUDR): Rechts- und Nachweisdokumente: Daten, Parteien, Referenznummern und Flächen werden nur eingetragen, wenn das Dokument sie unter einer erkannten Beschriftung oder in einem bestätigenden Satz druckt; eine Selbstbestätigung („X bestätigt, dass …“) nennt X als Aussteller, nie als Inhaber. Einen Wert, den das Dokument druckt, dessen Form unsere Regeln aber nicht bestätigen können, prüft die KI am Textauszug: Er wird nur eingetragen, wenn der Auszug ihn ausdrücklich nennt, sonst wartet er auf Ihre Prüfung.
  • Geändert (App, EUDR): Ein Rechts- oder Nachweisdokument wird einmal je Datei gelesen und für jede Artikelkopie nach festen Regeln beurteilt. Die Analyse ist schneller, und Kopien derselben Datei im selben Kontext erhalten dasselbe Ergebnis. Der gedruckte Inhaber wird mit dem Lieferanten und den angegebenen Erzeugern abgeglichen, auch über Übersetzungen und Umschriften; passt er zu keiner Partei, blockiert das Dokument. Lässt das Dokument offen, ob die genannte Firma der Inhaber ist, entsteht ein Prüfhinweis statt einer Blockade. Die Zertifizierungsstelle ist nie der Inhaber eines Zertifikats. Weicht das erkannte Zertifizierungssystem vom angegebenen ab, ist das ein Prüfhinweis, keine Blockade.
  • Geändert (App, EUDR): Ein Rechtsdokument gilt als abgelaufen, wenn sein gedrucktes Ablaufdatum vor dem Ende des Produktionszeitraums des Artikels liegt; ist kein Produktionszeitraum angegeben, wenn es vor dem heutigen Tag liegt.
  • Korrigiert (App, EUDR): Ein Dokument, das als Nachweis zu einem Geo-Risiko für mehrere Parzellen eingereicht wird, wird für jede Parzelle gegen deren eigenes Land und deren eigenen Rohstoff geprüft. Bisher konnte das Ergebnis einer Parzelle für eine andere übernommen werden. Ein gedruckter Gültigkeitszeitraum zählt bis zu seinem letzten Datum.
  • Geändert (App, EUDR): Rechtskonformität: Kategorien, für die kein Nachweis erforderlich ist oder deren Anforderung bereits erfüllt ist, zeigen abgelehnte Dokumente nicht mehr als offenen Punkt. Das Dokument bleibt sichtbar als „Optionaler Nachweis – nicht verwendet“ bzw. „Nicht verwendet – Anforderung bereits erfüllt“. Lieferanten erhalten für solche Dokumente keine „Beheben“-Hinweise mehr.
  • Geändert (App): Alle Dokumente werden mit Mistral OCR gelesen; PDFs bis 120 Seiten erhalten die volle Texterkennung (bisher 40).

​
2026-10-09

  • Neu: GET /api/v1/readiness?resourceType&resourceId&action beurteilt eine Ressource für genau eine Aktion (eudr.dds_draft.create, eudr.dds.submit, ppwr.supplier_reply.submit, ppwr.declaration.issue): Zustand, Befunde (höchstens 100) und die nächsten erlaubten Schritte (höchstens 20). Eine Momentaufnahme zur Erklärung, nie eine Freigabe für einen späteren Schreibvorgang. Fremde und fehlende Ressourcen antworten mit 404, eine nicht unterstützte Kombination mit 400 not_supported.
  • Neu: GET /api/v1/ppwr/article-units?articleId|orderId listet die Verpackungseinheiten, die mit genau einem Artikel oder einer Bestellung verknüpft sind, seitenweise per cursor (packaging:read).
  • Neu: Der MCP-Server bietet Schreibwerkzeuge: Artikel, Lieferanten und Bestellungen anlegen, Bestellungen aktualisieren, DDS-Entwürfe anlegen, externe DDS-Metadaten aktualisieren sowie PPWR-Komponenten und -Verpackungseinheiten anlegen oder aktualisieren und verknüpfen — dazu die Lesewerkzeuge getReadiness und listPpwrArticleUnits. Kein Löschen, keine Einladung, keine TRACES-Einreichung. Siehe KI-Assistenten (MCP).

​
2026-10-07

  • Neu: Die öffentliche API nimmt OAuth-2.1-Zugriffstoken an, die Polygon One für eine autorisierte Anwendung im Namen eines Benutzers ausstellt (Authorization Code + PKCE, dynamische Client-Registrierung über /.well-known/oauth-protected-resource). Das Token trägt die Rolle und die Berechtigungen dieses Benutzers, nicht die Berechtigungen eines API-Schlüssels. Ein Zustimmungsbildschirm zeigt die Anwendung und den angefragten Zugriff.
  • Neu: MCP-Server unter https://app.polygon-one.com/api/mcp für Claude, ChatGPT und Copilot Studio: 20 nur lesende Werkzeuge, eines je GET-Endpunkt der REST-API (listArticles, getOrder, listPpwrDeclarations …). Anmeldung per OAuth oder API-Schlüssel. Keine Schreibzugriffe, keine DDS-Einreichung, keine Compliance-Entscheidungen; 120 Aufrufe pro Minute je Benutzer und Client; Ergebnisse über 1 MB werden mit dem Hinweis abgelehnt, die Abfrage einzugrenzen; Datei-Downloads stehen Assistenten noch nicht zur Verfügung.
  • Geändert: Endpunkte, die für API-Schlüssel nicht verfügbar sind (Auslöser für erneute Analysen, Support-Chat, KI-Import, Partner-Logo, Administration), lehnen auch OAuth-Token ab — „maschineller Client“ meint beides.
  • Geändert: Ein Bearer-Token, das kein eudr_-Schlüssel ist, wird jetzt als OAuth-Token geprüft und antwortet bei Ungültigkeit mit 401; es fällt nicht mehr auf das Sitzungs-Cookie des Browsers zurück.
  • Geändert: Anfragen mit einem Authorization: Bearer-Header erhalten keine Erneuerung des Sitzungs-Cookies (Set-Cookie) mehr.
  • Neu: Schreibzugriffe mit einem OAuth-Token werden mit der Client-ID der Anwendung im Audit-Log festgehalten (metadata.oauthClientId); eine PPWR-Übernahme über ein OAuth-Token erhält die Feldherkunft api, wie eine Übernahme über einen API-Schlüssel.
  • Neu: POST /api/v1/orders/{id}/origin-confirmation nimmt die ausgewählten supplierArticleIds der Bestellung an, nachdem alle aktuellen Parzellen hochgeladen sind, und reiht die Bestätigung dieser aktuellen Herkunftsdaten durch den Lieferanten ein (202). Daten früherer Bestellungen werden nicht übernommen, die Urheberschaft des Käufers bleibt erhalten. Siehe Herkunft vom Lieferanten bestätigen lassen.
  • Korrigiert: Zwei Stapelimporte (oder ein Import und eine Bearbeitung in der App), die gleichzeitig die Zeilen derselben Bestellung neu schreiben, hinterlassen die Bestellung nicht mehr mit den Zeilen beider. Der letzte Schreibvorgang gewinnt; die Zeilen einer Bestellung sind immer genau die einer Anfrage. Senden Sie dieselbe orderNumber nie in zwei gleichzeitig laufenden Anfragen.
  • Geändert: PATCH /api/v1/plots/{id} leitet die Rohstoffgruppe aus den neuen Verknüpfungen ab: Eine Parzelle ohne Gruppe oder mit non_relevant übernimmt die Gruppe ihrer neuen Verknüpfungen wie beim Anlegen (wood, sobald eine davon Holz ist); eine ausdrücklich gesetzte Gruppe ändert sich nie. Eine Parzelle, die danach wood ist, braucht eine Holzart mit wissenschaftlichem Namen — gespeichert oder im neuen optionalen Feld species mitgesendet —, sonst 400 plot_species_required. Eine Parzelle, deren Gruppe sich nach ihrer Analyse geändert hat, wird erneut analysiert.
  • Neu (App): Ein abgelaufener Einladungslink eines Lieferanten erscheint als „Abgelaufen“ auf der Lieferantenkarte, im Fortschrittsbereich und auf den Wartekarten, mit einem „Erneut senden“, das die richtige Einladung wählt. Die Erinnerung nach 7 Tagen belebt eine abgelaufene EUDR-Einladung wieder, statt sie zu überspringen.
  • Neu (App): Kritische Antworten im Fragebogen sieht der Lieferant vor dem Absenden und der Käufer hinter der roten Markierung; ein fehlendes Fragebogen-Land wird benannt (Chip, Lückenbereich, Ansicht, Artikeltabelle).
  • Geändert (App): Eine Aktualisierungsanfrage, die Sie zu einem Fragebogen senden, nennt die Frage und öffnet das Formular des Lieferanten an dieser Stelle; vom System gesendete Anfragen bleiben unverändert.
  • Geändert (App): Der Eintrag zur Käuferprüfung im Verlauf nennt den Abschnitt und die Länder; die Lückenkarte zeigt Ihre eigene Anfrage nie als Antwort des Lieferanten.
  • Geändert (Risiko-Engine; gespeicherte Ergebnisse ändern sich erst bei einer erneuten Analyse): Holz-Parzellen nehmen auf jedem Zweig den Holz-Pfad; wiederkehrende Störungsalarme allein stützen HIGH nur, wenn der Wald von 2020 mindestens 0,5 ha und die Alarmfläche mindestens 0,18 ha groß ist.
  • Neu (App): Lieferanten, deren EUDR-Artikel importiert wurden, bevor die Automatisierung „Auto-Einladung“ eingeschaltet war, und die nie eingeladen wurden, werden durch einen täglichen Nachlauf und beim Einschalten eingeladen.
  • Geändert — inkompatibel für Integrationen, die eine geschätzte Größe senden: POST /api/v1/evidence/upload-url und POST /api/v1/ppwr/documents/upload-url signieren fileSize in die uploadUrl. Der PUT muss genau fileSize Bytes senden, sonst lehnt der Speicher ihn mit 403 ab (bisher wurde fileSize nur beim Ausstellen der URL geprüft). fileSize muss eine ganze Zahl größer als 0 sein; 0 oder ein Bruch antwortet mit 400 "Invalid file size.". Senden Sie die exakte Bytezahl der Datei.
  • Neu (dokumentiert): POST /api/v1/evidence nimmt reuseS3Key: Der s3Key aus einer früheren erfolgreichen Antwort hängt dieselbe gespeicherte Datei an einen weiteren Lieferantenartikel, ohne erneuten Upload. Genau eine Quelle (file, die uploaded*-Felder oder reuseS3Key), sonst 400; ein reuseS3Key, der nicht Ihrem Unternehmen gehört, antwortet mit 403.
  • Geändert: POST /api/v1/articles/bulk-delete, POST /api/v1/suppliers/bulk-delete, POST /api/v1/orders/bulk-delete, PUT /api/v1/articles/{id}/inputs und POST /api/v1/articles/{id}/primary-producer antworten auf einen Body, der kein JSON-Objekt ist, mit 400 { "error": "Invalid JSON body" } statt mit 500.

​
2026-10-06

  • Neu: Die API-Referenz dokumentiert alle Felder, Beispiele und Fehlerantworten (inkl. 429).
  • Geändert: Eine fehlerhafte ID im Pfad antwortet mit 400 (oder dem 404 des Endpunkts) statt mit 500.
  • Geändert: Ein Anfrage-Body, der kein JSON-Objekt ist, antwortet mit 400 statt mit 500.
  • Geändert: Validierungsfehler liefern details auf jedem Endpunkt als Liste von Problemen (path, message, code).
  • Geändert: Eine abgelehnte Nachweisdatei antwortet mit error (der Schlüssel message bleibt erhalten).
  • Geändert: Das Löschen eines Mitglieds einer gruppierten DDS antwortet mit 409 GROUP_MEMBER_DELETE_REFUSED statt mit 500.
  • Geändert: Ein einzelnes POST /api/v1/orders speichert lines[].positionId; gemischte oder wiederholte Positions-IDs antworten mit 400 und code (positionIdMixed, duplicatePositionId). PATCH antwortet ebenso.
  • Geändert: Ein einzelnes POST /api/v1/orders mit einer bereits vorhandenen Bestellnummer antwortet mit 409 statt mit 500.
  • Geändert: GET /api/v1/suppliers liefert bei eingebetteten Compliance-Ergebnissen die internen Felder deletedAt und retentionUntil nicht mehr.
  • Neu (dokumentiert): Komponenten in GET /api/v1/ppwr/units/{id} tragen acht weitere Attribute (Quelle und Methode des Rezyklatanteils, Kontaktempfindlichkeit, Schwermetall- und PFAS-Felder).
  • Geändert: Eine Bestellung mit einem Artikel, der noch auf die manuelle Prüfung der EUDR-Relevanz wartet, steht auf open, nicht auf notRelevant oder done. lines[].article.needsManualCheck zeigt, welche Zeile betroffen ist.
  • Geändert: Das Ändern der Nummer einer Bestellung auf eine bereits vorhandene antwortet mit 409 (bisher 500).
  • Geändert: Parzellen (nur API-Schlüssel): Ein Wert für supplierArticleIds, der keine Liste ist, antwortet mit 400 plot_supplier_article_ids_invalid (bisher: Parzelle ohne Verknüpfungen angelegt).
  • Geändert: Parzellen (nur API-Schlüssel): Ohne commodityGroup antwortet eine Parzelle, deren verknüpfte Artikel keine eindeutige Rohstoffgruppe ergeben, mit 400 plot_commodity_group_required (bisher: angelegt, Analyse fehlgeschlagen).
  • Geändert: Parzellen (nur API-Schlüssel): Die Holzarten-Regel und die Flächengrenze für Punkte verwenden die wirksame Rohstoffgruppe (gesendet oder aus den Verknüpfungen abgeleitet). Eine Wiederholung für eine Parzelle, die über ihre Verknüpfungen Holz ist, benötigt species.
  • Geändert: PPWR-Einheiten, die das Einheiten-Kontingent des Tarifs ablehnt, erscheinen in failed mit packagingUnitQuotaReached (bisher in skipped); eine abgelehnte Einheit legt nichts an, auch nicht ihren Lieferanten.
  • Geändert: Bei PPWR-links behält ein leeres massGrams mit formatReference die gespeicherte Masse je Größe (bisher: gelöscht).
  • Geändert: Das Anhängen eines PPWR-Dokuments antwortet mit 201 und extractionQueued: false, wenn die Analyse nicht eingereiht werden konnte (bisher 500, nachdem das Dokument gespeichert war).
  • Geändert: lang des Konformitätserklärungs-PDFs wird ohne Beachtung der Groß-/Kleinschreibung abgeglichen; ein nicht unterstützter Wert antwortet mit 400 und nennt die unterstützten Codes (bisher: Deutsch).
  • Geändert: Das PDF der technischen Dokumentation prüft lang wie das Konformitätserklärungs-PDF: Ein nicht unterstützter Wert antwortet mit 400 (bisher: Deutsch).
  • Geändert: Im PPWR-Import wird eine Größenzeile mit leerer Lieferanten-Zelle unter einer Einheit, die einen Lieferanten nennt, angenommen (bisher conflictingSizeRow); eine Größenzeile behält ihren eigenen Fehler, wenn ihre Einheit fehlschlägt.
  • Neu: POST /api/v1/ppwr/mengenmeldung/reports verwendet die für den Arbeitsbereich gespeicherte LUCID-Betreiber-ID, wenn die Anfrage sie weglässt, und gibt die verwendete systemOperatorId zurück.
  • Geändert: Die fünf PPWR-Ja/Nein-Kennzeichen (contactSensitive, foodContact, placedUnderOwnBrand, modifiesConformity, reusable) lassen sich über den Import ausschalten: Ein angegebenes no wird gespeichert; ein leerer Wert behält den gespeicherten Wert. Eine Größenzeile, die ihrer Einheitenzeile widerspricht, schlägt mit conflictingSizeRow fehl.
  • Geändert: POST /api/v1/ppwr/formats fragt nach, bevor vorhandene Größen überschrieben werden: 409 mit error: "overwriteRequired" und confirmUpdateCount; senden Sie die Anfrage erneut mit overwrite: true (wie bei Einheiten und Komponenten).
  • Geändert: GET /api/v1/ppwr/declarations?changedSince= liefert auch eine Erklärung, die ersetzt wurde oder deren activeSpecIds kleiner wurde, weil eine neuere Erklärung eine Einheit übernommen hat.
  • Neu: Erklärungen tragen supersededAt.
  • Geändert: pdfUrl einer Erklärung ist null, wenn die Datei nicht ausgeliefert werden kann.
  • Geändert: Mengenmeldung: Eine Verpackungseinheit zählt ihre Menge ohne Größe ODER ihre Mengen je Größe, nie beides. Eine Einheit mit beidem blockiert die Meldung mit placement_both_levels, bis eine Ebene geleert ist (das gilt auch für Mehrweg-Einheiten). Eingetragene Mengen haben Vorrang vor dem Mengen-Feed, der Feed hat Vorrang vor Mengen aus Bestellungen.
  • Geändert: Mengen-Feed: Feed-Mengen werden bei jedem Lesen berechnet — Änderungen an Verknüpfungen und SKUs wirken ohne erneute Übermittlung; sie werden je Größe platziert, wenn jede verknüpfte SKU einer Einheit mit mehreren Größen eine Größe nennt, sonst auf der Einheit. derived / cleared / conflicts im Job-Ergebnis zählen Verpackungseinheiten der betroffenen Zeitraum-/Markt-Bereiche. Jede Übermittlung wird im Audit-Log festgehalten (ein Eintrag je Übermittlung, mit Job-ID und API-Schlüssel). Übermittlungen in einen Arbeitsbereich werden nacheinander verarbeitet, sodass zwei Übermittlungen in denselben Zeitraum und Markt keine Mischung aus beiden mehr hinterlassen können.
  • Geändert: Das Erzeugen einer Mengenmeldung ersetzt nur die vorherige Meldung desselben Typs für dieses Jahr und diesen Markt (eine HJM1 markiert eine eingereichte HMM1 nicht mehr als ersetzt). Versionsnummern zählen je Meldungstyp.
  • Neu: DELETE /api/v1/ppwr/tonnage?periodYear&market&zsvrCategory entfernt eine über die API übermittelte Tonnage; 404, wenn keine vorhanden ist, 409 manualOverridePresent für eine in der App eingetragene Menge.
  • Geändert: GET /api/v1/evidence berücksichtigt limit, offset und fields (sie wurden ignoriert); ein unbekanntes Feld oder limit über 1000 antwortet mit 400. Ohne diese Parameter wird wie bisher die vollständige Liste geliefert. Dokumente werden nach Hochladezeitpunkt geliefert, älteste zuerst.
  • Geändert: Eine erneute Analyse einer einzelnen Parzelle behält das vorherige Ergebnis, bis das neue geschrieben ist, auch nach einem fehlgeschlagenen Lauf (analysisStatus und assessedAt zeigen, zu welchem Lauf es gehört).
  • Geändert: Eine idempotente Wiederholung einer Parzelle mit ungültigem size antwortet mit deduplicated; der Probelauf (POST /api/v1/plots/validate) antwortet am Parzellen-Limit mit valid: false und PLOT_LIMIT_REACHED.

​
2026-10-02

  • Geändert: Legt ein Bestellstapel (POST /api/v1/orders mit einem Array) für eine Einkaufsbestellung einen Artikel an, ist dieser Artikel jetzt in jedem Arbeitsbereich eine Vorlage pro Bestellung. Die Bestellzeile zeigt auf eine eigene Kopie des Artikels mit der Nummer <internalArticleNr>#<orderNumber>; lines[].article in GET /api/v1/orders nennt diese Kopie. Verkaufsbestellungen und vorhandene Artikel bleiben unverändert.
  • Neu: PPWR-Einheiten-Zeilen nehmen material und massGrams an. Eine neue Einheit mit material und ohne componentCodes erhält eine Hauptteil-Komponente. Die Antwort enthält zusätzlich mainPartsCreated und unitsWithoutComponents.

​
2026-10-01

  • Neu: PPWR-Konformitätserklärungen lesen — GET /api/v1/ppwr/declarations, GET /api/v1/ppwr/declarations/{id} und das PDF über GET /api/v1/ppwr/declarations/{id}/pdf. GET /api/v1/ppwr/units?include=doc ergänzt je Einheit docState und activeDeclaration. Siehe Konformitätserklärungen lesen.
  • Neu: EUDR-Nachweise unter v1 — POST /api/v1/evidence/upload-url, POST /api/v1/evidence und GET /api/v1/evidence, mit den Berechtigungen evidence:read und evidence:write.
  • Neu: Artikel tragen supplierLinks ([{ supplierId, supplierArticleId }]).
  • Neu: Dokumente an PPWR-Einheiten und -Komponenten hängen — POST /api/v1/ppwr/documents/upload-url und POST /api/v1/ppwr/documents. Siehe PPWR-Dokumente hochladen.
  • Neu: Die Schlüsselvorlage ERP-Integration enthält plots:write und evidence:write. Früher angelegte Schlüssel behalten ihre Berechtigungen.
  • Geändert: Das erneute Analysieren einer Parzelle ist für API-Schlüssel nicht mehr verfügbar — POST /api/v1/plots/{id}/reanalyze antwortet mit 403 ("Not available for API keys").
  • Geändert: Ein Arbeitsbereich kann ein Parzellen-Limit und ein monatliches Parzellen-Kontingent haben. Ist eines erreicht, antwortet POST /api/v1/plots mit 409 und code: "PLOT_LIMIT_REACHED" und legt nichts an.
  • Geändert: Exporte lassen sich für einen Arbeitsbereich abschalten. Downloads wie der Parzellenbericht, das PDF der Konformitätserklärung und die Mengenmeldungs-Datei antworten dann mit 403 und code: "EXPORTS_BLOCKED".
  • Geändert: eine optionale Compliance-Prüfung für DDS-Erklärungen. Ist sie für Ihren Arbeitsbereich eingeschaltet, antworten POST /api/v1/dds-statements und POST /api/v1/dds-statements/{id}/submit mit 422, error: "compliance_blocked" und details.blockingArticles, solange Artikel nicht konform sind.

​
2026-09-30

  • Geändert: POST /api/v1/orders mit einem Objekt speichert jetzt deliveryDate. Bisher wurde der Wert angenommen und verworfen.

​
2026-09-29

  • Neu: Leitfaden zur Geo-Analyse. POST /api/v1/plots/validate prüft eine Geometrie, ohne eine Parzelle anzulegen; GET /api/v1/plots/{id}/report liefert den Parzellenbericht als PDF. Siehe Geo-Analyse über die API.
  • Neu: GET /api/v1/plots/{id} trägt ein Objekt analysis mit dem Ergebnis der Entwaldungsanalyse.
  • Geändert: POST /api/v1/plots mit einem API-Schlüssel lehnt Linien, Sammlungen, Koordinaten mit weniger als 4 Nachkommastellen und nicht reparierbare Geometrien ab — 400 mit einem code, es wird nichts geschrieben. Gespeichert wird die normalisierte Geometrie; die Antwort enthält deduplicated und warnings.
  • Geändert: plots in Artikeln, Lieferanten und DDS-Erklärungen listet eindeutige Parzellen ohne Geometrie, höchstens 1000 Einträge; plotsTruncated: true zeigt an, dass es mehr gibt. In einen Lieferanten eingebettete Artikel tragen keine Parzellen. Die Geometrie einer Parzelle liefert GET /api/v1/plots/{id}.
  • Geändert: POST /api/v1/orders mit einem Objekt lehnt eine supplierId eines anderen Unternehmens und eine Artikel-id ab, die nicht Ihrem Unternehmen gehört (400).
  • Neu: PPWR-Einheiten- und Größen-Zeilen nehmen supplierReference an (die Artikelnummer des Lieferanten).
  • Geändert: PPWR-Einheiten- und Komponenten-Zeilen mit unbekanntem supplierName legen jetzt einen Lieferanten nur mit Namen an und verknüpfen ihn (aufgeführt in suppliersCreated). Bisher wurde die Zeile ohne Lieferant gespeichert.

​
2026-09-26

  • Geändert: Jeder Listen-Endpunkt liefert ohne limit höchstens 100 Zeilen (limit höchstens 1000). Blättern Sie mit offset, bis eine Seite kürzer als limit ist. Ausnahme: GET /api/v1/evidence liefert alle Zeilen und ignoriert limit und offset.
  • Neu: Leitfaden zum Delta-Sync von Bestellungen mit changedSince. Siehe Delta-Sync.
  • Neu: optionale positionId auf Bestellzeilen (Ihre ERP-Positionsnummer). Siehe Positionen.
  • Neu: abgeleiteter Bestell-status (open, done, notRelevant) und der Filter ?status= auf GET /api/v1/orders.
  • Neu: Mit aktivierten Pro-Bestellung-Kopien kann hsCode auf Bestellzeilen eine neue Version der Artikelkopie der Bestellung anlegen.
  • Geändert: ddsReferences und der Filter hasDdsReference lassen zurückgezogene und abgelehnte DDS-Erklärungen weg.
  • Dokumentiert: hsCode und articleDescription auf Bestellzeilen wirken nur, wenn die Zeile den Artikel anlegt.

​
2026-09-24

  • Neu: versionierte Pfade /api/v1/…. Pfade ohne Version (/api/…) bleiben ein dauerhafter Alias. Siehe Versionierung.
  • Neu: Query-Parameter fields auf jedem JSON-GET-Endpunkt (außer GET /api/v1/evidence, der ihn ignoriert). Siehe Feldauswahl.
  • Neu: Die OpenAPI-Spezifikation wird aus den Anfrage- und Antwortverträgen der Anwendung erzeugt.

​
2026-09-23

  • Neu: Parzellen-API — Parzellen anlegen, lesen, verknüpfen und löschen.
  • Neu: Filter changedSince auf GET /api/v1/orders.
  • Geändert: PATCH /api/v1/dds-statements/{id} ändert nur externe DDS-Erklärungen; jede andere Erklärung antwortet mit 404.

​
2026-09-15

  • Neu: PPWR-Stammdaten zurücklesen — GET /api/v1/ppwr/units, /units/{id}, /components, /components/{id}.
  • Geändert: PATCH /api/v1/orders/{id} und PATCH /api/v1/articles/{id} ignorieren Felder, die sich nicht ändern lassen.

​
2026-09-05

  • Neu: PPWR-Verpackungsgrößen — POST /api/v1/ppwr/formats. Siehe PPWR.

​
2026-08-17

  • Neu: PPWR-Mengen-Feed (POST /api/v1/ppwr/quantities), Tonnage (POST /api/v1/ppwr/tonnage) und Mengenmeldung (/api/v1/ppwr/mengenmeldung/…). Siehe PPWR.

​
2026-07-31

  • Neu: SKUs mit PPWR-Einheiten verknüpfen — POST /api/v1/ppwr/article-links.

​
2026-07-28

  • Neu: GET /api/orders filtern und blättern — hasDdsReference, orderNumbers, limit und offset.

​
2026-07-27

  • Korrigiert: Die Basis-URL in der Referenz ist https://app.polygon-one.com.

​
2026-07-12

  • Neu: PPWR-API — Stammdaten-Intake für Komponenten, Einheiten und Verknüpfungen (POST /api/ppwr/components, /units, /links). Siehe PPWR.
  • Geändert: Stapelimporte von Artikeln, Lieferanten und Bestellungen laufen asynchron — 202 mit einer jobId, Ergebnis über GET /api/import-jobs/{jobId}. Ein einzelnes Objekt antwortet weiterhin mit 201.

​
2026-06-16

  • Neu: Duplikat- und Plausibilitätswarnungen beim Anlegen eines Artikels (409 mit warnings, überschreibbar mit acknowledgeWarnings).