NetBox

Lattice and NetBox are both “IPAM” in conversation and not the same product. NetBox is a DCIM/CMDB: racks, cables, circuits, and an addressing plan. Lattice is DDI: that plan plus DHCP pools, reservations, and live leases.

If both write the same CIDR, you get two sources of truth. This integration is a bulk copy of prefixes, on purpose — not a live sync with a stored NetBox token.

Hub: integrations. Coming from Microsoft DHCP, ISC, or Kea is a different job: migrate.

Vendor documentation (auth headers, pagination, and prefix fields change between NetBox releases). Use these for the latest dump steps; this page is what Lattice accepts on import.

Just show me the steps — dump + POST at the bottom.

1. Who is master (and why)

Import only creates missing prefixes. It never deletes Lattice objects, never writes pools, never touches leases. If a prefix already exists (same CIDR), it is skipped. That is the safety valve: a NetBox cleanup cannot empty Lattice DHCP.

Export is the other direction: dump Lattice’s plan so your script can POST into NetBox. Lattice does not call the NetBox API.

2. Why there is no “NetBox URL + token” in Lattice

A live pull would mean Lattice stores a NetBox token that can read (and, if mis-scoped, write) the CMDB. It would also mean Lattice has to speak every NetBox version’s pagination and tenancy. The product choice is:

1. You dump prefixes from NetBox (GET /api/ipam/prefixes/).
2. You POST that JSON to Lattice.
3. Lattice never holds a NetBox credential.

The console More → NetBox is that paste box, plus an export of what Lattice already has.

3. Export (Lattice → file / your script)

curl -s http://127.0.0.1:8080/api/v1/integrations/netbox/export \
  -H "authorization: Bearer $TOKEN"

{
  "prefixes": [{"prefix": "10.20.0.0/16", "description": "plan", "status": "container"}],
  "subnets": [{"prefix": "10.20.20.0/24", "gateway": "10.20.20.1", "status": "active"}]
}

Map prefixes to NetBox Prefix (status container/active). Map subnets to Prefix (or your role of choice). Do this with your own script if you need live POST /api/ipam/prefixes/ against NetBox.

Export is a snapshot. It is not a webhook. For “something changed in Lattice,” use webhooks (ipam.audit) and then decide whether NetBox should learn it.

4. Import (NetBox list → Lattice prefixes)

Dump prefixes from NetBox. Current NetBox docs use Authorization: Token … (some releases also accept Bearer — follow your version’s REST API page).

?limit=0 is not “return every prefix” unless that NetBox instance has MAX_PAGE_SIZE disabled. By default, list endpoints paginate (often 50 per page, capped around 1000). Follow the next URL in the JSON until it is null, or page with limit and offset as NetBox documents.

curl -s -H "Authorization: Token $NETBOX_TOKEN" \
  "https://netbox.example.com/api/ipam/prefixes/?limit=1000" \
  > /tmp/nb-prefixes.json
# If "next" is set, fetch that URL too and concatenate "results".

POST the file to Lattice. Duplicates (same CIDR) are skipped.

curl -s -X POST http://127.0.0.1:8080/api/v1/integrations/netbox/import \
  -H 'content-type: application/json' \
  -H "authorization: Bearer $TOKEN" \
  -d @/tmp/nb-prefixes.json

Accepted shapes: NetBox’s { "results": [ { "prefix": "10.30.0.0/16", "description": "…" }, … ] } or { "prefixes": [ … ] }.

After import you still have to carve subnets and pools in Lattice. A prefix without a subnet is a drawing, not DHCP.

5. What this will not do

Just the steps

Follow NetBox pagination (next / limit+offset). limit=0 is not “all prefixes” unless that instance disabled MAX_PAGE_SIZE.

curl -s -H "Authorization: Token $NETBOX_TOKEN" \
  "https://netbox.example.com/api/ipam/prefixes/?limit=1000" \
  > /tmp/nb-prefixes.json
# If JSON "next" is set, fetch that URL and concatenate "results".

curl -s -X POST http://127.0.0.1:8080/api/v1/integrations/netbox/import \
  -H 'content-type: application/json' \
  -H "authorization: Bearer $TOKEN" \
  -d @/tmp/nb-prefixes.json

Then carve subnets and pools in Lattice. Do not store a NetBox token in Lattice.