Utilisez l’API Regulatory pour stocker les données de conformité réglementaire par produit que vous pouvez référencer lors de la préparation d’un envoi.

L’API Regulatory prend en charge les données pour les organismes de réglementation suivants :

• U.S. Consumer Product Safety Commission (CPSC) : données du certificat de conformité (CoC) soumises sous forme de clause de non-responsabilité, de référence au registre des produits de la CPSC ou de certificat complet.

• Commission de l’Union européenne — suppression du seuil de minimis : identifiants de produits requis dans le cadre de la suppression par l’UE du seuil de minimis de 150 €, effective en juillet 2026, pour accompagner les envois d’entreprise à consommateur de faible valeur (< 150 €) entrant dans l’UE.

Cette API ne dépose pas directement de déclarations auprès de l’US Customs and Border Protection (service américain des douanes et de la protection des frontières, CBP), de la Commission européenne ou de toute autre autorité. 

Le flux de travail global qui utilise l’API Regulatory se déroule comme suit :

1. Utilisez cette API pour stocker les données réglementaires d’un produit pour un organisme de réglementation et un pays spécifiques. Les informations que vous devez fournir peuvent différer. Pour plus d’informations, consultez la section Création d’un profil.
2. Créez un envoi à l’aide de l’API Ship. Assurez-vous que chaque article comporte un tableau regulatoryDetails[] et que chaque élément inclut les éléments regulationCode, productId et productIdType.
3. FedEx fusionne les profils d’articles stockés et les informations d’envoi.
4. FedEx agit en tant qu’importateur officiel et dépose tous les documents réglementaires nécessaires en votre nom.

Pour plus d’informations, consultez la section Utilisation des profils réglementaires et de l’API Ship.

La flexibilité de l’API Regulatory réduit les surfaces d’intégration et centralise le stockage. Chaque profil utilise les mêmes champs de premier niveau. Les données spécifiques au régulateur sont stockées dans un tableau details[] dont la structure des éléments est déterminée par le regulationCode.  

Les champs de profil obligatoires de premier niveau incluent les éléments suivants :

• regulationCode* : l’agence de réglementation à laquelle les informations s’appliquent. Par exemple : CPSC ou EU_DE_MINIMIS. La valeur de ce champ définit la structure de l’élément pour les informations réglementaires détaillées. 
• productId* : l’identifiant de produit du négociant ou du client.
• productIdType* : le type d’identifiant de produit. Par exemple : SKU, PART_NUMBER, GTIN, UPC, EAN, MPN et OTHER. 
• countryOfImport* : le pays de destination de l’importation.
• details[] : la structure des éléments de ce tableau change en fonction de l’organisme de réglementation que vous avez choisi pour l’envoi. Pour les envois réglementés par la CPSC, il contient les jeux de messages Disclaim ou Reference ; pour les envois réglementés par EU_DE_MINIMIS, il contient les identifiants du fabricant. 

* Ces valeurs sont utilisées pour correspondre aux valeurs du tableau regulatoryDetails[] d’une demande à l’API Ship afin que les données du profil puissent être fusionnées avec celles de l’envoi.

Conseil : cette structure reflète une entrée du tableau commodities[].regulatoryDetails[] de l’API Ship. Vous pouvez renseigner les demandes à l’API Ship en copiant directement les données depuis un profil stocké. Cela s’avère utile lorsque vous effectuez un envoi ponctuel pour lequel les informations du profil ne sont pas à jour.  

Envoyez une requête POST au point de terminaison Profils réglementaires pour créer un profil réglementaire.

Pour les informations propres au régulateur, reportez-vous aux sections suivantes. 

L’API Regulatory stocke les données CoC exigées par le CBP et la CPSC aux côtés de l’entrée ACE via le jeu de messages PGA. Créez un profil où regulationCode = "CPSC" et countryOfImport = "US."  

L’un des trois jeux de messages suivants doit être renseigné dans un élément details[].

En plus des champs obligatoires regulationCode, productId, productIdType et countryOfImport, utilisez le tableau details[] pour fournir les jeux de messages :  

• disclaimMessageSet : les données nécessaires pour la clause de non-responsabilité.

  • disclaimCode : A = le produit n’est pas réglementé par la CPSC ; B = les données ne sont pas requises selon les directives de l’agence. 
  • intendedUseCode : code de base + sous-code. Par exemple : "130.003". Pour plus d’informations, consultez la section Code d’utilisation prévue.
  • intendedUseDescription : texte libre. Requis uniquement lorsque intendedUseCode = "980.000" (pour un autre usage). 

