Introdução
Use a Regulatory API para armazenar dados de conformidade regulatória por produto que você pode consultar ao criar uma remessa.
A Regulatory API é compatível com dados dos seguintes reguladores:
Comissão de Segurança dos Produtos de Consumo (CPSC) dos EUA: dados do Certificado de Conformidade (CoC) enviados como uma isenção de responsabilidade, uma referência ao Registro de produtos da CPSC ou um certificado completo.
Comissão da União Europeia — eliminação do tratamento "de minimis": identificadores de produtos exigidos conforme a eliminação do tratamento de minimis de € 150 pela UE, a partir de julho de 2026, para acompanhar remessas business-to-consumer de entrada na UE de baixo valor (menos de € 150).
Essa API não registra declarações diretamente na Alfândega e Proteção de Fronteiras (CBP) dos EUA, na Comissão Europeia ou em outras autoridades.
O fluxo de trabalho geral que usa a Regulatory API é o seguinte:
- Use essa API para armazenar dados regulatórios de um produto em conformidade com um regulador e país específicos. Os detalhes necessários podem variar. Para mais informações, consulte Criação de um perfil.
- Crie uma remessa com a Ship API. Verifique se cada commodity contém a matriz
regulatoryDetails[]e se cada elemento incluiregulationCode,productIdeproductIdType. - A FedEx combina perfis de commodities armazenados e informações de remessa.
- A FedEx atua como importador registrado e arquiva todos os documentos regulatórios necessários em seu nome.
Para mais informações, consulte Uso dos perfis regulatórios e da Ship API.
A flexibilidade da Regulatory API minimiza as plataformas de integração e centraliza o armazenamento. Todos os perfis usam os mesmos campos de nível superior. Os dados específicos do regulador são armazenados em uma matriz details[], cujo elemento tem um formato determinado por regulationCode.
Os campos de nível superior obrigatórios do perfil incluem:
regulationCode*: a agência regulatória à qual os detalhes se aplicam. Por exemplo: CPSC ou EU_DE_MINIMIS. O valor desse campo define o formato do elemento para as informações regulatórias detalhadas.productId*: o identificador de produto do comerciante ou do cliente.productIdType*: o tipo de identificador de produto. Por exemplo: SKU, PART_NUMBER, REGISTERED_NUMBER, GTIN, UPC, EAN, MPN e OTHER.countryOfImport*: o país de destino da importação.details[]: o formato dos elementos dessa matriz muda dependendo de qual regulador você escolheu para a remessa. No caso de remessas regulamentadas pela CPSC, a matriz contém conjuntos de mensagens de Isenção de responsabilidade ou Referência. Já no caso de remessas regulamentadas por EU_DE_MINIMIS, ela contém identificadores dos fabricantes.
*Esses elementos são usados para a correspondência dos valores na matriz regulatoryDetails[] de uma solicitação da Ship API, permitindo a integração dos dados do perfil aos da remessa.
Dica: essa estrutura reflete uma entrada na matriz commodities[].regulatoryDetails[] da Ship API. Você pode copiar os dados diretamente de um perfil armazenado para preencher as solicitações da Ship API. Essa opção é adequada no caso de remessas únicas em que os detalhes do perfil estão desatualizados.
Faça o POST no endpoint dos perfis regulatórios para criar um perfil regulatório.
Para ver os detalhes específicos do regulador, consulte as seções a seguir.
A Regulatory API armazena os dados do CoC exigidos pela CBP e pela CPSC, além da entrada no ACE por meio do PGA Message Set. Crie um perfil em que regulationCode = "CPSC" e countryOfImport = "US".
Um dos três conjuntos de mensagens a seguir deve ser preenchido em um elemento details[].
Além dos regulationCode, productId, productIdType e countryOfImport obrigatórios, use details[] para fornecer os conjuntos de mensagens:
disputeMessageSet: os dados necessários para a isenção de responsabilidade.disclaimCode: A = o produto não é regulamentado pela CPSC; B = os dados não são necessários conforme instruções da agência.intendedUseCode: código base + subcódigo. Por exemplo: "130.003". Para mais informações, consulte Códigos de uso pretendido.intendedUseDescription: texto livre. Exigido apenas quandointendedUseCode= "980.000" (para outro uso).
referenceMessageSet: os dados necessários para a referência.productVersion: o identificador da versão do certificado do produto associado ao certificado no Registro de produtos da CPSC.certificateId: o ID do certificador atribuído a você pelo Registro de produtos da CPSC.
fullMessageSet: dados do certificado completo. Consulte as informações do endpoint regulatório para ver as descrições completas de objetos e campos, os detalhes e alguns exemplos. Os dados principais incluem:productDetailsmanufacturerDetailslotDetailscertifierEntitypointOfContactcitationDetails
Observação: você deve gerenciar as entradas do Registro de produtos da CPSC diretamente com a CPSC. Esta API faz referência aos IDs do registro da CPSC para arquivos de referência, mas não cria, lê ou atualiza os registros da CPSC.
Um intendedUseCode é um código de seis dígitos (###.###) que informa à CBP e às agências relevantes a finalidade do produto importado. Os códigos são definidos pela CBP no Apêndice R do ACE CATAIR. A CPSC considera que apenas um subconjunto específico desses códigos é válido para as entradas no eFiling, dependendo do conjunto de mensagens. Esse campo é sempre necessário quando disclaimMessageSet é preenchido.
A CPSC reconhece oito códigos base: 081, 090, 100, 130, 155, 940, 970 e 980.
O código base 130 é o mais usado para a CPSC porque o escopo da agência é de produtos de consumo. Os códigos 130.000 a 130.006 são os únicos que podem ser usados em uma entrada completa. A Isenção de responsabilidade A pode usar qualquer subcódigo 130, exceto os de 130.001 a 130.005 (ou seja, 130.000 ou 130,006). A Isenção de responsabilidade B pode usar apenas o 130.006.
A Regulatory API é compatível com as obrigações de dados instituídas com a remoção do limite de minimis de € 150 pela UE. Para criar um perfil, defina regulationCode = EU_DE_MINIMIS, countryOfImport para qualquer Estado membro da UE27 e inclua os detalhes regulatórios da commodity.
O campo productId é o identificador alfanumérico do produto. A UE considera que ele é o SKU comercial para a consignação.
Além dos regulationCode, productId, productIdType e countryOfImport obrigatórios, use details[] para fornecer:
merchantProductId: o identificador de produto do comerciante. Ele é diferente do productId se você usa identificadores separados nos níveis do comerciante e da SKU; caso contrário, defina esse campo comoproductId.nonStandardManufacturerProductId: SKU ou ID interno do fabricante. Por exemplo: SH123456-L.standardManufacturerProductId: um identificador padrão, como GTIN, UPC ou EAN. Por exemplo: 01233456789012. Use a sequência literal "NA" quando o produto não tem um identificador padrão.
A API emite um aviso REGP_EU_MISSING_IDENTIFIERS sem bloqueio quando um perfil EU_DE_MINIMIS é armazenado sem nenhum dos três identificadores preenchidos.
Você pode consultar os dados regulatórios armazenados pela Regulatory API na Ship API. Os detalhes dos perfis regulatórios são incorporados no downstream da remessa após a criação da remessa.
Os fluxos de trabalho comuns que utilizam a Ship API e/ou a Regulatory API incluem:
Uma abordagem que prioriza o perfil. Registre cada produto uma vez usando a Regulatory API e preencha apenas
productId + productIdType + regulationCodeemregulatoryDetails[]para as commodities da remessa. Os dados do perfil registrado são integrados à remessa.Uma abordagem exclusivamente inline. Cada commodity da remessa inclui
productId + productIdType + regulationCode +details[]totalmente preenchidos. Os dados completos da CPSC não podem ser enviados inline. Esse padrão está restrito aos conjuntos de mensagens de isenção de responsabilidade e referência da CPSC e ao regulador EU_DE_MINIMIS.Uma abordagem híbrida. Você pode substituir os dados existentes da Regulatory API para uma remessa específica. Inclua
productId + productIdType + regulationCodee selecionedetails[]. Os dados dos detalhes inline substituem todos os dados armazenados pela Regulatory API. Dados não incluídos nos detalhes inline da remessa, mas presentes no perfil, são incorporados após a criação da remessa.
Response