Filterable index loaded from data/seeds/official-data-sources.registry.json (falls back to GET /api/official-data-sources if the static path is unavailable). Use this for integration planning and human verification — not for silent bulk scraping. Staff: pair with Intel Map profiles and Intel Map.
| Name | Jur. | ISO | Categories | Official URLs | Notes |
|---|
Sources grouped by integration category. Each card lists the access model BlueDXP staff should plan for — documented APIs, dataset downloads, partner integration programs, etc. Counts reflect the current registry.
Per-jurisdiction tiles. Click a tile to filter the Registry tab to that jurisdiction.
Sources never verified or with stale verification (default: older than 90 days) are listed below for the BlueDXP team to re-check. Requires Postgres + a successful npm run sync:official-sources-to-db on the server. Sign-in is needed: open in the same browser session as your BlueDXP login. Inline actions (verify, mark live/in-evaluation, attach Intel Map node) require official_data_sources:verify — PLATFORM_ADMIN, OPERATIONS_MANAGER, or COMPLIANCE_OFFICER.
| ID | Jur. | Name | Status | Health | Last verified | Actions |
|---|---|---|---|---|---|---|
| Press “Refresh queue” to load. | ||||||
All inline actions call POST /api/official-data-sources-verify and write to the audit log automatically. Full request shape lives in the API Explorer tab.
Copy-pasteable contracts for all endpoints in this module. Use these in Postman, Insomnia, curl, or any adapter.
Where this registry plugs into the rest of the platform. Maintain the same source IDs across modules to keep a single canonical lineage.
DB-backed curated profiles for bonded zones, hubs and ports. Link an authority to its physical/operational node via intel_map_node_key.
Operational map view. Authorities surface here once their Intel Map node is attached.
Where authority lookups appear in the customer journey (KYC, clearance, e-invoicing, AEO etc.).
How the registry, knowledge layer, and verification log fit into the BlueDXP platform.
Master operator console — cross-module dashboards.
Dispatch operations view (carriers, drivers, trips). Some authorities link here for clearance sub-flows.
npm run validate:official-sources-registry — structural validationnode scripts/validate-official-data-sources-registry.js --probe — HEAD-probe every URLnpm run smoke:official-data-sources — CI smoke (in-process, no network)npm run merge:official-sources-mena — merge MENA patch into the registrynpm run backfill:registry-iso — backfill ISO 3166 codesnpm run export:official-sources-csv -- --jurisdiction SA -o ./sa.csv — CSV exportnpm run sync:official-sources-to-db — sync registry into Postgres knowledge layerGET /api/cron-official-data-sources-health?key=<BLUEDXP_ADMIN_KEY> — daily HEAD-probe cron (writes to verification_log)Curated reading for everyone planning, building, or auditing this registry: standards bodies, similar real-world projects (so we are not reinventing wheels), open-data & integration architecture papers, and 4IR / 5IR reference material aligned with the BlueDXP platform vision.
UN Centre for Trade Facilitation & Electronic Business (UN/CEFACT). Owns UN/EDIFACT, the Single Window standards, and the LOCODE port/airport master.
Harmonized Commodity Description & Coding System (HS). Universal product taxonomy used by every customs authority in this registry.
SAFE Framework, AEO programs, Data Model 3.x — the canonical reference for every customs & clearance authority listed in the Registry tab.
FAL Convention electronic Single Window (Apr 2024 mandatory) — the “ports_maritime” category in the Playbooks tab maps to this.
Telecom standards including X.509, NGN, IoT and AI/ML reference architectures relevant to BlueDXP's IoT/edge layer.
ISO 3166 (countries), ISO 6346 (containers), ISO 8601 (timestamps), ISO 27001 (security), ISO 28000 (supply-chain security), ISO 14083 (logistics emissions).
GLN (location), GTIN (product), SSCC (logistic unit), GRAI/GIAI (assets). The “standards_identifiers” category in the Playbooks tab.
Event-based supply-chain visibility standard (REST + JSON-LD). The right wire format for chain-of-custody / cyber-physical sync, very relevant to the platform's Evidence & Lineage layer.
Data Catalog Vocabulary — the standard way to describe open datasets. Worth aligning the registry's metadata with DCAT for federated discovery.
OGC API Features, SensorThings, Records. Useful for any geofence/IoT/digital-twin extension on top of these authorities.
Lightweight semantic markup so the public registry pages can be indexed (when un-noindexed) and used by AI agents as structured data.
Pan-European spatial data infrastructure. Reference architecture for cross-border interoperability (concepts apply to GCC + MENA federation too).
Open-source data exchange backbone connecting hundreds of public-sector authorities. The closest real-world analog to a national authority registry + integration fabric. Strong reference for the “Authority connector” pattern.
Connecting Europe Facility — reference building blocks (eID, eSignature, eDelivery, eInvoicing, Once-Only) for inter-authority integration.
Curated, open dataset of sanctions, PEPs and risk — a great reference for “register + tooling + dataset” design (license-aware, daily refreshes, API + bulk).
Beneficial-ownership data standard + register implementation. Excellent example of cross-jurisdiction registry governance.
International Trade Centre — one of the few large-scale “registry of authorities + datasets” products with clear access tiers; useful UX precedent.
UN/ITC/UNCTAD/WTO joint platform that aggregates regulatory information from national portals — conceptually the cross-border twin of this registry.
Federated catalog over 1M+ datasets from EU member states. Reference for federated registries with DCAT, harvesters, and a clean policy page.
Open-source initiative (Fraunhofer + DB Schenker + Rhenus + Dachser) for logistics interoperability standards. Highly relevant for BlueDXP's adapter strategy.
International Data Spaces Association — reference architecture for sovereign data exchange across organizations. The blueprint for our planned tenant-to-tenant data exchange.
Global Legal Entity Identifier Foundation. Recommended canonical entity ID for every authority and counterparty in BlueDXP — pair with GLN for locations.
The canonical maturity model for open data quality. Use it to grade each registry source (currently at 3 to 4 stars depending on the publisher).
Open by Default, Timely & Comprehensive, Comparable & Interoperable. Drives the “policy” section of the registry.
The license a publisher grants determines whether we can mirror, transform, or only link. Always capture license per source.
Reference template for permissive use of public-sector data; widely adopted across Commonwealth jurisdictions in this registry.
Not used in trade, but the FHIR resource + capability-statement pattern is an excellent model for “profile per authority + capabilities + extensions”.
Domain-oriented decentralized data ownership. The registry is BlueDXP's “data product catalog”; this paper explains why it must stay decentralized.
Why we keep the read API public + cacheable and the write/verify API guarded. Aligned with the platform's lib/services/event-store/ pattern.
The verification_log table IS event sourcing for the knowledge layer. Reading this article first will save weeks for whoever extends the schema.
Backing services (XII), config (III), build/release/run (V) — everything we follow in vercel.json + env vars.
The original framing of 4IR (IoT, AI, big data, cyber-physical, edge). Anchors BlueDXP's connectivity-centric design.
SDG 9 (industry, innovation, infrastructure) and SDG 12 (responsible production) drive 5IR's sustainability + ESG emphasis.
EU's vision for sectoral data spaces (mobility, manufacturing, etc.). The gold standard for “authority registry → data exchange fabric”.
The emerging standard for logistics GHG accounting. Likely a future required field per registry source.
Information security management. Relevant for tenant isolation, audit logging, and the verification log retention policy.
Reference for “quantum-ready” from the platform vision. ML-KEM + ML-DSA are the FIPS-203/204 standards to plan towards for sensitive endpoints.
Industrial Internet Reference Architecture (IIRA) — the textbook for IoT + edge integrations BlueDXP plans for the 4IR connectivity layer.
Reference architecture for digital twins of physical systems (ports, fleets, warehouses). Pair with this registry to drive the “Atlas” tab evolution.
Customs Union, the GCC Standardization Org (GSO), Single Window initiatives. Authoritative starting point for any “GCC” registry row.
UN Economic & Social Commission for Western Asia. Cross-cutting policy + open data for MENA economies. Useful for indicator backfill.
Logistics Performance Index (LPI), Doing Business — canonical macro indicators per jurisdiction in the registry.
BoP, fiscal & trade data; useful for macro overlays on the Atlas tab.
The world's largest official trade data API. Gold standard for “statistics_trade” integrations referenced in Playbooks.
Aggregated trade + tariff data with REST APIs. Useful pair for any commodity classification work behind the Trade Compliance module.
Single source of truth for the platform — modules, nodes, integrations, SOPs, ISO controls, and the Git revision trail. This registry slots into the Trade Compliance and Knowledge branches.
Security checklist that the public + verify endpoints adhere to (RBAC, ETag, no info leakage in errors, magic-key cron, JWT verify-then-trust).
How to add a new authority, add a new jurisdiction, run validators, and propose schema changes.
Machine-readable contract for both endpoints. Import into Postman, Insomnia, or generate a typed client.
All external links open in a new tab. Internal links resolve to BlueDXP repo paths. If you hit a dead link or have a better reference, edit official-data-sources.html and ship a PR.
Machine JSON: GET /api/official-data-sources (optional ?jurisdiction=SA, ?q=customs, ?category=clearance_trade_platform, ?id=<source>, ?stats=1, ?group=jurisdiction|category, ?knowledge=1; ETag + CORS) · Auth-guarded knowledge: GET/POST /api/official-data-sources-verify · Validate: npm run validate:official-sources-registry · Sync to DB: npm run sync:official-sources-to-db