Avalara Item Classification automates the complex process of determining HS codes, taking into consideration country, product attributes, and other factors.

Core capabilities

Apply Avalara-maintained tax rules and rates tailored to your product category and jurisdictions.

Industry-specific logic

Support tiered pricing, bundled offerings, exemptions, and multi-jurisdiction calculations without custom engines.

Complex scenarios

Stay current with evolving requirements through regularly updated content and configuration options.

Regulatory alignment

Integrate with billing, ERP, and custom apps using REST APIs built for high-volume transaction processing.

Operational scale

Use API documentation, integration checklists, and environment setup guides linked from each product below. Provisioning and access details depend on your Avalara products and onboarding path.

Getting started

Avalara APIs provide REST interfaces for billing, subscription, ERP, and custom applications. They support scalable tax determination and high-volume processing so you can embed compliance into your existing workflows.

How it integrates

What Tariff Code Classification solves

When to use Tariff Code Classification

Tariff Code Classification

Get Started

Automated Tariff Code Classification assigns HS and HTS tariff codes to products at scale using predefined logic and classification models. It helps businesses standardize product classification across large catalogs without manual intervention.

Automatically classify large product catalogs using standardized logic.

High-volume classification

Apply consistent tariff codes across systems and transactions.

Consistent code assignment

Reduce reliance on manual classification workflows.

Reduced manual effort

Support growing catalogs and global expansion.

Scalable classification workflows

Integrate classification workflows through APIs by submitting product attributes and retrieving assigned tariff codes. Setup typically includes mapping product catalog data and configuring classification rules within your system.

Integrate via REST APIs to submit product descriptions and receive tariff code assignments in real time.

Automated Tariff Code Classification

Self-Serve Tariff Code Classification allows users to manually classify products by entering product details and attributes. It is designed for interactive classification workflows when automation is not required.

Classify products using descriptions and attributes.

Interactive classification

Flexible input handling

User-controlled decisions

Enable interactive classification through APIs that accept product descriptions and return tariff code suggestions. Implementation requires passing product data and handling user-driven selection workflows.

Use the self-serve interface directly or integrate via APIs for a hybrid classification approach.

Self-Serve Tariff Code Classification

Managed and Premium Tariff Code Classification provide expert-led and hybrid classification services to support accurate tariff code assignment for products. These solutions are designed for businesses that require high confidence in classification, especially for complex or compliance-sensitive scenarios.

Leverage specialists to assign and validate tariff codes for accuracy and compliance.

Expert-led classification

Combine automated classification with expert review to support high-confidence results.

Hybrid classification model

Ensure classification outputs meet regulatory requirements and support audit workflows.

Compliance and audit support

Support classification for products with complex attributes, regulatory requirements, or high-risk profiles.

Complex product handling

Get started by onboarding products into classification workflows.

You can integrate APIs to submit product data and retrieve validated tariff codes, with support for automated processing and expert review.

Submit product data through APIs or batch uploads and receive expert-assigned tariff codes with supporting documentation.

Managed and Premium Tariff Code Classification

Avalara Trade Compliance helps businesses manage regulatory requirements for cross-border transactions. It supports compliance with trade rules, restrictions, and regulatory obligations.

Apply trade compliance rules across jurisdictions.

Regulatory rule management

Risk reduction

Help ensure transactions meet regulatory requirements.

Cross-border control

Integrate compliance checks into transaction workflows using APIs to validate cross-border transactions against regulatory requirements. Setup includes configuring jurisdiction rules and adding compliance checks to order processing workflows.

Integrate via REST APIs to screen transactions and retrieve compliance status in real time.

Avalara Trade Compliance

The Trade and Tariff Library provides access to global tariff schedules, duty rates, and trade data required for cross-border compliance and decision-making.

Access global tariff schedules and duty rate information.

Centralized tariff data

Stay aligned with changing trade regulations.

Up-to-date trade data

Support classification and compliance workflows.

Data-driven decisions

Access tariff and trade data through APIs by querying country, product, and classification inputs. Integration involves incorporating tariff data retrieval into classification, calculation, or compliance workflows.

Query tariff data and duty rates via REST APIs to embed trade data into pricing, compliance, and logistics workflows.

Avalara Trade and Tariff Library

Comma-separated list of supported `avalara-version` dates (most recent first).

The `avalara-version` the server honoured for this response.

