UniFi API Browser: reading what the controller exposes
Tool to browse data exposed by Ubiquiti's UniFi Controller API
At a glance
- What is it?
- The UniFi API browser is a small PHP tool that exposes the data behind a Ubiquiti controller, with both a classic username and password client and a client for the official API key based Network Application API. It suits an administrator or developer who needs to see fields the web interface hides, and it must be installed on your own network rather than exposed to the internet.
- Who is it for?
- Adopt the UniFi API browser when you need to see what a controller actually returns, because it gives you the raw collections behind the web interface, the API key based official endpoints, and a JSON output you can pipe into other tooling, which is what makes it useful for troubleshooting and for building on top of the API.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Two API clients, because Ubiquiti has two APIs
The UniFi API browser is a tool for browsing data exposed through the UniFi Controller API, written in PHP and JavaScript with the Bootstrap CSS framework. What it does not do is hide a structural fact about Ubiquiti's product line, which is that there are two APIs and they authenticate differently.
The tool ships with both clients. The classic PHP API client, UniFi-API-client, handles username and password authentication against the classic UniFi Controller API. The official UniFi Network Application API client, unifi-network-application-api-client, handles API key authentication against the official UniFi Network Application API.
That distinction is not academic. The classic controller API is the one the UniFi web interface itself talks to, and it has accumulated a long, slightly irregular surface of endpoints. The official API is the vendor-sanctioned one, keyed rather than credentialed, and it is the one a new integration should be built against. A tool that speaks both lets you compare what the two expose on the same hardware, which is genuinely useful, and it lets you keep using the classic surface for the endpoints the official API has not implemented yet.
Support for the classic API covers versions 5.X.X through 11.X.X of the UniFi Controller or Network Application software, with version 11.0.89 confirmed to work. The official API path requires a Network Application that supports API key authentication, and Network Application on UniFi OS based consoles and servers is also supported.
The 11.x statistics migration is the sharpest edge
If you run a recent controller, one section of the README deserves a careful read, because it describes a set of endpoints that silently stop working.
Network Application 11.x moved all time-series statistics to a new statistics engine and removed several legacy endpoints. On 11.x the legacy interval statistics collections, which are the 5-minute, hourly, daily and monthly statistics for sites, access points and gateways along with the speedtest results, return empty results. And the dashboard metrics, events, alarms and IDS/IPS events collections return an error rather than data.
The fix is documented and specific. Use the collections marked for 11.x in the Stats menu, and use the system log collections in the Messages menu instead. There is also a statistics source collection that shows which engine a controller uses, either LEGACY or MODERN, and that is the quickest way to tell which set of collections will actually return something.
This is the kind of detail that separates a project with real field experience from a wrapper written against documentation. An empty result set with no error message looks exactly like a broken tool, and a maintainer who has hit that has written down how to avoid it.
One more limitation is stated plainly: the tool does not support all available data collections and API endpoints, and the README lists the ones that are implemented. What is not in that list is not available in the browser, so the list is the real feature set rather than the marketing description.
Collections, sites and controllers, and the two switchers
The feature list is a good description of the shape of the tool, and the two switchers in it are what make it usable on a network with more than one controller.
The first is switching between multiple controllers of different types from the dropdown menu. That matters because the official API and the classic API are configured differently, and a network with a UniFi OS console running one version and an older appliance running another would otherwise need two instances of the tool.
The second is switching between sites managed by the connected controller, with auto-selection when only one site is available. Sites in the classic model are the tenant boundary for policies, and the collections are scoped to the current site, so this is a parameter of every request rather than a filter applied afterwards.
The output format switcher offers JSON, JSON highlighted, PHP array, interactive, and PHP array highlighted. The five options are aimed at different consumers. Plain JSON is for piping into jq or another tool. The highlighted variants are for reading in a browser. The PHP array forms are for a developer who wants to paste a response straight into a PHP session or a var_dump, and the interactive mode is for browsing a large collection interactively rather than scrolling a wall of text.
Copy to clipboard is available with the JSON output format, and the README notes it fails gracefully with large collections, which is the right way to handle a browser tab choking on a multi-megabyte response.
The classic collection list is the documentation of the old API
The implemented collections for classic controllers are listed in full, and the list is itself the most useful reference in the repository for anyone writing against that API without a browser.
Under Configuration there are list sites on this controller, list site settings, list admins for the current site, system information (sysinfo), self, list wlan config, list VoIP extension, list network configuration, list port configurations, list port forwarding rules, list firewall groups, list current channels, list DPI stats, dynamic DNS configuration, list country codes, and list Radius accounts, which is supported on controller version 5.5.19 and higher.
Under Clients and users there are list online clients, list guests, list users, list user groups, stat all users, stat authorisations and stat sessions. Under Devices, list devices covering access points, USG routers and USW switches, list wlan groups, list AP groups for version 6.0.X and higher, list rogue access points, and list devices tags for version 5.5.19 and higher.
The version annotations on those entries are the useful part. They tell you that a given collection simply does not exist on older controller software, which is a different failure from an empty response and one you can predict once you know your controller version.
The Stats section is the largest, and the 11.x entries mixed in with the legacy ones are the reason the statistics source collection matters. The Stats section also includes port forward stats and DPI stats, a reminder that the classic API mixes configuration and telemetry in one surface.
The official API collection list is a proper resource model
The official API collections read like a proper REST resource model, and comparing them with the classic list tells you what the vendor considers the clean shape of the interface.
Under Application there is application info, and under Sites a list of sites. Devices covers list adopted devices, list pending devices and device statistics. Clients has list clients, Networks has list networks, WiFi has list WiFi broadcasts, and Hotspot has list vouchers.
The network configuration side is grouped by area. Firewall lists firewall zones, firewall policies, ACL rules, traffic matching lists and DNS policies. Switching lists switch stacks, MC-LAG domains and LAGs.
And then there is a Supporting Resources group, which is the interesting one: WAN interfaces, site-to-site VPN tunnels, VPN servers, RADIUS profiles, device tags, DPI categories, DPI applications and countries. These are the things a classic API user has to dig out of a configuration blob, and here they are first class resources with a list endpoint each.
That is a fair indication of where to build new work. If you are writing a new integration against a UniFi controller, the official API is the surface to learn, and this tool is the fastest way to see the shape of the data it returns without writing a client first.
Setup, output formats, and the 2.x to 3.x upgrade
The tool is a PHP application with a Bootstrap front end, and the setup is described as very easy with minimal dependencies. The repository layout reflects a conventional PHP application: index.php and login.php at the root, an ajax/ directory for the asynchronous parts, a collections.php and a collections-official.php holding the two collection definitions, common.php, templates/ for the Twig output, js/ and css/ for assets, a config/ directory, and a vendor/ directory for the installed dependencies, with a composer.json and composer.lock to pin them.
Version 3.0.0 changed the requirements, and if you are coming from 2.x the upgrade notes are the part to read first. PHP 8.1 or higher is now required, previously PHP 7.4. Twig 3.x replaces Twig 2.x, which was end of life. Kint 5.x replaces Kint 3.x for PHP 8.1 compatibility. Official API support arrived, so you can configure API key controllers alongside the classic username and password ones, and a controller with a single site now has that site selected automatically. One subtlety worth noting: custom menu entries added in config.php apply only to classic controllers and are hidden when an official API controller is selected.
When upgrading you are told to update your config/config.php based on the new config/config-template.php, and that existing classic controller entries continue to work without changes.
Beyond the browsing itself there are a few small features that make it a work tool rather than a toy. You can switch between the default Bootstrap theme and the Bootswatch themes, and there is an About modal showing version information for PHP, cURL and the UniFi Controller, which is the fastest way to diagnose a connection problem. Timing details of API calls are shown, and the README suggests they can be useful to benchmark your controller. Debug mode for troubleshooting cURL connections is enabled by setting $debug to true in the config file. The release history shows v3.1.0 on 2026-10-19, v3.0.0 on 2026-02-23 and v2.0.36 on 2025-10-09, with the last push to master on the same day as v3.1.0.
Editorial conclusion
Adopt the UniFi API browser when you need to see what a controller actually returns, because it gives you the raw collections behind the web interface, the API key based official endpoints, and a JSON output you can pipe into other tooling, which is what makes it useful for troubleshooting and for building on top of the API. Do not install it on a controller you do not own, and do not expose it to a network you do not control, because the tool talks to the controller with administrative credentials. Before you deploy, read the security notice the README points to, check whether your controller runs the legacy or the modern statistics engine, and confirm your PHP version is 8.1 or newer, since 3.x dropped 7.4.
Frequently asked questions
What does the UniFi API browser actually show?
It browses the data collections and API endpoints exposed by a UniFi controller, including configuration such as list wlan config, list port forwarding rules and list firewall groups, client and user listings, device listings, and the statistics collections. The README notes the API exposes more data than the controller's web interface shows, which makes it useful for troubleshooting.
Why do the statistics collections return empty on Network Application 11.x?
Version 11.x moved all time-series statistics to a new statistics engine and removed several legacy endpoints, so the 5-minute, hourly, daily and monthly statistics for sites, access points and gateways and the speedtest results come back empty, and the dashboard metrics, events, alarms and IDS/IPS events collections return an error. Use the 11.x collections in the Stats menu and the system log collections in the Messages menu, and check the statistics source collection to see whether the controller is LEGACY or MODERN.
How do I authenticate the UniFi API browser against a controller?
Two ways are supported. The classic PHP API client uses username and password against the classic UniFi Controller API, supporting controller versions 5.X.X through 11.X.X with 11.0.89 confirmed. The official UniFi Network Application API client uses API key authentication and requires a Network Application that supports it.
What are the requirements for version 3 of the UniFi API browser?
PHP 8.1 or higher is required, previously it was PHP 7.4. Version 3.0.0 also moved from Twig 2.x to Twig 3.x and from Kint 3.x to Kint 5.x, and the upgrade guidance says to update your config/config.php from the new config/config-template.php, with existing classic controller entries continuing to work unchanged.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/art-of-wifi-unifi-api-browser)Was this useful?