Regulatory API предназначен для сохранения данных о соответствии товаров нормативным требованиям, которые можно использовать при создании отправления.

Regulatory API поддерживает данные для перечисленных ниже органов регулирования.

• Комиссия по безопасности потребительских товаров США (Consumer Product Safety Commission, CPSC): данные сертификата соответствия (CoC), подаваемые в качестве отказа от обязательств, ссылки на реестр продукции CPSC или полного сертификата.

• Комиссия Европейского союза — отмена de minimis: идентификаторы товаров, требуемые в связи с отменой ЕС порога de minimis в размере 150 евро, которая вступает в силу в июле 2026 года, для сопровождения малоценных (стоимостью менее 150 евро) поставок по схеме «бизнес для потребителя», поступающих в ЕС.

Этот API не подает заявки напрямую в Погранично-таможенную службу (CBP) США, Комиссию Европейского союза или другие органы. 

Рабочий процесс, в котором применяется Regulatory API, в целом выглядит описанным ниже образом.

1. Используйте этот API для сохранения нормативных данных о товаре в соответствии с требованиями конкретного органа регулирования и страны. Требуемая информация может быть разной. Более подробные сведения см. в разделе Создание профиля.
2. Создайте отправление с помощью Ship API. Обязательно укажите для каждого товара массив regulatoryDetails[], каждый элемент которого должен содержать поля regulationCode, productId и productIdType.
3. FedEx объединяет сохраненные профили товаров и информацию об отправлениях.
4. FedEx выступает в качестве ответственного импортера и подает все необходимые нормативные документы от вашего имени.

Дополнительные сведения см. в разделе Использование нормативных профилей и Ship API.

Гибкость Regulatory API сводит к минимуму количество точек интеграции и централизует хранилище. В каждом профиле используются одни и те же поля верхнего уровня. Данные, связанные с конкретным органом регулирования, хранятся в массиве details[], форма элементов которого определяется параметром RegulationCode.  

Ниже перечислены обязательные поля профиля верхнего уровня.

• regulationCode*: орган регулирования, к которому относятся сведения. Пример: CPSC или EU_DE_MINIMIS. Значение в этом поле определяет форму элементов для подробных нормативных сведений. 
• productId*: идентификатор товара продавца или покупателя для данного профиля.
• productIdType*: тип идентификатора товара. Пример: SKU, PART_NUMBER, GTIN, UPC, EAN, MPN и OTHER. 
• countryOfImport*: страна назначения импорта.
• details[]: форма элементов в этом массиве зависит от органа регулирования, выбранного для отправления. Для отправлений, регулируемых CPSC, он содержит наборы сообщений об отказе от обязательств или ссылок; для отправлений, регулируемых EU_DE_MINIMIS, он содержит идентификаторы производителей. 

* Эти значения используются для сопоставления значений в массиве regulatoryDetails[] запроса Ship API, что позволяет подставить данные из профиля в данные отправления.

Совет: эта структура повторяет запись в массиве commodities[].regulatoryDetails[] Ship API. Запросы Ship API можно заполнять, копируя их непосредственно из сохраненного профиля. Это удобно, если вы отправляете разовое отправление, данные профиля в котором устарели, и данные требуется обновить вручную.  

Используйте конечную точку Regulatory Profile, чтобы создать профиль регулирования. Один запрос может включать до 25 профилей регулирования.

Сведения для различных органов регулирования приведены в разделах ниже. 

Regulatory API хранит данные сертификата соответствия (CoC), которые необходимы для CBP и CPSC, а также запись ACE в наборе сообщений PGA. Создайте профиль с полями regulationCode = "CPSC" и countryOfImport = "US".  

В элементе detail[] необходимо заполнить один из трех перечисленных ниже наборов сообщений.

Помимо обязательных параметров regulationCode, productId, productIdType и countryOfImport, передайте наборы сообщений в массиве detail[]:  

• disclaimMessageSet: данные, необходимые для отказа от обязательств.

  • disclaimCode: A = товар не регулируется CPSC; B = данные не требуются согласно рекомендациям ведомства. 
  • intendedUseCode: основной код и подкод. Пример: "130.003". Дополнительные сведения см. в разделе Коды предполагаемого использования.
  • intendedUseDescription: произвольный текст. Требуется только в том случае, если intendedUseCode = "980.000" (для других целей). 