For single-item submissions, points at the canonical GET endpoint for
the newly-created classification. For bulk submissions, points at the
first item's GET URL; callers should iterate
`items[].classifications[].id` for the rest.


Requests remaining in the current window.

Unix epoch (seconds) when the window resets.

Seconds the client should wait before retrying (RFC 7231).

Accept

Dated version of the contract the caller is pinning to (`YYYY-MM-DD`).
Discoverable via `OPTIONS` on the same path (`avalara-supported-versions`
response header). Unsupported dates return 422; sunset dates return 410.


avalara-version

companyId

Content-Type

Context

customerId

returnIcAccountId

Allowed methods and contract versions for this path. Used for CORS
pre-flight and version discovery; the body is intentionally empty.


Rate limit exceeded. Honour the `Retry-After` header before retrying.
Body uses the `AvaTaxError` envelope with `RateLimitExceeded`.


AvaTax-style error envelope `{ "error": { "code", "target", "details"[] } }`.

Returned for:
- Gateway / OAuth failures (**401**) before the controller runs.
- **POST** `/{companyId}/classifications` HTTP-level failures: **402**, **413**, **422**,
  **503**, **500** (and downstream `AvaTaxException` bodies when mapped by the controller).
- **GET** `.../classifications/{id}` **404**, **422**, **500** (mirrors legacy V1).

Nested per-item / per-COD errors inside a **207** `ClassificationResponse` still use the flat
`Error` schema on the embedded `error` fields.

Use `error.code` plus `error.details[].number` to branch programmatically. Common numbers
include `31` / `34` / `37` (auth), `5` (`ValueRequiredError`), `50` (`UnhandledException`),
`70` (`ModelStateInvalid`), `3011` (`MtccPlusNotProvisioned`), `3015` (`EntitlementRequired`),
`3016` (`PayloadTooLarge`), `3008` (`RetryRequest`), and values from `ClassificationError`.


This service or operation is not authorized for this account or user.

Unify GET response - one classification record identified by the
composite `id`, with the originating item embedded as `item`.
Field projection is driven by the legacy classification record
loaded from the underlying store (HSCT / ItemMaster / DW /
parking lot, in priority order), not by parsing the ID. Fields
beyond `id` / `status` are populated when the legacy record
carries them. The embedded `item` reverses the legacy
field-name flips (`description` -> `title`, `summary` ->
`description`, `itemGroup` -> `category`); the
`_uncategorized` sentinel is silently dropped.


Reverse-mapped from the legacy uppercase activity (`HS_FULL` -> `hsFull`, etc.).

Suppressed when the resolved customer's `confidenceFlag` is off.

Suppressed alongside `confidence` for customers without the confidence flag.

Final HS code; present once `status == "classified"` for `hsFull` / `hs6`.

Composite ID; same value the POST response surfaces under `items[].classifications[].id`.

Suppressed unless `status == "classified"` (V1 parity).

Reverse-mapped from the legacy status using the same heuristics as the POST builder.

Capped at 10 per request (configurable via
unify.max.countries.of.destination). Exceeding returns 413.


**Sandbox / integration use only.** Pre-supplied HS code per
country of destination. When present, the server treats the
listed code as the final classification for that COD and
bypasses all classification logic (no Indix / HSAC call).
Strictly capped to 20 characters per value.

Independent of `classificationType`, every COD listed in
`hsCodeTest` is processed via the managed pipeline. When the
caller asked for an auto type and supplied `hsCodeTest` for
every entry in `countryOfDestination`, the entire request is
re-routed to managed. Partial coverage splits the request:
covered CODs run through managed, the rest through the
requested auto path.

Covered CODs surface in the response as
`status: "classified"`, `hsCode: "<test value>"`,
`confidence: "test"`. Uncovered CODs follow the regular auto
response shape. The response's `classificationType` echoes
the original caller value (re-routing is internal).


Bulk shape. Capped at 10 per request (configurable via
unify.max.items.per.request). Exceeding returns 413.


Please provide a value for field countryOfExport.

Per-COD compliance payload returned by the Quoting service. Populated only
when `compliance` is in `classifications` *and* an HS code is available
for the COD (auto path: Indix prediction; managed path:
caller-supplied `providedHsCodes`). Mutually exclusive with
`complianceError`. Item shape mirrors
`com.avalara.xb.classification.views.Compliance` (Quoting response).