• referenceMessageSet : les données nécessaires pour la référence.

  • productVersion : l’ID de la version du certificat de produit actuellement associé au certificat dans le registre des produits de la CPSC. 
  • certificateId : l’ID du certificateur qui vous a été délivré par le registre des produits de la CPSC.
  • registryProductId : l’ID du produit qui vous a été délivré par le registre des produits de la CPSC.

• fullMessageSet : données complètes du certificat. Reportez-vous aux informations du point de terminaison réglementaire pour obtenir les descriptions complètes des objets et des champs, les informations et les exemples. Les données principales incluent :

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

Remarque : vous devez gérer les entrées du registre des produits de la CPSC directement avec la CPSC. Cette API référence les ID de registre de la CPSC pour les dépôts de référence, mais ne crée, ne lit, ni ne met à jour les enregistrements du registre de la CPSC.

Un intendedUseCode est un code à six chiffres (###.###) qui indique au CBP et aux agences concernées l’usage auquel le produit importé est destiné. Les codes sont définis par le CBP dans l’annexe R de l’ACE CATAIR. La CPSC considère qu’un sous-ensemble spécifique de ces codes est valide pour ses soumissions de dépôt électronique, selon le jeu de messages. Ce champ est toujours obligatoire lorsque disclaimMessageSet est renseigné. 

La CPSC reconnaît huit codes de base : 081, 090, 100, 130, 155, 940, 970 et 980.

Base 130 est le code de base le plus utilisé pour la CPSC, car le champ d’action de l’agence concerne les produits de consommation. Les codes 130.000 à 130.006 sont les seuls à pouvoir être utilisés pour une soumission complète. La clause Disclaim A peut utiliser n’importe quel sous-code 130 sauf 130.001–130.005 (c.-à-d. 130.000 ou 130.006). La clause Disclaim B peut uniquement utiliser 130.006.

L’API Regulatory prend en charge les obligations de données introduites par la suppression par l’UE du seuil de minimis de 150 €. Pour créer un profil, définissez regulationCode = EU_DE_MINIMIS, countryOfImport pour n’importe quel État membre de l’UE27, et  incluez les informations réglementaires pour l’article. 

Le champ productId correspond à votre identifiant de produit alphanumérique. L’UE traite cette information comme le SKU du commerçant pour l’envoi.

En plus des champs obligatoires regulationCode, productId, productIdType et countryOfImport, utilisez le tableau details[] pour fournir : 

• merchantProductId : l’identifiant de produit du commerçant. Il est distinct de productId si vous utilisez des identifiants séparés au niveau du commerçant et du SKU. Si ce n’est pas le cas, définissez-le comme étant égal au productId.
• nonStandardManufacturerProductId : le SKU ou l’ID interne du fabricant. Par exemple : SH123456-L. 
• standardManufacturerProductId : un identifiant standard tel que GTIN, UPC ou EAN. Par exemple : 01233456789012. Utilisez la chaîne littérale « NA » lorsque le produit ne possède pas d’identifiant standard.

L’API émet un avertissement non bloquant REGP_EU_MISSING_IDENTIFIERS lorsqu’un profil EU_DE_MINIMIS est stocké sans qu’aucun des trois identifiants ne soit renseigné. 

Vous pouvez référencer les données réglementaires stockées par l’API Regulatory depuis l’API Ship. Les informations des profils réglementaires sont intégrés à l’envoi en aval, après la création de l’envoi. 

Les flux de travail courants qui exploitent l’API Ship et/ou l’API Regulatory incluent :

1. Une approche axée d’abord sur le profil. Enregistrez chaque produit une seule fois à l’aide de l’API Regulatory, puis indiquez uniquement productId + productIdType + regulationCode dans le tableau regulatoryDetails[] pour les articles de votre envoi. Les informations du profil enregistré sont alors fusionnées dans l’envoi. 

2. Une approche intégrée uniquement. Chaque article de votre envoi comprend productId + productIdType + regulationCode + le tableau details[] entièrement renseigné. Les données CPSC complètes ne peuvent pas être transmises de manière intégrée ; ce modèle est limité aux jeux de messages de clause de non-responsabilité et de référence de la CPSC ainsi qu’au régulateur EU_DE_MINIMIS.

3. Une approche hybride. Pour un envoi particulier, vous pouvez remplacer les données existantes de l’API Regulatory. Incluez productId + productIdType + regulationCode + certains éléments de details[]. Les données intégrées remplacent toutes les données stockées par l’API Regulatory. Toutes les données de détails qui ne sont pas incluses dans les informations intégrées de l’envoi, mais qui sont présentes dans le profil, sont fusionnées après la création de l’envoi.