Verwenden Sie die Regulatory API, um produktspezifische regulatorische Compliance-Daten zu speichern, auf die Sie beim Erstellen einer Sendung verweisen können.

Die Regulatory API unterstützt Daten für die folgenden Regulierungsbehörden:

• U.S. Consumer Product Safety Commission (CPSC) – Certificate of Compliance (CoC) Daten, die als Haftungsausschluss, als Verweis auf das CPSC Produktregister oder als vollständiges Zertifikat eingereicht werden.

• Europäische Kommission – De-minimis-Entfernung – Produktkennzeichnungen, die gemäß der Abschaffung des De-minimis-Schwellenwerts in Höhe von 150 € ab Juli 2026 erforderlich sind, um Business-to-Consumer-Sendungen mit geringem Warenwert (< 150 €) in die EU zu begleiten.

Diese API übermittelt keine Einträge direkt an die US-amerikanische Zoll- und Grenzschutzbehörde (CBP), die EU-Kommission oder eine andere Behörde. 

Der Gesamt-Workflow, der die Regulatory API nutzt, sieht wie folgt aus:

1. Nutzen Sie diese API, um regulatorische Daten für ein Produkt unter einem bestimmten Regulator und Land zu speichern. Die von Ihnen anzugebenden Details können variieren. Weitere Details finden Sie unter Profil erstellen.
2. Erstellen Sie eine Sendung mit der Ship API. Stellen Sie sicher, dass jede Ware ein regulatoryDetails[] Array enthält und jedes Element regulationCode, productId und productIdType umfasst.
3. FedEx führt gespeicherte Warenprofile und Versandinformationen zusammen.
4. FedEx agiert als offizieller Importeur und reicht alle notwendigen behördlichen Dokumente in Ihrem Namen ein.

Weitere Details finden Sie unter Verwendung regulatorischer Profile und die Ship API.

Die Flexibilität der Regulatory API minimiert Integrationsoberflächen und zentralisiert die Speicherung. Jedes Profil verwendet die gleichen Felder auf oberster Ebene. Regulatorspezifische Daten werden in einem Array gespeichert, details[], dessen Elementform durch regulationCode bestimmt wird.  

Zu den erforderlichen Profilfeldern auf oberster Ebene gehören die folgenden:

• regulationCode* – Die Aufsichtsbehörde, für die die Angaben gelten. Zum Beispiel: CPSC oder EU_DE_MINIMIS. Der Wert dieses Feldes definiert die Elementform für detaillierte regulatorische Informationen. 
• productId* – Die Produktkennung des Händlers oder Kunden.
• productIdType* – Die Art der Produktkennung. Zum Beispiel: SKU, PART_NUMBER, REGISTERED_NUMBER, GTIN, UPC, EAN, MPN und OTHER. 
• countryOfImport* – Das Zielland des Imports.
• details[] – Die Form der Elemente in diesem Array ändert sich abhängig davon, welchen Regulator Sie für die Sendung gewählt haben. Für CPSC-regulierte Sendungen enthält es Disclaim- oder Referenz-Nachrichtensätze; für EU_DE_MINIMIS-regulierte Sendungen enthält es Herstellerkennungen. 

* Diese Werte werden verwendet, um die Werte im regulatoryDetails[]-Array einer Ship API-Anfrage abzugleichen, damit die Profildaten in die Sendungsdaten integriert werden können.

Tipp: Diese Struktur spiegelt einen Eintrag im Ship-API-API commodities[].regulatoryDetails[] wider. Sie können Ship-API-Anfragen aus einem gespeicherten Profil direkt ausfüllen. Das ist nützlich, wenn Sie eine einmalige Sendung haben, bei der die Profildaten veraltet sind.  

Führen Sie einen POST-Befehl an den Endpunkt Regulatory Profiles aus, um ein regulatorisches Profil zu erstellen.

Regulatorspezifische Informationen finden Sie in den folgenden Abschnitten. 

Die Regulatory API speichert die von CBP und CPSC benötigten CoC-Daten zusammen mit dem ACE-Eintrag über das PGA Message Set. Erstellen Sie ein Profil mit regulationCode = "CPSC" und countryOfImport = "US".  

Einer der folgenden drei Nachrichtensätze muss in einem Element details[] gefüllt werden.

Zusätzlich zu den erforderlichen regulationCode, productId, productIdType und countryOfImport verwenden Sie details[], um die Nachrichtensets bereitzustellen: 

• disclaimMessageSet – Die für den Haftungsausschluss benötigten Daten.

  • disclaimCode – A = Das Produkt wird nicht von der CPSC reguliert; B = Daten sind laut den Richtlinien der Behörde nicht erforderlich. 
  • intendedUseCode – Basiscode + Untercode. Zum Beispiel: "130.003". Weitere Informationen finden Sie unter Codes für den Verwendungszweck.
  • intendedUseDescription – Freitext. Nur dann erforderlich, wenn intendedUseCode = "980.000" (Für andere Verwendungszwecke).