Set when the unify compliance gate skipped the Quoting call because the item
is missing a field Quoting requires (today: `countryOfExport`). Wire
shape is identical to Quoting's own `ValueRequiredError` payload
(`{ details: [{ code, number, message, description, helpLink, severity }] }`).
Mutually exclusive with `compliance`; the classification itself is
unaffected.


Two characters ISO 3166 code identifying the country

is given request parameter has ADD (Anti-Dumping Duty) rates.

is given request parameter has CVD(Countervailing Duty) rates.

is given request parameter PGA restrictions for countryOfImport.

is given request parameter have restrictions for countryOfImport.

Pure pass-through map. Anything the caller puts here is forwarded
verbatim to the Quoting compliance service. The only locally
validated fields are `startDate` / `endDate` (yyyy-MM-dd, end >=
start). System-managed keys (`id`, `hscode`, `countryOfImport`,
`countryOfExport`, `countryOfManufacture`, `section232Parameters`)
are silently stripped before forwarding. Section 232 must be sent
via `item.section232[]`.


Compliance-enrichment error envelope returned on
`ClassificationResult.complianceError` when the unify compliance gate
short-circuited the Quoting call. Wire shape is identical to
Quoting's own `{ details: [...] }` validation-error payload, so
unify callers can reuse the error handling they already wrote for
direct AvaTax / Quoting calls. Mutually exclusive with
`ClassificationResult.compliance`.


Optional top-level summary code. Omitted by the unify gate today.

Optional top-level summary message. Omitted by the unify gate today.

Optional context tag. Omitted by the unify gate today.

Single entry inside `ComplianceError.details[]`. 1:1 mirror of the
AvaTax `ErrorDetail` shape (minus the legacy `faultCode` slot). The
unify gate emits `{ code: "ValueRequiredError", number: 5 }` for
required-field violations - byte-for-byte identical to what Quoting
returns when called directly.


the name of the product that need to ship

Basis for duty calculation (e.g., PRICE, QUANTITY, CIF)

Indicates if Free Trade Agreement rates apply

Small `{ "code", "message" }` object used **only** inside successful HTTP responses
for **nested** failures — e.g. `207` payloads under `items[].error` or
`items[].classifications[].error` when a single item or COD is rejected.

**Not** used for HTTP-level `402` / `413` / `422` / `503` / `500` on `POST .../classifications`;
those responses use `AvaTaxError`. Gateway `401` also uses `AvaTaxError`.


Name of the error. Refer to Error Codes section for a list of accepted values.

A more detailed description of the problem referenced by this error message, suitable for display in the contents area of an alert box.

Concise summary of the message, suitable for display in the caption of an alert box.

Unique ID number referring to this error or message.

Item the message refers to, if applicable. This is used to indicate a missing or incorrect value.

Severity of the message`:`  Success, Warning, Error and Exception.

Short one-line message to summarize what went wrong

What object or service caused the error? (Unknown, HttpRequest, HttpRequestHeaders, IncorrectData)

hs_code_test

price

weight

The required classification activity for the request. Accepted values are: HS_FULL : full HS code classification (country specific). This is the default activity if no value is specified in the request. HS6: 6 digits HS code classification

If the information provided in the request is not enough, an accurately classification might not be possible. In this case, the assumption made for classification will be returned in this field.

This is a detailed description of the assumptions made in order to classify an item when information provided in the request is not enough (e.g. similar product URL, product number or anything which can be used as identifier behind the classification logic).

Single country of destination code (ISO 3166-1 alpha-2).
Must be a valid country code supported by the system.


Multiple countries of destination codes (ISO 3166-1 alpha-2).
- Must be valid country codes supported by the system
- Invalid country codes will be included in the invalidCODs array
- At least one valid country code is required


This is the HS classification result. It’ll be returned in the body for GetHSClassification method.

The id of the HS classification request. This id is created by CreateHSClassificationRequest and returned in the response.

List of invalid country codes that could not be processed

Alternative HS codes that could apply to this item, when available. This field is only included when the broker parameter is set to "true" and there are alternative HS codes available. Provided as a stringified JSON array.

Indicates whether the product information was updated during classification.

This value will be returned by getHSClassification method only if an item cannot be classified (status=CANNOT_BE_CLASSIFIED). It contains a detailed description of the issue. It’ll be ignored if it’s provided in the request.

