TL;DR
- Bulk work should reduce repetitive research, not automate the legal classification decision.
- Normalize each SKU into a fact-based description, search current HTS reference data, and save several plausible candidates with their hierarchy and notes.
- Route every candidate to a qualified reviewer. A search result has no classification confidence score, even if it appears first.
- After a code is approved, run duty, Chapter 99, PGA, and AD/CVD checks separately. Those checks reveal consequences and additional questions; they do not prove the classification.
Know what the public tools can and cannot do
Tandom's public API and read-only MCP catalog can search current HTS rows, look up an existing code, walk its hierarchy, retrieve legal notes, calculate duty, and surface PGA, Chapter 99, and AD/CVD signals. Those are useful building blocks for catalog review.
They do not turn an arbitrary product description into an approved classification. The public GET /v1/hts/search operation is reference search. It does not apply the full legal sequence, consult private product evidence, or certify that its first result is correct.
That distinction matters most at scale. Calling a search result a classification makes a large spreadsheet look complete while hiding the rows that need judgment.
Prepare the catalog before you search
Product names written for sales or inventory systems rarely contain enough classification facts. Create a separate review file with one row per distinct fact pattern and these columns:
- Identity: SKU, plain-English article name, supplier, and the current filed code if one exists.
- Physical facts: materials, form, dimensions, capacity, power source, and component breakdown where relevant.
- Commercial facts: function, principal or actual use, who uses it, and whether it is imported as a part, kit, set, unfinished article, or complete article.
- Entry facts: origin, entry date, and any steel, aluminum, or other facts needed for downstream duty analysis.
Add an information gap column. A row missing composition, end use, or another dispositive fact belongs in a supplier follow-up queue before anyone chooses a code.
Build a review queue, not an answer file
1. Deduplicate true variants
Group rows only when the facts that drive classification are the same. Color and packaging variants may qualify; different materials, functions, capacities, or import conditions often do not.
2. Search with factual phrases
Query the main article and its function first. Use material, form, and end use to narrow the candidates. Save multiple results instead of forcing a single code when the text is ambiguous.
3. Expand each candidate
Walk the candidate's parents and children, then read the applicable section, chapter, heading, and subheading notes. Record the text that includes or excludes the product.
4. Route by risk and missing facts
Prioritize new categories, high entered value, material ambiguity, parts and sets, trade-remedy exposure, and disagreements with a previously filed code. Every row still receives human disposition; the risk score determines review order, not whether review happens.
Use the public API without overstating the result
The example below turns a short SKU list into a candidate queue. It intentionally labels every row REVIEW_REQUIRED. Keep your API key in an environment variable and follow the endpoint-specific safeguards in the public reference.
// hts-candidate-queue.mjs — Node 20+
const API_KEY = process.env.TANDOM_API_KEY;
const ENDPOINT = "https://api.tandom.ai/v1/hts/search";
const skus = [
{ sku: "P-100", query: "forged stainless steel pipe flange" },
{ sku: "P-200", query: "electric centrifugal water pump industrial" },
];
for (const item of skus) {
const url = new URL(ENDPOINT);
url.searchParams.set("q", item.query);
url.searchParams.set("limit", "5");
const response = await fetch(url, {
headers: { Authorization: "Bearer " + API_KEY },
});
if (!response.ok) throw new Error("HTTP " + response.status);
const data = await response.json();
console.log(JSON.stringify({
...item,
candidates: data.results,
status: "REVIEW_REQUIRED",
}));
}Next, use the public hierarchy and notes operations to investigate each candidate. Do not manufacture a confidence score from result order, code length, or the number of matches. None of those measures whether the legal classification is correct.
Review, approve, and preserve the reasoning
The reviewer should record the selected code, the facts relied on, the applicable HTS text and notes, the GRI step that resolved the question, the reviewer, and the review date. If the answer depends on a supplier fact, attach the source document or response.
Once the code is approved, calculate the duty stack for the intended origin and entry date. Run PGA, Chapter 99, and AD/CVD checks as separate workstreams. A clean duty result does not validate the code, and an HTS match does not establish AD/CVD scope.
Escalate unresolved or high-impact products to a licensed customs broker, customs counsel, or CBP's eRulings process.
Common pitfalls
- Calling search rank confidence. Relevance ranking is not a legal conclusion.
- Using vague source descriptions. "Machine part" is a supplier-information problem, not an API problem.
- Ignoring notes and exclusions. Heading text alone can point in the wrong direction.
- Reusing stale decisions silently. Record the schedule version and revisit affected families when the HTSUS changes.
- Mixing classification with trade remedies. AD/CVD scope and Chapter 99 applicability require their own facts and analysis.