2.0 KiB
UniFi integration spec
UniFi is positioned as a hardware identity and telemetry source, a product-line intelligence feed, and a procurement and lifecycle signal—not only as networking gear. The platform integrates UniFi OS, UniFi Network Application, firmware catalogs, device generation, and support-horizon mapping so Sankofa Phoenix can answer: what exact hardware is deployed, what generation and firmware lineage, what support status, and is this infrastructure policy-compliant for this sovereign body?
Use cases: Discover devices, map ports, push port profiles; plus hardware identity, EoL/support horizon, and compliance-relevant metadata. Auth: API token per site (Vault). Sync: nightly; store in integration_mappings.
UniFi Product Intelligence layer
UniFi is used as a hardware identity and telemetry source, not only networking. The platform maintains a canonical UniFi product catalog (unifi_product_catalog) with:
- SKU, model name, generation (Gen1 / Gen2 / Enterprise)
- Performance class, EoL date, support horizon
approved_sovereign_defaultfor purchasing and compliance
API: GET /api/v1/integrations/unifi/product-catalog (optional ?generation=, ?approved_sovereign=true), GET /api/v1/integrations/unifi/product-catalog/:sku. Device list GET .../unifi/sites/:siteId/devices returns devices enriched with generation and support_horizon from the catalog when the device model matches.
This layer feeds purchasing (approved buy lists, BOMs) and compliance (approved SKUs per sovereign, support-risk views).
Sovereign-safe controller architecture
Per-sovereign UniFi controller domains with no cross-sovereign write. See sovereign-controller-topology.md for the diagram and trust boundaries. Optionally store controller endpoints in the unifi_controllers table (org_id, site_id, base_url, role: sovereign_write | oversight_read_only, region); credentials remain in Vault. API: CRUD under GET/POST/PATCH/DELETE /api/v1/unifi-controllers, scoped by org_id.