This value is returned by get HS Classification method. It’ll be ignored if it’s provided in the request.

List of valid country codes that were successfully processed

The HS code to verify. Must be 6-12 digits, optionally followed by up to 2 letters.

Full classification response from the classification submission. Only present when verified=false and classification submission succeeds. Includes a 'failedVerificationCode' parameter in classificationParameters array.

Human-readable message about the verification result

Echo of the HS code that was submitted for verification

Whether the HS code was verified as appropriate for the product

The unique ID number of the company that owns this item.

A short description of the product. It’s also referred as product title or name.

A unique id generated by Avalara Classification System

A unique code representing this item. It’s recommended to use the SKU number.

Product category breadcrumbs. This is the full path to the category where item is included. Categories should be separated by ` > `.

Use the  parentCode to group product variants. Variants are a group of similar items that only differ from one another by product details like size, color, material, pattern, age group or size .

The system has predefined list of parameter names that are known and
processed accordingly (see enum).

Predefined parameters for a compliance enrichment
request include: compliance_flagging, country_of_export,
country_of_manufacture, manufacturer_name, compliance_start_date,
compliance_end_date. When `compliance_flagging` is set to `true`,
`country_of_export` is **required** (otherwise no compliance call
is made for that country of destination) and
`country_of_manufacture` + `manufacturer_name` are strongly
recommended for accurate duty, FTA, CVD/ADD and restrictions
lookups.

For a brokerage response, where classification provides an HS6 with
optional full HS codes for your brokers to select from requires the
broker parameter set to true. 

For a premium response, where classifications are returned with full
explanations of rationale require the
premium parameter set to true. 

The system also supports 
custom parameters. For custom parameters, the name is not predefined
and should be provided in the request.

Indicates if the rate applies under de minimis thresholds

Indicates whether this punitive rate should be applied **on top of** all other duty components (MFN, FTA).


Indicates whether the punitive rate is **compounded**, i.e. calculated as: rate + surchargeRate + (rate * surchargeRate)


Unit of measurement (e.g., percentage, kilogram, count)

The webhook callback payload that will be sent to the client's webhook endpoint when a classification is completed.
Only clients who have specifically opted to receive webhook callbacks need to implement this endpoint.
This is an optional feature for "Item Classification Without Storage" customers.

**Authentication:**
The webhook callback supports two authentication methods:
- Basic Authentication: Requires an API key configured in the Avalara system
- OAuth: Requires an OAuth token endpoint to be configured in the Avalara system

**Conditional Fields:**
- The `possibleHsCodes` field is only included when the `broker` parameter is set to "true" and there are alternative HS codes available

**Retry Behavior:**
If the webhook call fails due to server connectivity issues, the system will automatically retry the call.


The ID of the company that owns this item.

Compliance information if compliance_flagging was enabled.

The country code for which the classification was performed.

The id of the HS classification request that was completed.

The unique item code (typically your SKU) that was classified.

Alternative HS codes that could apply to this item, when available.
This is provided as a stringified JSON array.


Explanation of the classification decision when available.

The status of the classification request.

Avalara-issued OAuth 2.0 bearer token. Enforced upstream by the
gateway / authentication layer; failures surface as HTTP **401**
with the `AvaTaxError` envelope.


