Utilice la Regulatory API para almacenar datos de cumplimiento reglamentario por producto a los que pueda hacer referencia al crear un envío.

La Regulatory API admite datos para los siguientes organismos reguladores:

• Comisión de seguridad de productos del consumidor (CPSC) de EE. UU.: datos del certificado de cumplimiento enviados como aviso legal, referencia al registro de productos de la CPSC o certificado completo.

• Comisión Europea (eliminación del umbral de minimis): identificadores de producto requeridos en virtud de la eliminación por parte de la UE del umbral de minimis de 150 €, con entrada en vigor en julio 2026, para acompañar los envíos de bajo valor de empresa a consumidor (<150 €) que entren en la UE.

Esta API no registra entradas directamente ante la Oficina de aduanas y protección fronteriza (CBP) de EE. UU., la Comisión Europea ni ninguna otra autoridad. 

El flujo de trabajo general que utiliza la Regulatory API es el siguiente:

1. Utilice esta API para almacenar datos normativos de un producto bajo una autoridad reguladora y un país específicos. Los detalles que debe indicar podrían diferir. Para obtener más información, consulte Crear un perfil.
2. Cree un envío con la Ship API. Asegúrese de que cada mercancía lleve un array regulatoryDetails[] y que cada elemento incluya regulationCode, productId y productIdType.
3. FedEx combina los perfiles de mercancías almacenados y la información de envío.
4. FedEx actúa como importador registrado y presenta todos los documentos reglamentarios necesarios en su nombre.

Para obtener más información, consulte Cómo utilizar perfiles regulatorios y la Ship API.

La flexibilidad de la Regulatory API minimiza las superficies de integración y centraliza el almacenaje. Todos los perfiles utilizan los mismos campos de nivel superior. Los datos específicos de la autoridad reguladora se almacenan en un array details[] cuya estructura de elementos viene determinada por regulationCode.  

Entre los campos de perfil de nivel superior obligatorios se incluyen los siguientes:

• regulationCode*: la agencia reguladora a la que se aplican los detalles. Por ejemplo: CPSC o EU_DE_MINIMIS. El valor de este campo define la estructura de los elementos para la información reglamentaria detallada. 
• productId*: el identificador de producto del comerciante o el cliente.
• productIdType*: el tipo de identificador del producto. Por ejemplo: SKU, PART_NUMBER, GTIN, UPC, EAN, MPN y OTROS. 
• countryOfImport*: el país de destino de la importación.
• details[]: la estructura de los elementos de este array varía en función del regulador que haya seleccionado para el envío. Para los envíos regulados por la CPSC, contiene conjuntos de mensajes disclaim o de referencia; para los envíos regulados por EU_DE_MINIMIS, contiene identificadores del fabricante. 

*Estos valores se utilizan para hacer coincidir los valores en el array regulatoryDetails[] de una solicitud de Ship API para que los datos del perfil se puedan combinar con los datos del envío.

Consejo: esta estructura refleja una entrada en el array commodities[].regulatoryDetails[] de la Ship API. Puede rellenar solicitudes de la Ship API copiando directamente desde un perfil almacenado. Esto es útil cuando tiene un envío único en el que los detalles del perfil no están actualizados.  

Realice una solicitud POST al punto de conexión de Regulatory Profiles para crear un perfil regulatorio.

Para obtener detalles específicos del regulador, consulte las siguientes secciones. 

La Regulatory API almacena los datos del CoC que la CBP y la CPSC exigen junto con la entrada ACE a través del PGA Message Set. Cree un perfil con regulationCode = «CPSC» y countryOfImport = «US».  

Uno de los tres conjuntos de mensajes siguientes debe incluirse en un elemento details[].

Además de los datos obligatorios regulationCode, productId, productIdType y countryOfImport, utilice details[] para proporcionar los conjuntos de mensajes:  

• disclaimMessageSet: los datos necesarios para el disclaim.

  • disclaimCode: A = el producto no está regulado por la CPSC; B = los datos no son necesarios según la guía de la agencia. 
  • intencionalUseCode: código base + subcódigo. Por ejemplo: «130.003». Para obtener más información, consulte Códigos de uso previsto.
  • intendedUseDescription: texto libre. Obligatorio solo cuando intendedUseCode = «980.000» (para otros usos). 

