What UFLPA screening actually requires

Update, 2026-09-11. This post describes the product as it stood on 2026-08-27. Since then, antidumping/countervailing duty (AD/CVD) screening was removed from the API (September 2026 — for AD/CVD scope, use the ITA’s own search at access.trade.gov/adcvd), and an HTS number is no longer used to screen anything. Section 301 forced-labor duties on products of 60 economies took effect on 2026-07-24 and are not assessed by this API. For the current picture, see How to check a supplier against the UFLPA Entity List.

The Uyghur Forced Labor Prevention Act (UFLPA), signed into law December 23, 2021 and in effect since June 21, 2022, changed the default posture at the U.S. border for a specific category of goods. It’s worth being precise about what it actually does, because the mechanism is different from most import-compliance rules.

The rebuttable presumption

UFLPA creates a rebuttable presumption: goods mined, produced, or manufactured wholly or in part in China’s Xinjiang region — or produced by an entity on the UFLPA Entity List maintained by the DHS-led Forced Labor Enforcement Task Force (FLETF) — are presumed to have been made with forced labor and are barred from entry into the United States. The burden sits with the importer to rebut that presumption with clear and convincing evidence. In practice this inverts the usual order of operations: U.S. Customs and Border Protection can detain a shipment first and require the importer to prove it’s clean second, rather than the importer needing to prove a problem exists before anything is held.

What a real pre-shipment check has to cover

Because the presumption attaches to both a specific list of named entities and a broader regional-origin question, a meaningful screen has to check more than a single list:

• The UFLPA Entity List itself, published by DHS/FLETF — a real, public, keyless list (currently served as an HTML table at dhs.gov) naming specific companies whose goods are subject to the presumption.
• The Consolidated Screening List (CSL) — the U.S. government’s combined denied- and restricted-party list, since forced-labor exposure and export-control/denied-party risk frequently show up on the same supplier.
• Antidumping/countervailing duty (AD/CVD) exposure for the shipment’s specific HTS classification and country of origin — a separate enforcement track from UFLPA, but one that’s commonly checked (or missed) in the same pre-shipment review, and one that can apply retroactively.

Here’s a detail that matters if you’re building or buying a screening tool rather than just reading about the law: not all three of these sources are equally accessible. The UFLPA Entity List itself needs no account or key — it’s a public HTML table anyone can fetch. The Consolidated Screening List and AD/CVD case data, by contrast, sit behind trade.gov’s Developer Portal and require a registered API key; unauthenticated requests to either are rejected outright. And AD/CVD’s own public web search tool has no simpler path around that — it’s a stateful, session-bound web application, not a page with a plain underlying data endpoint, so there’s no shortcut that avoids registering for the key. A tool that claims to check all three “for free” without that key is either not actually checking two of them, or is doing something more fragile than a documented API call.

And a key isn’t always enough. As of this writing the federal endpoint that serves the structured AD/CVD dataset has had an expired TLS certificate on its own side since 28 July 2026 — we verified it independently, and it is still expired. Any client that verifies certificates properly will refuse that connection no matter how valid its API key is. It is a useful reminder that “we check AD/CVD” and “we reached AD/CVD data today” are two different statements, and only the second one is worth anything on a specific shipment.

What “no match” should — and shouldn’t — tell you

A “no match” result only means the specific sources actually queried didn’t return a match at the time of the check. It is not, by itself, a guarantee that a shipment or supplier is free of forced-labor or trade-enforcement exposure — especially if one of the three sources above wasn’t actually reached live. A screening result is only as useful as its own honesty about which sources it actually hit.

How Aervik Labs’ US Import Risk Screening API handles this

The US Import Risk Screening API takes an HTS number you already have, a country of origin, and optionally a supplier or manufacturer name, and checks it against the UFLPA Entity List, the Consolidated Screening List, and AD/CVD case exposure for that HTS/country combination in one call — returning a deterministic overall exposure rating (none / low / elevated / high) calculated the same way every time from the same inputs, never an AI judgment call. Every response discloses, per source, whether that section reflects a real, currently-wired government data call or a clearly-labeled placeholder dataset, so incomplete_coverage is something you can see and act on, not something hidden behind a clean-looking result. As of today UFLPA and the Consolidated Screening List are live; AD/CVD is the placeholder, and the reason is the expired government certificate described above, not a missing key on our side.

One thing it deliberately does not do is work out the code for you. You supply the HTS number; it is echoed back as your own input, and every tariff reference the API returns from AD/CVD scope data is reduced to the 6-digit international HS subheading — Commerce publishes those references at 8 and 10 digits, and the service will fail a response rather than pass one through. Determining the tariff line for a shipment is a licensed customs broker’s work.

This is advisory only — not legal or customs advice, and not a customs-business determination or HTS classification ruling. Consult a licensed customs broker or attorney for your organization’s actual compliance obligations.

For a walkthrough of building this into an onboarding or pre-shipment workflow, see What UFLPA Screening Actually Requires. This API shipped as part of a three-unit release; see the changelog for the exact date.