If you're subscribed to the Avalara Item Classification service, these APIs 
 allow you to submit products for Item Classification and retrieve the 
 corresponding HS Codes.

 **Notes**:
 - Avalara Item Classification is a billable service. If the service is not 
 enabled, the API will not provide a response.
 - In the development environment (Sandbox), the service will not 
 return HS Codes. Instead, requests will remain in a pending status by default.
 Use the `hs_code_test` parameter in your Sandbox/integration environment to pass 
 an HS Code directly. In this case the product will not be reviewed by any operator,
 and a response will be sent back in a matter of minutes.

 There are two subscription options for the Item Classification API:
 - **Item Classification With Storage**: Your item metadata is automatically 
 stored as an [Avalara
 Item](https://developer.avalara.com/api-reference/avatax/rest/v2/models/ItemModel/) 
 object. This enables easy referencing of your items and metadata throughout
 Avalara using your own SKU.
 - **Item Classification Without Storage**: You have the flexibility to store 
 your classified items in a manner that best suits your needs. If you opt 
 for this, you can optionally set up a webhook to receive your classifications.

 **Unify endpoint**:
 The `/api/v2/companies/{companyId}/classifications` resource (POST/GET) is the
 unify, explicit-intent contract. Callers declare what they want via
 `classificationType` (`managed`, `autoPro`, `autoEssentials`), `classifications`,
 and `classificationModifiers`, instead of relying on the implicit Auto HS
 branching of the older `/classifications/hs` endpoints. It uses Bearer (OAuth 2.0)
 authentication and the AvaTax error envelope. See
 `documentation/design/unified endpoint/` for background.

Avalara License

Avalara Item Classification API

CORS pre-flight and version discovery. `Allow` lists the supported
methods; `avalara-supported-versions` lists the dated `avalara-version`
contracts the server currently honours.


Discover allowed methods and contract versions for this path

Accepts three body shapes:
1. Single object with `item`.
2. Single object with `items[]` sharing classification config.
3. Top-level JSON array of independent requests.

**Success responses** (`201 Created`, `207 Multi-Status`) are always `{ "items": [...] }`.

**HTTP-level errors** (`402`, `413`, `422`, `429`, `503`, `500`, and `401` from the gateway) return
the **AvaTax error envelope** (`AvaTaxError`) — `{ "error": { "code", "target", "details"[] } }` —
the same structural shape used for OAuth/gateway failures. Only **nested** rejections inside
a `207` item / per-COD result still use the small `{ "code", "message" }` object (`Error`).


All items accepted and all classifications produced.

## Index-based correlation

`items[i]` in the response corresponds positionally to:
- `items[i]` in the request body when the caller used the `items[]` shape, or
- the i-th element of the top-level JSON array when the caller used the array shape, or
- the single response element `items[0]` when the caller used the single `item` shape.

## Partial-success caveat inside 201

Even on `201`, individual classifications can carry
`status: cannotBeClassified` (auto path with no Indix prediction)
or `status: pending` (managed path). Per-COD rejections that
warrant HTTP escalation surface as **207 Multi-Status** instead.


Multi-status — some items or per-COD classifications were rejected.

## Index-based correlation

`items[i]` in the response corresponds positionally to `items[i]`
in the request body (or the i-th element when an array body was
sent). Per-item rejections appear under `items[i].error`;
per-COD rejections inside an otherwise-accepted item appear
under `items[i].classifications[j].error`.


Gateway authentication failure - the request was rejected by
the upstream authentication layer BEFORE the unify controller
ran. Body uses `AvaTaxError` (not the small nested `Error` used
only inside **`207`** payloads). All other HTTP failures on this
POST also use `AvaTaxError` — branch on **HTTP status** and
**`error.code`** / **`details[].number`**, not on a second top-level
`{ "code", "message" }` shape.

Sub-cases (distinguished by `error.code` /
`error.details[0].number`):
- `AuthorizationException` (31) - token valid but caller is
  not authorised for this account / operation.
- `AuthenticationIncomplete` (34) - missing `Authorization`
  header.
- `BearerTokenInvalid` (37) - token unrecognised or expired.


Customer is not entitled to the requested `classificationType` or modifier.
Uses the AvaTax envelope (`error.code`: `EntitlementRequired` number **3015**, or
`MtccPlusNotProvisioned` number **3011** when the `mtccPlus` modifier is not provisioned).


Request exceeds a per-request size cap. Either `items[]` > configured max
(`unify.max.items.per.request`), `countryOfDestination[]` > configured max
(`unify.max.countries.of.destination`), or auto bulk over its own cap.
Body is `PayloadTooLarge` (number **3016**) in the AvaTax envelope.


Request validation (`ModelStateInvalid`, number **70**), minimal-field validation,
missing body (`ValueRequiredError`, **5**), or `ErrorCodeException` translated via
`HSClassificationErrors.translateError` — all returned as the AvaTax envelope.
Validator rules surface as `error.code: ModelStateInvalid` with each failed rule in
`details[]` using the unify rule code in `details[].code`.


Unhandled server error (`UnhandledException`). AvaTax envelope.

Upstream AvaTax / HTTP dependency did not respond in time (`RetryRequest`, number **3008**).
Returned as AvaTax envelope; `severity` is typically `Warning`.


Submit a product for HS classification for one or more countries of
destination. Each product (item) must be uniquely identified by itemCode
for a particular company. It is recommended to use your internal SKU
number as itemCode. Item classifications belong to the company you
designate.

## Dual-mode behavior

The same endpoint serves both auto-classification and manual
classification customers. The mode is chosen server-side based on
customer entitlement and the `async` query parameter:

- **Auto classification path** (synchronous prediction). Selected when:
  - The customer is entitled to **Auto HS**, **Auto HS Pro**, or **Auto HS ICP**, **and**
  - `async` is **not** `true` (i.e. omitted or `false`).

  The request is internally routed to the ML-based auto-classify flow
  (previously exposed as `/classifications/hscodes/auto`, now deprecated
  and removed from the public surface). The classification result is
  returned **synchronously** in the response body — there is no need to
  poll the GetHSClassification endpoint afterwards.

- **Manual classification path** (asynchronous parking-lot creation).
  Selected when:
  - The customer is **not** entitled to Auto HS / Auto HS Pro / Auto HS ICP, **or**
  - `async=true` is supplied (force manual flow even for entitled customers).

  The item is queued for manual classification. The response carries a
  `PENDING` status and the classification result can be retrieved later
  via `GET /classifications/hs/{hsClassificationId}`.

If the auto-classify path is selected but fails before invoking the
prediction service (e.g. authentication or payload conversion error),
the request automatically falls back to the manual classification path
so the call still succeeds.

## Request body

Both modes accept the **same** request body shape
(`HSClassificationModel` / `HSClassificationWithComplianceModel`).
Existing integrations do not need to change their payload to benefit
from auto-classification: simply enable Auto HS on the customer.

## Limits

- **Manual path:** maximum payload size of approximately 60KB. Exceeding
  this returns **413 Payload Too Large**. Split bulk-country requests if
  you hit the limit.
- **Auto path:** combined count (items × countries of destination) must
  not exceed the configured per-request limit (e.g. 10). Exceeding it
  returns **413 Payload Too Large**.


The ID of the company that owns this item. This is your integer company ID, not the string company code.

The unique identifier of the customer (for multi-tenant scenarios). When omitted, the customer is resolved from the authentication token.

When `true`, the response includes the Item Classification account id (`icAccountId`) for each classification entry. Defaults to `false` when not supplied.

Forces the **manual classification path** (parking-lot creation) even when the customer is entitled to Auto HS / Auto HS Pro / Auto HS ICP. When omitted or `false`, entitled customers are auto-classified synchronously. When `true`, the item is always queued for manual classification and the response status will be `PENDING`.

async

Optional contextual metadata propagated to downstream services.

The details for the item which requires HS classification.

Created. Returned for both modes:
- **Manual path:** the classification request was accepted and parked
  for manual classification; `status` is `PENDING`.
- **Auto path** (auto-HS-entitled customer, `async != true`): the
  classification was performed synchronously and the result is in
  the response body. `status` can be `CLASSIFIED_AUTOMATICALLY` (HS
  code predicted with sufficient confidence), `PENDING` (confidence
  threshold not met — item routed for manual classification), or a
  "Failed to Classify - Insufficient product information..." status
  when the model could not produce a prediction.
All country codes in the request were valid.


Multi-Status. Returned in two situations:
- **Manual path:** the request was partially successful — some
  country codes were valid and processed, while others were
  invalid (see `validCODs` / `invalidCODs`).
- **Auto path** (auto-HS-entitled customer, `async != true`,
  multiple items in the request): the body is a **JSON array** with
  one element per request item, in the **same order** as the input.
  Each element is either a full classification object or an error
  object describing the failure for that slot.


Bad request. Can be caused by a malformed JSON request or invalid parameter values.

Authentication required. Can be caused by missing or incorrect credentials.

Payload Too Large. Returned when either:
- **Manual path:** the request body exceeds the approximate 60KB
  size limit. Split into multiple smaller requests.
- **Auto path:** the combined count (items × countries of
  destination) exceeds the configured per-request limit.


Unsupported media type. The `Content-type` header has to be `application/json`.

Request cannot be processed due to validation errors.

Create an HS classification request (auto-classifies synchronously for Auto HS / Auto HS Pro / Auto HS ICP customers; otherwise queues for manual classification).

Returns the HS classification code. The status field reflects the actual state of the classification request.

The hsClassificationId used to identify a request was returned in the response of the CreateHSClassificationRequest method.

hsClassificationId

Successful get HS classification request response.

Authentication required. Can be caused by a missing or incorrect credentials.

Tariff Code Classification

Section232Entry