Nested per-item / per-COD errors inside a 207ClassificationResponse 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.
—
Groups content-level changes by country for a given HS root.
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.
—
—
—
—
—
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.
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.
Describes a single content-level nomenclature change.
Defines the content-level general nomenclature notification. The changes use a nested structure, grouped by HS root and country, following the path changes[] -> changedCountries[] -> changes[].
Provides a high-level summary of the content-level nomenclature changes included in the notification.
—
multipart/form-data body for the document-upload variant of this endpoint. Submit a PDF
and/or image(s); the service reads them into classification object(s) and classifies them.
At least one of pdf, images, text, imageUrl, or url must be supplied. The
classification-intent fields (classificationType, classifications, countryOfDestination)
are applied to every product extracted from the document(s). Files are validated for type,
size (≤ 25 MB/file, ≤ 50 MB total, ≤ 10 files), page count (≤ 50), readability, encryption,
and image quality before extraction.
—
Describes a single duty rate change.
Defines the duty rate notification. The payload uses a flat changes[] envelope where each change is based on the HS code and rate and does not include catalog items. The rate is expressed as nested previous and current objects.
Describes 1 side, either the previous or current value, of a duty rate.
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 403 / 413 / 422 / 503 / 500 on POST .../classifications;
those responses use AvaTaxError. Gateway 401 also uses AvaTaxError.
—
—
—
—
—
—
—
—
—
—
—
—
Describes a single item-level change. For a TARIFF_CHANGE event, hsCode is the new code.
Defines the item-level notification. The payload uses a flat changes[] envelope where item identity is carried inline on each change. The eventType value is either TARIFF_CHANGE or INVALID_HSCODE.
—
—
—
—
—
—
—
—
Groups content-level changes by HS root.
—
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.