• referenceMessageSet: los datos necesarios para la referencia.

  • productVersion: el ID de la versión del certificado del producto actualmente asociado al certificado en el registro de productos de la CPSC. 
  • certificateId: el ID de certificador que le ha proporcionado el registro de productos de la CPSC.
  • registryProductId: el ID para el producto que le ha proporcionado el registro de productos de la CPSC.

• fullMessageSet: datos completos del certificado. Consulte la información sobre el punto de conexión de Regulatory para ver descripciones completas de objetos, así como campos, detalles y ejemplos. Los datos primarios incluyen: 

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

Nota: Debe gestionar las entradas del registro de productos de la CPSC directamente con la CPSC. Esta API hace referencia a los ID del registro de la CPSC para archivos de referencia, pero no crea, lee ni actualiza elementos del registro de la CPSC.

Un intendedUseCode es un código de seis dígitos (###.###) que indica a la CBP y a las agencias pertinentes para qué se va a utilizar el producto importado. Los códigos los define la CBP en el anexo R de ACE CATAIR. La CPSC considera válidos para sus envíos de eFiling únicamente un subconjunto específico de esos códigos, en función del conjunto de mensajes. Este campo siempre es obligatorio cuando se rellena disclaimMessageSet. 

La CPSC reconoce ocho códigos base: 081, 090, 100, 130, 155, 940, 970 y 980.

El código base 130 es el más utilizado por la CPSC, ya que el ámbito de actuación de la agencia se centra en los productos de consumo. En una presentación completa solo pueden utilizarse los códigos comprendidos entre 130.000 y 130.006. El disclaim A puede usar cualquier subcódigo 130 excepto 130.001-130.005 (es decir, 130.000 o 130.006). El disclaim B puede usar solo 130.006.

La Regulatory API admite las obligaciones de datos introducidas por la eliminación por parte de la UE del umbral de minimis de 150 €. Para crear un perfil, establezca regulationCode = EU_DE_MINIMIS, countryOfImport en cualquier Estado miembro de la UE27 e incluya los detalles regulatorios de la mercancía. 

El campo productId es el identificador alfanumérico de su producto. La UE lo trata como el SKU del comerciante para el envío.

Además de los datos obligatorios regulationCode, productId, productIdType y countryOfImport, utilice details[] para proporcionar: 

• merchantProductId: el identificador de producto del comerciante. Esto es distinto de productId si utiliza identificadores a nivel de comerciante y de SKU independientes; en caso contrario, establezca este valor igual a productId.
• nonStandardManufacturerProductId: el SKU o ID interno del fabricante. Por ejemplo: SH123456-L. 
• standardManufacturerProductId: un identificador estándar como GTIN, UPC o EAN. Por ejemplo: 01233456789012. Utilice la cadena de caracteres «NA» cuando el producto no tenga un identificador estándar.

La API emite una advertencia no bloqueante REGP_EU_MISSING_IDENTIFIERS cuando se almacena un perfil EU_DE_MINIMIS sin completar ninguno de los tres identificadores. 

Puede hacer referencia a los datos regulatorios almacenados por la Regulatory API desde la Ship API. Los detalles de los perfiles regulatorios se incorporan al envío en etapas posteriores, una vez creado el envío. 

Entre los flujos de trabajo habituales que utilizan la Ship API o la Regulatory API se incluyen los siguientes:

1. Un enfoque basado en perfiles. Registre cada producto una sola vez utilizando la Regulatory API y, luego, indique solo productId + productIdType + regulationCode en regulatoryDetails[] para las mercancías de su envío. Los detalles se combinan con el envío desde el perfil registrado. 

2. Un enfoque exclusivamente en línea. Cada mercancía en su envío incluye productId + productIdType + regulationCode + junto con el array details[] totalmente cumplimentado. Los datos completos de la CPSC no pueden transmitirse en línea; este patrón está restringido a los modos disclaim y de referencia a los conjuntos de mensajes de la CPSC, así como al regulador EU_DE_MINIMIS.

3. Un enfoque híbrido. Para un envío concreto, puede sobrescribir los datos existentes de la Regulatory API. Incluya productId + productIdType + regulationCode + y seleccione details[]. Los datos de detalles en línea sobrescriben los datos almacenados por la Regulatory API. Los datos de detalles no incluidos en los detalles en línea del envío, pero que están presentes en el perfil, se combinan después de crear en envío.