UniFi Monitoring with VCF Operations Management Pack Builder

I built a custom UniFi management pack design to bring network inventory and device-health metrics into VCF Operations. It uses the local UniFi Network API without a bridge appliance; this post covers the connection, authentication, monitoring coverage and deployment workflow.

The result is a custom Ubiquiti UniFi Network management pack design, built using the Management Pack Builder built into VCF Operations. It discovers UniFi sites and adopted devices, including UDM gateways, switches, and access points, through the local Network API.

The sections below cover the August 31, 2026 revision. The original eight device metrics remain in place; port-speed metrics and WAN inventory are described in the update.

Deployment verification

• In Builder, check the collection log and the actual discovered sites and devices, not only the connection-test badge.
• After installing the design, configure and validate the integration account separately. Confirm fresh data over at least two scheduled collection cycles.
• Compare a representative device identity and health metric with the UniFi console before relying on the integration. Counts depend on your adopted inventory; the design alone does not establish a runtime result.

The design

• VCF Operations 9.1 and the built-in Management Pack Builder
• August 31, 2026 revision: installed pack version 1.0.0.2; internal design metadata remains 1.0.0
• Local UniFi Network integration v1 API through UniFi OS
• Four custom object types: UniFi Site, UniFi Device, UniFi Port and UniFi WAN Interface

The export was created with VCF Operations 9.1.0.0400.25541561 and tested against a UDM Pro running UniFi OS 5.1.29 and UniFi Network 10.5.67. Compatibility with other Operations releases, UniFi versions, and hosting layouts needs to be validated. This is a custom integration—not an official Ubiquiti or Broadcom-supported management pack.

Management Pack Builder provides REST API connections, object definitions, relationships, and metric mappings without requiring a separate collector application. VMware’s overview explains the approach.

How the management pack connects

VCF Operations collector → HTTPS → UniFi OS → local UniFi Network API

No bridge appliance is required. This design uses the local Network API, not the cloud-based Site Manager API. The collector needs network access to the console; being able to open UniFi from an administrator workstation does not prove that the collector can reach it.

Ubiquiti provides version-specific local API documentation under UniFi Network > Integrations. Check the endpoints available in your installation before deploying. Ubiquiti’s API guide explains the local and cloud API options.

Discovering sites and devices without hardcoded IDs

Collection starts with application information and site discovery, then follows the discovered IDs to devices and their latest statistics. The requests use this UniFi OS base path:

/proxy/network/integration/v1

The Sites request supplies siteid to the Devices request. Devices then supplies deviceid to the statistics request. Sites and Devices use offset/limit paging with a page size of 100. Preserve these mappings so discovery can follow the destination environment instead of relying on manually entered IDs.

Other UniFi hosting arrangements may use different paths. Validate those against the local documentation rather than assuming the UniFi OS proxy prefix applies everywhere.

Use a local API key—not a UI password

The design authenticates using an API key in the X-API-KEY header. Create an appropriate key in the local Network Integrations area and enter it in the API Key credential field in VCF Operations.

X-API-KEY: ${authentication.credentials.api_key}

That expression is a credential reference, not a key to replace in the exported file. A UniFi UI password or an unrelated cloud API credential is not a substitute. Use a dedicated key with the least access available that permits the required monitoring requests.

Keep the API key out of the JSON. Enter it in the credential field, and avoid exposing it in screenshots, copied headers, or troubleshooting logs.

For a 401 or 403 response, check that the key belongs to the target local application, is active, has sufficient access, and was entered without extra whitespace. Confirm that the X-API-KEY mapping still references the credential field.

HTTPS and certificate validation

The export defaults to port 443 and SSL Configuration set to Verify. Enter the actual HTTPS port for your console and use a trusted certificate whose name matches the collector’s connection hostname.

If certificate validation fails, check the trust chain, hostname, certificate dates, and collector connectivity. No Verify keeps encryption but bypasses server certificate validation; it should not become the default production fix. No SSL removes transport encryption.

Core device metrics retained from version 1.0

The core Site-to-Device relationship is retained from the original design. Device properties include name, model, IP address, MAC address, firmware version and state. The August 31 revision adds UniFi Port and UniFi WAN Interface objects, bringing the full design to four object types.

The three load-average values bring the total to eight device metrics. These are metric definitions, not a fixed collection count: the number of returned objects and values depends on the devices and API responses in your environment.

Check rate units before building dashboards. The uplink metrics retain raw API values without a configured unit conversion. Validate their semantics before labeling them as bits or bytes per second.

What is not included yet

This version focuses on inventory and device health. It is not a complete network-performance management pack.

• Port traffic/error counters, PoE properties and dedicated WAN-service monitoring are not included. Port state/speed and WAN inventory are included in the August 31 revision.
• Events, prebuilt dashboards, and alert definitions are not included.
• Metric availability can vary by device and UniFi Network version.
• Other API paths, hosting layouts, and Operations releases require separate validation.

Deployment at a glance

1. Prepare a local UniFi Network API key and review its permissions.
2. Confirm HTTPS connectivity and certificate trust from the intended collector.
3. Open Developer Center → Management Pack Builder and import the design JSON.
4. Configure the Source test connection with the console hostname, HTTPS port, API Key, and TLS settings.
5. Test Application Info, Sites, Devices, Latest Device Statistics, Device Details and Ports, and WAN Interfaces in dependency order.
6. Run a full collection test and inspect the objects, relationships, properties, and metrics.
7. Install the validated design, or use Upgrade when editing the existing installed design.
8. Configure the runtime integration account with its own connection settings, credentials, and collector selection.
9. Validate the account, then confirm scheduled collection and recent data timestamps.

The JSON is a Builder design—not an installable .pak. Import it into Management Pack Builder. Importing the design alone does not enable production collection.

Builder test settings and runtime integration settings should be checked separately. Do not assume that a successful Builder test means the production account is configured. If testing works but scheduled collection does not, check the runtime credentials and collector network path.

Do you need to edit the JSON?

For a normal deployment, no. The hostname default is blank, and the actual connection details belong in VCF Operations after import. Preserve the API-key reference, dynamic site/device placeholders, structural IDs, and expressions.

If a design with the same name already exists, use a unique name for the imported copy. Do not change version metadata to make an incompatible export appear compatible.

Final thoughts

This project brings UniFi network-device visibility into VCF Operations through direct HTTPS collection, without another appliance to deploy and maintain.

The current revision adds port visibility and WAN inventory to the original site/device health model. Start by validating the API responses in your environment, then build dashboards and alerts around the data you can reliably collect.