Global Landed-Cost & Tariff-Change Monitor

The US eliminated the de-minimis exemption February 24, 2026 (made indefinite June 24, 2026). The EU removed its €150 low-value exemption July 1, 2026. Effective landed duty on some China-origin products now exceeds 50%. If your pricing model was built on last quarter's duty number, it's probably wrong now — and it'll be wrong again the next time a rate changes, silently, with no notification unless you're watching for it.

What it does

Looks up the current duty stack for an HS code / origin / destination against up to three real customs systems (US HTSUS, EU TARIC via Access2Markets, UK Global Tariff), and — the core value — diffs the result against what it saw last time, flagging exactly when a rate has moved since your last check.

Verified, not assumed

All three jurisdiction integrations were tested against real, live government data while building this actor — including deliberately catching and fixing two real bugs this way (a KV-store key-format rejection, and a US search-API quirk that silently returned zero results for zero-padded codes) before they'd have shown up as silent wrong answers in production:

• EU reads the same JSON endpoint the EU's own official Access2Markets tool (trade.ec.europa.eu) calls internally — found by inspecting its Angular bundle, confirmed live against real HS codes. It correctly surfaced the EU's brand-new "Low-value consignment customs duty" (effective 01/07/2026, exactly the regulation this actor exists to track), and correctly returned the real, itemized company-specific anti-dumping (62.10%) and countervailing (17.20%) duties on Chinese e-bikes on top of the 6% base rate — a real 85.3% effective duty, verified against actual EU trade law data, not fabricated.
• UK uses trade-tariff.service.gov.uk's own published, documented JSON:API. Verified live that its "Third country duty" measure (type 103 — the same code the EU system uses, since both derive from the shared pre-Brexit TARIC classification) resolves to a real percentage.
• US uses USITC's own public HTS search API (hts.usitc.gov). Verified live for base MFN/Column-1 rates.

The honest limitation: US Section 301 / 232 / IEEPA duties

This actor does not attempt to calculate Section 301, Section 232, or IEEPA "reciprocal tariff" additional duties for US imports. This isn't a shortcut — it was tested for. A known Section-301-affected category (bicycles, HS 8712) was queried against USITC's own API, and its additionalDuties field came back null/unpopulated on every single result. Those duties live in HTS Chapter 99 "temporary modification" subheadings, cross-referenced by origin country and effective-date window through a process no public USITC API exposes per-product — a genuine pain point in real customs practice, not a gap unique to this actor. baseDutyRate for US results is real and correct; for China-origin goods specifically, treat it as a floor, not the full picture, until Chapter 99 is manually cross-referenced or a paid compliance data source is layered on top.

EU and UK do not have this gap — their anti-dumping/countervailing/temporary duties are joined to the base lookup and included automatically.

Input schema

{
  "mode": "monitor",
  "jurisdictions": ["us", "eu", "uk"],
  "productValue": 1000,
  "watchList": [
    { "hsCode": "8517140000", "originCountry": "CN", "destinationCountry": "DE" }
  ]
}

mode: "monitor" (default) walks watchList; mode: "lookup" does a single one-off check using top-level hsCode/originCountry/destinationCountry. Per the x402/agent-payable design constraint for this build batch, monitor is the default — scheduled/agent callers want deltas, not full re-pulls.

For EU checks, destinationCountry is normalized to a real EU member state internally if you pass a non-member code (e.g. GB, US) — EU duty is bloc-wide and doesn't vary by which member state is named, but the underlying API returns a completely different, incompatible response shape for non-member destinations, so this actor picks a representative member (Germany) rather than pass a value that would silently break the lookup.

UK codes: the UK's 10-digit commodity codes don't always follow from zero-padding a shorter 6-digit HS heading — verified live that this works for some products and 404s for others where the heading splits into several non-zero-suffixed children. Provide the full 10-digit UK commodity code where precision matters; a shorter code is a best-effort heuristic, not a guarantee.

Output schema

{
  "hsCode": "string",
  "originCountry": "string",
  "destinationCountry": "string",
  "jurisdiction": "us | eu | uk",
  "baseDutyRate": "number (%) | null",
  "additionalDuties": [
    { "type": "section_301 | section_232 | ieepa | eu_temp_duty | anti_dumping | countervailing | other", "rate": "number (%) | null", "description": "string" }
  ],
  "totalEffectiveDutyRate": "number (%) | null",
  "estimatedLandedCost": "number | null",
  "rateChangedSinceLastRun": "boolean",
  "previousRate": "number | null",
  "sourceUrl": "string",
  "checkedAt": "ISO timestamp",
  "status": "success | failed"
}

anti_dumping and countervailing extend the PRD's original 5-value enum — added after finding EU data genuinely returns these as distinct, separately-regulated duty categories (confirmed against Chinese e-bikes), not folded into eu_temp_duty or other.

Flat per-item duties (like the EU's new €3/item low-value consignment duty) appear in additionalDuties with a descriptive note but a null rate and aren't folded into totalEffectiveDutyRate/estimatedLandedCost — turning a flat fee into a %-of-value figure needs item count, which isn't in this actor's input schema. The duty itself is never hidden, just not double-counted into a number it can't accurately produce.

Delta detection

Every lookup is diffed against the last time this same HS code / origin / destination / jurisdiction combination was checked, using a generic KV-store-backed delta module (src/shared/deltaStore.ts) built to be reused as-is in Actor 27 (Sanctions/PEP Delta Feed) per the build program's own sequencing — that module has no tariff-specific fields, only a generic key + value + equality check.

previousRate: null on an entity's first-ever check is expected (nothing to diff against yet), not a failure.

Pricing

Event	Price
Run started	£0.05
Lookup checked (no change)	£0.03
Rate change detected	£0.06
Lookup failed	free

Setup note

No browser needed — all three jurisdictions work over plain HTTP with realistic headers, so this runs on the lightweight apify/actor-node:20 base image.

n8n integration

• Workflow A (trigger): scheduled weekly run against a watch list of your (or clients') imported SKUs.
• Workflow B (processing): alert when rateChangedSinceLastRun: true, with old rate vs. new rate and estimated margin impact from estimatedLandedCost.