• referenceMessageSet: данные, необходимые для ссылки.

  • productVersion: идентификатор версии сертификата товара, связанный с данным сертификатом в реестре продукции CPSC. 
  • certificateId: идентификатор сертифицирующего лица, выданный вам реестром продукции CPSC.
  • registryProductId: идентификатор, который использовался при регистрации товара в реестре продукции CPSC. Это необязательное поле. В нем можно использовать значение из поля productId верхнего уровня, но если при сохранении профиля с помощью этого API применяется идентификатор товара верхнего уровня, отличный от использовавшегося для регистрации товара, здесь можно указать идентификатор из реестра. Если не указать это значение, для ссылки на реестр продукции CPSC будет использоваться поле productId.

• fullMessageSet: полные данные сертификата. Полное описание, сведения и примеры см. в информации о конечных точках нормативных сведений. Основные данные включают следующие: 

  • productDetails;
  • manufacturerDetails;
  • lotDetails;
  • certifierEntity;
  • pointOfContact;
  • citationDetails.

Примечание. Управление записями реестра продукции CPSC осуществляется непосредственно через CPSC. Этот API использует идентификаторы реестра CPSC для подачи документов с помощью ссылки, но не создает, не читает и не обновляет записи в реестре CPSC.

Коды предполагаемого использования

Значение intendedUseCode — это шестизначный код (###.###), который сообщает Погранично-таможенной службе (CBP) США и соответствующим ведомствам, для чего предназначен импортируемый товар. Коды определены CBP в Приложении R к ACE CATAIR. В зависимости от набора сообщений CPSC считает действительными для подаваемых электронных документов только определенное подмножество этих кодов. Это поле является обязательным всегда, когда заполнен набор disclaimMessageSet. 

CPSC распознает восемь базовых кодов: 081, 090, 100, 130, 155, 940, 970 и 980.

Чаще всего для CPSC используется базовый код 130, поскольку данное ведомство работает с потребительскими товарами. При подаче полного набора информации можно использовать только коды с 130.000 по 130.006. Для отказа от обязательств A можно использовать любой подкод 130, кроме 130.001–130.005 (то есть 130.000 или 130.006). Для отказа от обязательств B можно использовать только подкод 130.006.

Regulatory API поддерживает требования в отношении данных, введенные ЕС в связи с отменой порога de minimis в размере 150 евро. Чтобы создать профиль, задайте для параметра regulationCode значение EU_DE_MINIMIS, для countryOfImport — любую из 27 стран ЕС, а также укажите нормативные сведения для данного товара. 

Поле productId содержит буквенно-цифровой идентификатор вашего товара. В ЕС это поле считается SKU продавца.

Помимо обязательных параметров regulationCode, productId, productIdType и countryOfImport, передайте следующие данные в массиве detail[]: 

• merchantProductId: идентификатор товара продавца. Этот параметр отличается от productId, если вы используете отдельные идентификаторы на уровне продавца и SKU; в противном случае установите его равным productId.
• nonStandardManufacturerProductId: внутренний SKU или идентификатор производителя. Пример: SH123456-L. 
• standardManufacturerProductId: стандартный идентификатор, например GTIN, UPC или EAN. Пример: 01233456789012. Если у товара нет стандартного идентификатора, укажите строковое значение NA.

Если в профиле EU_DE_MINIMIS не указан ни один из трех идентификаторов, API выдает неблокирующее предупреждение REGP_EU_MISSING_IDENTIFIERS. 

Вы можете ссылаться на нормативные данные, сохраненные с помощью Regulatory API, из Ship API. Данные из нормативных профилей применяются к отправлениям на этапах после их создания. 

Ниже перечислены стандартные рабочие процессы, в которых используется как Regulatory API, так и Ship API.

1. Метод на основе профилей. Зарегистрируйте каждый товар один раз с помощью Regulatory API, а затем указывайте только значения productId + productIdType + regulationCode в массиве regulatoryDetails[] для товаров в своем отправлении. Сведения из зарегистрированного профиля будут подставлены в отправление. 

2. Гибридный метод. Вы можете переопределить существующие данные Regulatory API для конкретного отправления. Укажите элементы productId + productIdType + regulationCode и отдельные значения details[]. Непосредственно введенные значения имеют приоритет над данными, сохраненными с помощью Regulatory API. Сведения, не указанные для отправления непосредственно, но содержащиеся в профиле, подставляются из него после создания отправления.