Architecture

Nine layers. One resolution. Every territorial question, answered in a single round-trip.

TLL stacks nine territorial dimensions, from raw ISO codes up through trade profile and postal format, and resolves them together. You query a place; you get the full territorial contract back.

01 IDENTITY

ISO codes

ISO 3166-1 + ISO 3166-2 + UN M.49

Canonical country and subdivision identifiers, kept in lock-step. Deprecated codes stay addressable and map to their successors.

schema iso_geo
02 POLITY

Governing state

Sovereign + autonomy + legal basis

The sovereign authority and how much autonomy the territory exercises under it. Åland resolves to FI, Greenland to DK, the Canary Islands to ES.

schema governing_state
03 LOCALE

Language

Primary + statutory language

Primary content language and the statutory language(s) under local law. Swedish for Åland, not Finnish.

schema language
04 LICENSING

Rights region

WIPO ST.3 + maps-to

IP-office territory codes and how they map to other registries, needed for licence territories and rights-region routing.

schema rights_region
05 PUBLISHING

Content profile

Typical catalogue + via

Which catalogue stacks typically inherit for this territory, and the upstream territory the inheritance chains through.

schema content_profile
06 FISCAL

Tax & customs

EU VAT / customs / excise + rates

VAT/IGIC standard and reduced rates, EU customs / VAT / excise area membership, EEA / EFTA flags, and reporting currency.

schema tax_customs
07 TRADE

Trade profile

OSS / IOSS thresholds

EU One-Stop-Shop and Import One-Stop-Shop thresholds for distance selling. These are the gating numbers most checkout stacks hard-code by mistake.

schema trade_profile
08 SHIPPING

Logistics routing

Recommended route (derived)

Domestic vs. intra-union vs. international routing, derived at decision time from L1, L2, and L9 rather than stored.

schema logistics_routing
09 POSTAL

Postal

UPU country + postcode ranges

UPU country code and postcode ranges. This is the layer the parcel label actually scans against.

schema postal
Decision endpoints

Ask the right question,
get the right answer.

TLL doesn't make you reason about standards. You ask a decision question, TLL returns a decision. Request schemas are stable; responses carry source citations.

POST /v1/vat/resolve
What VAT applies?
Returns outbound rate, the reason, and whether a customs declaration is required — every fact tied to the rule_id that produced it.
{ "from": "DE", "to": "AX", "goods_value_eur": 50 }
→ { "outbound_vat_rate": 0, "outbound_vat_reason": "Export to non-EU VAT territory" }
POST /v1/checkout/resolve
Everything, one call.
The composite endpoint most integrations use. Address + basket in, full territorial profile out. Idempotent by basket hash.
{ "address": {...}, "basket": [...] }
→ { "territory": {...}, "vat": {...}, "logistics": {...} }
POST /v1/logistics/route
How should it ship?
Recommended route (DIRECT vs VIA the governing state), customs forms emitted only when required, and the rule_id behind the choice.
{ "from": "DE", "to": "AX" }
→ { "recommended_route": "DIRECT", "customs_forms": ["CN22"] }
POST /v1/rights/resolve
Is this content licensed here?
Resolves territory → rights region with the matched license, the reason, and the commercial-practice catalog viewers actually see.
{ "user_location": "AX", "content_licensed_in": ["FI"] }
→ { "access_allowed": true, "matched_license_region": "FI", "reason": "AX maps to FI for rights region" }
In code

What it looks like over the wire.

HTTP-native, JSON-only, no SDK required. Curl is enough.

GET /v1/territories/AX 
{
  "mode": "live",
  "territory": {
    "code": "AX",
    "name_en": "Åland Islands",
    "name_local": null,
    "layers": {
      "iso_geo": { "iso_3166_1": "AX", "iso_3166_1_alpha3": "ALA", "un_m49": "248" },
      "governing_state": { "governing_state": "FI", "autonomous": true, "legal_basis": "Act on the Autonomy of Aland 1991/1144" },
      "language": { "primary": "sv", "statutory": "sv" },
      "rights_region": { "wipo_st3": null, "maps_to": "FI" },
      "content_profile": { "typical_catalog": "SE", "via": "FI" },
      "tax_customs": { "special_regime": "third_territory_for_vat", "eu_customs_union": true, "eu_vat_area": false, "eu_excise_area": false },
      "postal": { "upu_country": "AX", "postal_code_range": "22xxx" }
    }
  },
  "sources": [ /* per-fact citations */ ],
  "meta": { "request_id": "req_01H..." }
}
POST /v1/address/classify 
// Request
{
  "address": {
    "city": "Mariehamn",
    "postal_code": "22100",
    "country_input": "FI"
  }
}

// Response
{
  "mode": "live",
  "classification": {
    "tll_code": "AX",
    "rule_id": "address-classifier:postal-prefix-ax",
    "conflict_detected": true,
    "conflict_reason": "Address signals indicate AX but country_input was FI",
    "signals": { "country_input": "FI", "postal_code_match": "AX", "city_match": "AX", "ip_geolocation": null },
    "suggested_corrections": { "country": "AX" }
  },
  "sources": [],
  "meta": { "request_id": "req_01H..." }
}
Next

See where teams actually use it.

Tax compliance, sanctions screening, content delivery, fulfilment routing: the same nine layers, different consumers.

Browse use cases Contact us