← All posts
How-To

Inventory & IPAM: The Source of Truth Your Scripts Actually Trust

Upload a CSV, connect to NetBox, or generate an IP range — Inventory normalises every source into the same validated row shape for the platform.

NAPT Team8 min read
Inventory and IPAMCSVNAPT

Every automation tool in history has died on the same hill: the inventory was wrong. A script can be beautifully written, the model can be brilliant, but if the device list is stale, nothing the platform says is true. Inventory is the foundation, and treating it as a side concern is the most expensive mistake a NetOps team can make.

The Inventory tab gives you four ways to populate the source of truth — file upload, IPAM connectors, IP range expansion, manual edits — and one canonical row shape that everything downstream consumes.

The canonical row

Every row carries hostname, IP, device type, site, role, vendor, model, OS version, tags, and an extensible extras map for whatever your team needs. Required fields are validated on entry; optional fields are filled from defaults when missing. The validity flag on each row is what the rest of the platform uses to decide whether a script can target it.

Upload

The upload tab accepts CSV, YAML, and JSON. Column mapping is automatic for common header names and interactive when it cannot guess. Every imported row is run through the same validators as a manual edit, so you cannot smuggle a malformed device in through the file path.

IPAM connectors

The IPAM tab generates a Python loader script for your chosen system — NetBox, Infoblox, phpIPAM, and friends — pre-filled with your filter selections. The script outputs a CSV in the canonical row shape, which you then upload. We chose this two-step pattern instead of direct API calls because it works inside air-gapped environments and gives you a script you can also run from CI.

The generator never embeds credentials in the script. Every system uses environment variables that the script reads at runtime, so the generated file is safe to commit.

IP range expansion

For greenfield work or lab builds, expand a CIDR into hosts with a hostname pattern (device-{n}), a default device type, and optional site and role. A common pattern is to seed inventory from an IP range, run discovery scripts to fill in the real metadata, and then snapshot the result.

Parameters and custom fields

The Parameters tab defines defaults applied to any row missing a value, plus the custom fields available in the row editor. Custom fields are stored in extras and surfaced in scripts via a typed accessor, so you do not have to guess at what data is present.

Preview, edit, export

The Preview tab shows the merged inventory, lets you fix individual rows, and exports back to CSV, YAML, or JSON. Exports are identical in shape to imports, which means you can roundtrip inventory between systems without losing fidelity.

Why we resisted "live IPAM as a backend"

Treating IPAM as a live backend sounds modern; in practice it couples every script run to the availability of an external system you do not control. We snapshot inventory at run time so a degraded IPAM never silently corrupts a diagnostic. When inventory must change, change it explicitly.

Tips

  • Use site and role on every device, even when you think you do not need them — every other panel groups by them.
  • Keep hostnames device-unique within a workspace; many scripts assume this.
  • When in doubt, store the extra metadata in a custom field. It is cheap; missing data is expensive.

What to try first

Import the smallest meaningful slice of your real inventory — one site, one role — and run a read-only script against it. Inventory is the kind of thing you only learn by using.

#inventory#ipam

Was this helpful?

Generate scripts for the task covered in this post

Describe what you need and NAPT writes production-ready automation in Netmiko, NAPALM, or Nornir.

Open Script Generator →
New to NAPT? Start with the Setup Guide

Related posts