• referenceMessageSet – Die für die Referenz benötigten Daten.

  • productVersion – die Versionskennung des Produktzertifikats, die derzeit im CPSC-Produktregister dem Zertifikat zugeordnet ist. 
  • certificateId – Die Zertifizierungs-ID, die Ihnen vom CPSC Product Registry ausgestellt wurde.

• fullMessageSet – Vollständige Zertifikatsdaten. Vollständige Objekt- und Feldbeschreibungen, Details und Beispiele finden Sie in den Informationen zu regulatorischen Endpunkten. Zu den Primärdaten gehören: 

  • productDetails
  • manufacturerDetails
  • lotDetails
  • certifierEntity
  • pointOfContact
  • citationDetails

Hinweis: Einträge im CPSC-Produktregister müssen Sie direkt bei der CPSC verwalten. Diese API verweist auf CPSC-Register-IDs für Referenzeinreichungen, erstellt jedoch keine CPSC-Registereinträge, liest oder aktualisiert sie nicht.

Ein intendedUseCode ist ein sechsstelliger Code (###.###), der CBP und den zuständigen Behörden mitteilt, wofür das importierte Produkt verwendet werden soll. Die Codes werden von CBP in Anhang R des ACE CATAIR definiert. CPSC betrachtet nur eine bestimmte Teilmenge dieser Codes als gültig für seine eFiling-Einreichungen, abhängig vom Nachrichtensatz. Dieses Feld ist immer erforderlich, wenn disclaimMessageSet ausgefüllt ist. 

CPSC erkennt acht Grundcodes: 081, 090, 100, 130, 155, 940, 970 und 980.

Base 130 ist der am häufigsten verwendete Basiscode für CPSC, da der Zuständigkeitsbereich der Behörde Konsumgüter umfasst. Bei einer vollständigen Einreichung dürfen nur die Codes 130.000 bis 130.006 verwendet werden. Disclaim A kann jeden beliebigen 130-Untercode außer 130.001–130.005 (d. h. 130.000 oder 130.006) verwenden. Disclaim B darf nur 130.006 verwenden.

Die Regulatory API unterstützt die Datenverpflichtungen, die durch die Abschaffung der De-minimis-Schwelle von 150 € eingeführt wurden. Um ein Profil zu erstellen, legen Sie regulationCode = EU_DE_MINIMIS fest, countryOfImport auf einen beliebigen EU27-Mitgliedstaat und geben Sie die regulatorischen Details für die Ware an. 

Das Feld productId ist Ihre alphanumerische Produktkennung. Die EU behandelt dies als Händler-Art.-Nr. für die Sendung.

Zusätzlich zu den erforderlichen regulationCode, productId, productIdType und countryOfImport verwenden Sie details[], um Folgendes bereitzustellen: 

• merchantProductId – Die Produktkennung des Händlers. Dies unterscheidet sich von productId, wenn Sie separate Händler- und Art.-Nr.-basierte Kennungen verwenden; andernfalls setzen Sie dies auf productId.
• nonStandardManufacturerProductId – Die interne Art.-Nr. oder ID des Herstellers. Zum Beispiel: SH123456-L. 
• standardManufacturerProductId – Eine Standardkennung wie GTIN, UPC oder EAN. Zum Beispiel: 01233456789012. Verwenden Sie die Zeichenfolge "NA", wenn das Produkt keine Standardkennung hat.

Die API gibt eine nicht blockierende REGP_EU_MISSING_IDENTIFIERS-Warnung aus, wenn ein EU_DE_MINIMIS-Profil ohne Befüllung eines der drei Identifikatoren gespeichert wird. 

Sie können regulatorische Daten, die von der Regulatory API gespeichert werden, aus der Ship API abrufen. Details aus den Regulatory-Profilen werden nach der Erstellung der Sendung in den Downstream-Prozess integriert. 

Zu den gängigen Workflows, die die Ship API und/oder die Regulatory API nutzen, gehören:

1. Ein profilorientierter Ansatz. Registrieren Sie jedes Produkt einmal mit der Regulatory API und geben Sie dann nur productID + productIdType + regulationCode in regulatoryDetails[] für Waren in Ihrer Sendung an. Die Details aus dem registrierten Profil werden in die Sendung übernommen. 

2. Ein reiner Inline-Ansatz. Jede Ware in Ihrer Sendung enthält productId + productIdType + regulationCode + vollständig ausgefüllte details[]. Vollständige CPSC-Daten können nicht inline übertragen werden; dieses Muster ist auf den Ausschluss von und Verweis auf CPSC-Nachrichtensätze und den EU_DE_MINIMIS-Regulator beschränkt.

3. Ein hybrider Ansatz. Für eine bestimmte Sendung können Sie die vorhandenen Regulatory API-Daten überschreiben. Schließen Sie productId + productIdType + regulationCode ein und wählen Sie details[] aus. Inline-Detaildaten überschreiben alle Daten, die von der Regulatory API gespeichert werden. Alle Detaildaten, die nicht in den Inline-Details der Sendung enthalten sind, aber im Profil vorhanden sind, werden nach Erstellung der Sendung zusammengeführt.