Utilisez l’API réglementaire pour stocker les données de conformité réglementaire par produit que vous pouvez consulter lors de la création d’un envoi.

L’API réglementaire prend en charge les données des régulateurs suivants :

• Commission américaine de la sécurité des produits de consommation (CPSC) — Données du certificat de conformité (CoC) soumises à titre d’avis 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 produit requis en vertu de la suppression par l’UE du seuil de minimis de 150 €, en vigueur à partir de juillet 2026, pour accompagner les envois d’entreprise à consommateur de faible valeur (< 150 €) entrant dans l’UE.

Cette API ne soumet pas directement les déclarations auprès de l’U.S. Customs and Border Protection (CBP), de la Commission européenne ou de toute autre autorité. 

Le flux de travail global qui utilise l’API de réglementation est le suivant :

1. Utilisez cette API pour stocker les données réglementaires d’un produit sous un organisme de réglementation et un pays spécifiques. Les renseignements que vous devrez fournir pourraient varier. Pour plus de détails, veuillez consulter Créer un profil.
2. Créer un envoi en utilisant Ship API. Veillez à ce que chaque marchandise comporte un tableau regulatoryDetails[] et que chaque élément comprenne regulationCode, productId, productIdType.
3. FedEx fusionne les profils de marchandises 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 de détails, consultez utilisation des profils réglementaires et du Ship API.

La flexibilité de l’API réglementaire réduit les surfaces d’intégration et centralise le stockage. Chaque profil utilise les mêmes champs de niveau supérieur. Les données propres à chaque organisme de réglementation sont stockées dans un tableau details[], dont la structure des éléments est déterminée par regulationCode.  

Les champs de profil de niveau supérieur requis comprennent les éléments suivants :

• regulationCode* – l’agence de régulation pour laquelle les détails s’appliquent. Par exemple : CPSC ou EU_DE_MINIMIS. La valeur de ce champ définit la structure de l’élément pour les renseignements réglementaires détaillés. 
• productId* – L’identifiant de produit du marchand ou du client.
• productIdType* – Type d’identifiant de produit. Par exemple : UGS, PART_NUMBER, REGISTERED_NUMBER, GTIN, UPC, EAN, MPN et OTHER. 
• countryOfImport* – Le pays de destination de l’importation.
• details[] – La structure des éléments de ce tableau varie selon l’organisme de réglementation choisi pour l’envoi. Pour les envois réglementés par la CPSC, il contient des jeux de messages de type Disclaim ou Reference; pour les envois réglementés par EU_DE_MINIMIS, il contient des identifiants de fabricant. 

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

Conseil : Cette structure reflète une entrée dans les marchandises du Ship API [].RegulatoryDetails [] tableau. Vous pouvez remplir les requêtes Ship API en copiant directement à partir d’un profil stocké. Cette fonction est utile lorsque vous effectuez un envoi unique et que les détails du profil ne sont plus à jour.  

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

Pour obtenir des détails spécifiques aux régulateurs, consultez les sections suivantes. 

L’API réglementaire stocke les données du CoC exigées par le CBP et la CPSC avec l’entrée ACE via le PGA Message Set. 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 details[] pour fournir les jeux de messages suivants :  

• disclaimMessageSet – les données nécessaires pour l’avis de non-responsabilité.

  • disclaimCode – A = Le produit n’est pas réglementé par la CPSC; B = Les données ne sont pas requises conformément aux directives de l‘agence. 
  • intendedUseCode – Code de base + sous-code. Par exemple : « 130,003 ». Pour en savoir davantage, voir les codes d’utilisation prévus.
  • intendedUseDescription – Texte libre. Requis uniquement lorsque intendedUseCode = "980.000" (Autre utilisation). 

• referenceMessageSet – Les données nécessaires à la référence.

  • productVersion – L’identifiant de version du certificat produit actuellement associé au certificat dans le registre de produits CPSC. 
  • certificateId – Identifiant du certificateur qui vous a été attribué par le registre des produits de la CPSC.

• fullMessageSet – Données complètes du certificat. Consultez les informations sur le point final réglementaire pour obtenir des descriptions complètes des objets et des champs, des détails et des exemples. Les données principales comprennent :

  • détails du produit
  • détails du fabricant
  • détails du lot
  • entité de certification
  • point de contact
  • détails de la citation

Remarque : vous devez gérer les entrées du Registre des produits CPSC directement avec CPSC. Cette API fait référence aux identifiants d’enregistrement de la CPSC pour les déclarations de référence, mais ne permet pas de créer, de consulter ni de mettre à jour les enregistrements de la CPSC.

Un intendedUseCode est un code à six chiffres (###.###) qui indique au CBP et aux agences concernés à quoi le produit importé est destiné. Les codes sont définis par le CBP dans l’annexe R du CATAIR ACE. La CPSC ne considère comme valides pour ses soumissions de dépôt électronique qu’un sous-ensemble spécifique de ces codes, en fonction du 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.

Le code de base 130 est le plus utilisé pour la CPSC, car le champ d’application de l’agence concerne les produits de consommation. Les codes 130.000 à 130.006 sont les seuls qui peuvent être utilisés pour une soumission complète. Le type « Disclaim A » peut utiliser n’importe quel sous-code 130, à l’exception des codes 130.001 à 130.005 (c.-à-d. 130.000 ou 130.006). Le type « Disclaim B » peut utiliser uniquement le code 130.006.

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

Le champ productId est votre identifiant alphanumérique de produit. L’UE traite ceci comme l’UGS du marchand pour l’envoi.

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

• marchandProductId : identifiant du produit du marchand. Ces identifiants sont distincts de l’identifiant du produit si vous utilisez des identifiants distincts au niveau du marchand et de l’UGS; dans le cas contraire, définissez cette valeur égale à productId.
• nonStandardManufacturerProductId -  UGS ou ID interne du fabricant. Par exemple : SH123456-L.
• standardManufacturerProductId – Un identificateur standard tel que GTIN, UPC ou EAN. Par exemple : 01233456789012. Utilisez la chaîne de caractères littérale « NA » lorsque le produit ne possède aucun identifiant standard.

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

Vous pouvez consulter les données réglementaires stockées par l’API réglementaire à partir du Ship API. Les détails des profils réglementaires sont incorporés à l’envoi en aval après la création de l’envoi. 

Les flux de travail courants qui exploitent le Ship API et/ou l’API réglementaire incluent :

1. Une approche axée sur le profil. Enregistrez chaque produit une fois à l’aide de l’API réglementaire, puis fournissez uniquement productId + productIdType + regulationCode dans regulatoryDetails[] pour les marchandises de votre envoi. Les détails sont fusionnés dans l’envoi à partir du profil enregistré. 

2. Une approche en ligne uniquement. Chaque marchandise de votre envoi comprend productId + productIdType + regulationCode + entièrement renseigné details[]. Les données CPSC complètes ne peuvent pas être transmises en ligne; ce modèle est limité aux jeux de messages CPSC de type avis de non-responsabilité et référence, 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 réglementaire. Incluez productId + productIdType + regulationCode + et sélectionnez details[]. Les données de détails en ligne remplacent toutes les données stockées par l’API réglementaire. Toutes les données détaillées qui ne sont pas incluses dans les détails en ligne de l’envoi mais qui sont présentes dans le profil sont fusionnées après la création de l’envoi.