Before you begin
- A Atlas AVD plan. The Integrations hub is not available on Community
- The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
- A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
- An Omada Cloud-Based Controller, or an Omada software or hardware controller (5.9 or later) reachable at a public https address with a publicly trusted certificate
- An Omada administrator who can create an Open API application
- To sync into Vault: a Vault admin and at least one asset template (the Network Device template is a good fit)
What you can do
- Document every Omada gateway, switch and EAP access point as an Atlas Vault asset, with no manual data entry.
- Connect once per controller to cover every site the application can see.
- Map each Omada site to the customer company it belongs to.
- Keep the documentation current: every hour Atlas adds new devices, updates changed details and archives devices the site no longer has.
- See what changed and when: firmware, management IP, model, name, site and uplink changes, each with the previous value kept.
- Ask Atlas Advisor about documented equipment, for example "Which Omada devices are disconnected?"
Step 1: Create an Open API application
- In the Omada controller, open the Global view and go to Settings → Platform Integration → Open API, then add an application.
- Choose Client mode, and give it a Viewer role whose site privileges cover the sites Atlas should document. A viewer cannot change anything.
- Open the application's details and copy four values: the Interface Access Address, the Omada ID, the Client ID and the Client Secret.
- A Cloud-Based Controller's Interface Access Address is a TP-Link address such as https://use1-omada-northbound.tplinkcloud.com. A self-hosted controller's is its own https address.
Step 2: Connect in Atlas
Once connected, the card shows Manage, which opens Atlas Vault → Assets, and Disconnect. The client secret is stored encrypted and is never shown again. Atlas exchanges it for a short-lived access token at the start of each sync and never stores the token.
- Select the tenant in the tenant picker.
- Go to Administration → Integrations and click Connect on the TP-Link Omada card.
- Enter the Interface Access Address, Omada ID, Client ID and Client Secret.
- Click Connect. Atlas signs in and lists your Omada sites before saving anything; if the credentials are rejected, nothing is stored.
A self-hosted controller must be reachable from Atlas at a public https address with a publicly trusted certificate. Atlas never connects to private addresses and never turns off certificate checks, so a controller still on its factory self-signed certificate is refused. Cloud-Based Controllers already meet both.
Step 3: Map each site to a company
Add one sync per site. Each site can be mapped only once in an Atlas tenant, so its equipment never ends up under two companies.
- Open Atlas Vault → Assets → RMM & PSA sync and click Add sync.
- Source: TP-Link Omada.
- Device type: pick an Omada site.
- Template: pick Network Device. Atlas fills in the field mappings for you: Name, Type, Manufacturer, Model, Serial Number, Management IP, MAC Address, Firmware Version and Location. You can change or add any mapping.
- Company: the customer this site belongs to.
- Leave Sync automatically every hour on, click Save Changes, then click Run now to document it straight away.
What gets documented
- Identity: name, serial number, MAC address, manufacturer (TP-Link), model and hardware version.
- Type: Gateway, Switch or Access Point.
- Network: the device's IP address and, for a gateway, its public IP address.
- Software: firmware version.
- Operational: connected, disconnected, pending, heartbeat missed or isolated.
- Placement: the Omada site, the device's tag, and the switch or gateway port it is uplinked to.
Devices are matched by serial number (or by MAC address when the controller reports no serial), so renaming a device or changing its IP updates the same asset instead of creating a new one. Connected clients, SSIDs, VLANs and port profiles are not documented.
Your own documentation is kept
Atlas only fills the fields you map. Notes, attachments, custom fields and anything else you add in Vault are yours and are never touched. If you edit a mapped field by hand, Atlas keeps your value; if Omada later reports something different, the field is flagged under Drift to review so you can choose which to keep. A device the site no longer has is archived, not deleted, and comes back automatically if it returns. Atlas archives a device only after a complete read, so an unreachable controller or a rejected secret never empties your documentation.
Change history
Open an asset's ⋯ menu and choose History to see what changed: when the device was first documented, a new name, model, management IP, MAC address, firmware, site or uplink (each with the previous and new value), when it was no longer reported, and when it came back. Routine connected and disconnected changes are not recorded. The same entries appear on the Operations Timeline.
Ask Atlas Advisor
Atlas Advisor answers questions from the documented assets, read-only and limited to what you can see in Vault, with or without an AI provider. For example: "list our Omada switches", "Which Omada devices are disconnected?", "What firmware are our TP-Link access points running?" or "Is TP-Link Omada connected?".
What the integration does not do
- It is read-only. It never changes configuration, adopts or reboots devices, or upgrades firmware.
- It does not document connected clients, SSIDs, VLANs or port profiles.
- It does not connect to a controller on a private network or with a self-signed certificate.
- It syncs every hour or when you click Run now; the interval cannot be changed.
- It connects one Omada application per Atlas tenant. Credentials cannot be edited in place: disconnect and connect again with the new values.
GCC High tenants
On a tenant or deployment in Azure Government (GCC High), calls to TP-Link Omada are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from TP-Link Omada stay empty. The operator who runs your Atlas deployment can approve TP-Link Omada as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.
Disconnecting
Click Disconnect on the card and confirm. Atlas deletes its stored copy of the client secret and pauses every Atlas Vault sync from Omada. The documented assets and their history stay in Vault; turn the syncs back on after you reconnect. Nothing changes in the Omada controller. Delete the Open API application there too if you no longer need it.
Troubleshooting
- The connection test reports that sign-in failed: the Client ID, Client Secret or Omada ID is wrong, or the application was deleted.
- The connection test cannot connect: check the Interface Access Address, and that a self-hosted controller is public and presents a publicly trusted certificate.
- A site is missing from the Device type list: the application's role does not include it. Add the site to the role, then add the sync again.
- A sync fails for one site: the controller could not return its devices, for example because it was unreachable. The documentation is kept until the next successful sync.
- A sync reports the integration is not configured: TP-Link Omada was disconnected. Connect it again, then turn the sync back on.