Home/Offers/Logistics & Supply Chain/Customs Document Intelligence API

Logistics & Supply Chain

Customs Document Intelligence API

A customs entry fails for the same reasons every time: a field left blank, a value in the wrong currency, a description that will not support the code claimed.

Freight forwarders
Customs brokers
Trade compliance software
E-commerce exporters
3PLs

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Customs operations run on documents that arrive in whatever form the shipper felt like sending. A commercial invoice as a photographed PDF, a packing list in a spreadsheet with merged cells, a certificate of origin as an image in an email body. Somebody rekeys all of it into the declaration system, and that rekeying is where the errors enter — a transposed value, a missing net weight, an incoterm nobody filled in.

The costs of those errors are not evenly distributed. Most produce a query and a delay. Some produce a held consignment and storage charges. A few produce a penalty, and the ones involving misdeclared value or an incorrect classification can escalate well beyond the cost of the shipment. The error rate is a direct function of how much manual rekeying happens.

Classification is the genuinely difficult part, and it needs stating plainly. Assigning a tariff code is a legal determination with liability attached, made against the nomenclature, explanatory notes, binding rulings and the specific facts of the goods. Software can narrow the candidates, surface the relevant notes and flag when a description cannot support a claimed code. It cannot take on the responsibility, and nothing in this build should be read as doing so.

Who buys this

Freight forwarders, Customs brokers, Trade compliance software, E-commerce exporters, 3PLs

Category: Logistics & Supply Chain

What the API returns

What comes back

Structured field extraction from invoices, packing lists and transport documents
Confidence per extracted field, with low-confidence fields routed to review
Missing and inconsistent field detection against declaration requirements
Cross-document reconciliation: invoice against packing list against transport document
Candidate tariff classifications with the reasoning and the notes relied on
Flags where a goods description will not support the code claimed
Country-of-origin and preference documentation completeness checks
An audit trail linking every extracted value to its location in the source document

Endpoints

Method	Path	Returns
POST	/v1/documents/extract	Extract structured fields from an uploaded document
POST	/v1/shipments/validate	Validate a document set against declaration requirements
POST	/v1/classify/suggest	Candidate tariff codes with reasoning for review
POST	/v1/reconcile	Cross-check a document set for inconsistencies
GET	/v1/requirements/{country}/{procedure}	Required fields and documents for a procedure
POST	/v1/reviews	Record a broker decision for audit and model feedback

Request and response

illustrative

Request

{
  "shipment_ref": "SHP-2026-10-4471",
  "destination_country": "GB",
  "procedure": "import_release_for_free_circulation",
  "documents": [
    { "type": "commercial_invoice", "file_id": "fil_8821" },
    { "type": "packing_list", "file_id": "fil_8822" },
    { "type": "bill_of_lading", "file_id": "fil_8823" }
  ],
  "classification_assist": true
}

Response

{
  "shipment_ref": "SHP-2026-10-4471",
  "extraction": {
    "invoice_number": { "value": "INV-99120", "confidence": 0.99 },
    "invoice_total": { "value": 48210.00, "currency": "USD", "confidence": 0.97 },
    "incoterm": { "value": null, "confidence": 0.0, "status": "missing" },
    "net_weight_kg": { "value": 2140.0, "confidence": 0.71, "status": "review" },
    "country_of_origin": { "value": "VN", "confidence": 0.94 }
  },
  "validation": [
    { "code": "missing_required_field", "field": "incoterm", "severity": "blocking" },
    { "code": "currency_mismatch", "detail": "Invoice in USD; packing list values in EUR",
      "severity": "warning" }
  ],
  "reconciliation": [
    { "field": "gross_weight_kg", "invoice": 2410.0, "bill_of_lading": 2460.0,
      "variance_pct": 2.1, "severity": "info" }
  ],
  "classification_candidates": [
    { "line": 1, "description": "Aluminium brackets, powder coated, for shelving",
      "candidates": [
        { "code": "7610.90.90", "confidence": 0.62,
          "reasoning": "Aluminium structures and parts thereof",
          "notes_relied_on": ["Chapter 76 note 1", "GIR 1"] },
        { "code": "8302.42.00", "confidence": 0.24,
          "reasoning": "Base metal mountings and fittings for furniture" }
      ],
      "requires_broker_determination": true,
      "insufficient_description": false }
  ],
  "audit": { "field_provenance": "fil_8821:page1:bbox[412,880,610,902]" }
}

