Best HS code classification APIs in 2026: how to choose

Search for a customs API today and you will find a dozen vendors claiming to classify products with AI. Some are genuinely useful. Some return a plausible-looking HTS code with no explanation, no source and no way to check it before you file. That difference matters more than the marketing copy admits — a wrong HS code doesn't just cost a support ticket, it can cost a CBP penalty, a denied entry, or years of underpaid duty owed back with interest.

This is not a ranked list of named products. Pricing and feature sets change every quarter, and a review that names specific tools is stale within months. What stays useful is a framework: the handful of decisions that separate an HS code classification API you can build a business on from one that will quietly poison your compliance data. Use it on whatever you're evaluating, including PortRobin's own API — we'll be upfront about where it sits on each criterion.

What does an HS code classification API actually need to do?

Strip away the branding and every classification API is solving two problems, and they aren't the same kind of problem. The first is classification: turning a free-text description — "men's cotton hoodie with kangaroo pocket" — into a candidate Harmonized Tariff Schedule (HTS) code. That's a judgement call, grounded in heading text and the General Rules of Interpretation (GRI), and exactly the kind of task a language model can help with, provided it's tethered to the real schedule rather than free-associating. The second problem is rating: taking that code plus a country of origin and turning it into a duty percentage. That's a lookup against a published schedule of record, plus whatever Section 301, 232 or 122 measures currently apply. A good API keeps these steps conceptually separate, because they need different trust models — you can tolerate an AI being wrong about a classification and correcting it, but not an API that invents a duty rate.

Does it show its reasoning, or just hand you a bare code?

This is the single most useful thing to check first. Ask the API to classify something genuinely borderline — a reusable silicone food pouch, a hybrid leather-and-textile bag, a product with electronic and mechanical components — and look at what comes back. A bare six-digit or ten-digit code with no working is a black box: you have no way to judge whether it's right, and neither does anyone reviewing your import file six months later during a CBP audit.

What you want instead is GRI-based reasoning attached to the answer: which heading was considered, why it was chosen over the alternatives, and which General Rule of Interpretation applied — GRI 1 for a straightforward heading match, GRI 3(b) for essential character on a composite good, and so on. That reasoning doesn't need to read like a customs broker's memo, but it needs to exist, because it's what lets a compliance team actually defend the classification later rather than just trusting a number a machine produced.

Does it cite a source and a verification date for the duty rate?

A confidence score on the classification is useful. A confidence score on the duty rate is a red flag, because the rate isn't a probability — it's either sourced to the current HTS and Chapter 99 measures, or it isn't. Every response should carry a source and a verification date, so you know how fresh the number is. If the API can't tell you when a rate was last checked, it can't tell you whether last month's Section 301 list update is reflected in what it just gave you. The honest failure mode is a response that says "unverified, check the official schedule" rather than one that quietly returns a number that might be stale.

How well does it handle Chapter 99 stacking?

This is where a lot of classification tools quietly fall down — it's the hardest part to get right and the easiest to fake. The base HTS rate is only the starting point. Depending on origin, you can be stacking a Section 301 tariff (China-origin goods on long-standing product lists), a Section 232 measure (steel, aluminium and derivative products), and a Section 122 balance-of-payments tariff on top of it — sometimes two or three at once, on the same line.

Ask any API you're evaluating for the effective rate on a China-origin steel product, not just the base HTS number. If it returns only the base rate with no mention of Chapter 99 duties, that's a serious gap — the real landed cost could be double what it just gave you, and nobody pricing off that number would know until the broker's invoice arrived. These measures are also genuinely unstable, changing through Federal Register notices sometimes with only weeks of warning, so ask how often the underlying dataset refreshes.

How much should an HS code API cost, and what should the pricing model look like?

Pricing structures fall into a few recognisable patterns, and each tells you who the vendor is built for. A per-call price with a visible free tier suits a developer testing integration before committing. A flat monthly seat price suits a compliance team on a dashboard rather than an API. "Contact sales" with no published number is common for enterprise feeds, but it's a poor fit for a small team that needs unit economics before writing a line of code. Whichever model you find, check the edges: the free-tier call limit, the overage cost, and whether there's a hard rate limit that will silently 429 your traffic during a busy season. A published limit, even a modest one, beats an unpublished one — it means the vendor has actually load-tested their own service.

Does it offer MCP or agent-native access alongside REST?

A REST API with a JSON response is table stakes in 2026, but a growing share of classification work now happens inside AI agent workflows rather than traditional application code — an agent that reads a product feed, classifies each line, and flags low-confidence results for human review. For that pattern to work well, the API needs to be something an agent framework can call natively, typically over the Model Context Protocol (MCP), rather than something a developer hand-wires every time. Look for a documented MCP server, ideally alongside a machine-readable index file (an `llms.txt`) that tells an agent what tools exist without a human reading the docs first.

The evaluation criteria at a glance

Run any candidate API through this list before you build anything on top of it. None of these require a paid trial to check — most are visible from the public documentation and a handful of test calls.

How do you sanity-check any classification API's output before it goes into production?

No API — including this one — should be the last stop before you file. Treat every automated classification as a strong first draft, then verify it against the schedule of record. The US Harmonized Tariff Schedule is maintained by the USITC and published in full online, free and searchable — it's the actual legal text every duty rate traces back to. If an API's suggested code and the USITC heading text don't obviously match, that's your signal to dig deeper or request a binding ruling from CBP before committing to the classification at scale.

A useful habit for a growing import operation: spot-check a sample of API-classified SKUs against the USITC schedule every quarter, and treat mixed-material or multi-function products as candidates for a formal binding ruling rather than an automated answer alone. A five-person DTC brand shipping reusable water bottles from Vietnam ran exactly this check last year and found their classification tool had picked a plastics heading for a bottle that was actually majority stainless steel by weight — a difference worth several points of duty on every container that arrived.

Automated classification gets you to the right neighbourhood fast. Whether you're on the right street is still something a human should confirm on anything that isn't a straightforward, single-material product.

Where PortRobin fits on this framework

In the interest of being upfront rather than just prescriptive: PortRobin's classification endpoint returns ranked HTS candidates with the reasoning behind each one, not a single bare code. The landed-cost and duty endpoints resolve Chapter 99 measures for the given origin and tag every rate with a source and a verification date — an unverified rate comes back flagged, not guessed. The REST API is public and CORS-enabled with no key required, and the same tools are exposed over an MCP server for agents. Verify it against your own test calls rather than take our word for it.

None of this is legal, customs or tax advice — it's a framework for evaluating tools, not a substitute for a licensed broker's judgement on a specific entry. Whatever API you use, the discipline is the same: verify the reasoning, verify the source, and verify the stacked rate before the goods leave the port.

Frequently asked questions