How to map interfaces and IPs to hosts using /v1/entities?

Question

Hi everyone,

I’m currently working with the /v1/entities API and trying to better understand how relationships are modeled between hosts, network interfaces, and IP addresses.

So far, this is what I’m seeing in my environment:

* Network interface entities include attributes like adminStatus, operStatus, physicalAddress, speed, uri, etc.
* However, I don’t see any explicit field like hostId, and the relationships field is either missing or empty
* Some hosts have IDs in SWIS URI format (e.g. swis://...), while others have simple IDs
* I’m not finding a clear way to link:* interfaces → hosts
* IP addresses → hosts (directly or via interfaces)

What I’m trying to achieve is building a proper topology (hosts, interfaces, IPs), but I’m not sure what the recommended approach is when using /v1/entities.

A few questions for anyone who has worked with this:

* How do you map a network interface to its host using this API?
* Are relationships only populated for Observability-native entities, and not for Orion/SWIS-backed ones?
* If relationships are not returned, what’s the best practice to correlate these entities?

Any insights, examples, or pointers to documentation would be really appreciated.

Thanks!

cristina_niga7 · Answer

Hi,

Thank you, this clarifies the relationship model for Network Collector / Orion-discovered entities.

I have one additional question regarding agent-based discovery in SWO SaaS.

Can SolarWinds agents (UAMS/Observability agents) also create/discover NetworkInterface and IpAddress entities in /v1/entities, or are these entities only created through Network Collector / Orion monitoring?

If agents can also discover these entities, what is the recommended way to associate them to their parent host?

Currently, for Network Collector / Orion entities, I associate:

* NetworkInterface → Host
* IpAddress → Host

by parsing the SWIS URI from the entity response.

For agents, I associate:

* Agent → Host

using:
agent.uamsClientId == host.id

What I am unsure about is the following:

If an agent can discover NetworkInterface or IpAddress entities, what is the correct way to associate those entities to their parent host?

* Is there a field similar to uamsClientId that should be used?
* Is there a relationship field that should be populated?
* Or is another correlation method recommended?

Could you please clarify the intended model for agent-discovered interfaces/IP addresses?

Thanks!

Dmytro.Borovyk · Answer

Hi, there is a specific logic on how entities and attribues are connected

In SWO SaaS, network devices monitored by Network Collector are modeled as entities, and child resources such as interfaces are treated as discovered/associated elements of that device.

* In the current relationship inventory used internally by the platform, the relevant edges are:* NetworkDevice --Has--> NetworkInterface
* NetworkDevice --Has--> IpAddress

So for SaaS SWO, the safest interpretation is:

* A network interface is a child of a NetworkDevice
* An IP address is also a child of a NetworkDevice
* You should not assume that IpAddress is modeled as a child of NetworkInterface in the entity graph, at least not from what the current relationship model shows.

That means if you are building topology from /v1/entities, I would currently model it like this:

* NetworkDevice* Has → NetworkInterface
* Has → IpAddress

rather than:

* NetworkDevice* NetworkInterface* IpAddress

Here is an example on how it works in Exploring Metrics in UI. You can see that you're looking for a metric and then filter based on an attributed related to this metric. So when you are looking for a specifc interface or ip address, first think of specific metric you want to get like discard packets or errors or packet counts and filter on interface name or hostname or ip address related to it. Another words - metric first, attribute second. This comes from OTEL architecture where metrics, traces and logs are base and all attributes from legacy world are attached to it. Hope it make sense.