Where the data comes from

Your document archive	Historical invoices, packing lists and declarations with the outcomes, which is the training and validation material
Published tariff nomenclature	Official tariff schedules and explanatory notes from the relevant customs authority, which are public and authoritative
Binding rulings and classification decisions	Published rulings, where available, which are what a broker actually reasons from
Declaration requirement specifications	Published field and document requirements per country and procedure, which change and must be tracked
Exchange rate references	Official customs exchange rates, which differ from market rates and are specified per period
Your broker decisions	Recorded determinations and corrections, which are the feedback that makes the suggestion model better over time

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Layout-aware extraction rather than plain text OCR, since customs documents carry meaning in table structure and position
Per-field confidence with a routing threshold, so uncertain fields reach a human instead of entering a declaration silently
Validation against published requirement specifications per country and procedure, maintained as those specifications change
Cross-document reconciliation with tolerances, since small weight variances are normal and large ones are not
Classification as a retrieval and ranking problem over the nomenclature and notes, returning reasoning and the notes relied on rather than a bare code
Explicit detection of descriptions too vague to classify, which is a more useful output than a confident guess
Full field provenance down to the document region, because a customs audit asks where a number came from
Accuracy measured per field type and per document quality band, with scanned and photographed documents reported separately from digital ones

What it changes for the business

Less rekeying

Extraction removes the manual step where most declaration errors originate.

Problems found before submission

Missing fields and inconsistencies surface while the shipment can still be fixed cheaply.

Faster classification review

A broker reviewing ranked candidates with the notes attached works faster than one starting from the nomenclature.

Audit readiness

Field-level provenance makes an audit a retrieval exercise rather than an archaeology project.

How it fits into your product

How it embeds

Documents posted from your existing intake, whether email, portal or EDI attachment
Extraction results returned as structured JSON for your declaration system to consume
Review queue endpoints for fields and classifications routed to a human
Broker decisions posted back, both for audit trail and for model feedback
Webhooks on blocking validation failures so a shipment is stopped before submission
Deployment inside your infrastructure, which most brokers require for trade documentation

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Does this replace our customs broker?

No, and that is not a disclaimer we are adding for comfort — it is the design. Tariff classification and declaration accuracy carry legal liability that sits with the declarant and the broker, and no API takes that on. The service extracts data, checks completeness, and ranks candidate codes with the notes behind them. A licensed broker makes the determination, and the API records that they did.

How accurate is the extraction?

It depends heavily on document quality, and we report it that way. Digitally generated PDFs extract at high accuracy on standard fields. Photographs of printed invoices, documents in unfamiliar layouts and handwritten annotations are materially worse. Rather than a single accuracy claim we publish per-field, per-quality-band figures and route anything below threshold to review.

Can it classify goods automatically for low-value shipments?

It can suggest, and for high-volume homogeneous flows the suggestion will be right most of the time. Whether you accept a suggestion without broker review is a compliance decision with liability attached, and it depends on your authorisations, your volumes and your risk appetite. We will build the controls and the audit trail for whichever policy you adopt; we will not recommend bypassing review to save time.

What happens when a description is too vague to classify?

The API says so explicitly rather than ranking candidates against inadequate information. An insufficient-description flag is more useful than a 40 per cent confidence code, because it tells the operator to go back to the shipper, which is the only correct action.

Do declaration requirements not change constantly?

They do, and keeping the requirement specifications current is a real ongoing cost rather than a one-off build. We would scope that maintenance explicitly, per country and procedure in your scope, and we would rather cover five jurisdictions properly than claim forty and let them drift.

All Logistics & Supply Chain offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers