Product
NetBox
If you run NetBox, it already knows things your terminal doesn’t: which devices terminate a circuit, who owns an IP, what lives at a site. Transit connects to it twice — as an API session the AI can investigate, and as an inventory source you can sync devices from. Both connections point the same direction: NetBox flows into Transit. Nothing syncs back, nothing runs on a schedule, and the AI has no path to any of it.
Available in Transit 6.2.0 and later.
A controller like any other — with a curated collection
Add NetBox the way you add any controller: pick NetBox as the vendor,
point the base URL at your instance plus /api (self-hosted instances and
sub-path installs both work), and paste an API token. Two token forms exist
and the preset handles the common one:
- Classic tokens (any NetBox version) ride
Authorization: Token <key>— the preset fills this. - v2 tokens (
nbt_…, NetBox 4.4+) are plain Bearer — switch the auth scheme to Bearer token.
A read-only NetBox token is the right shape: the AI can only ever read, and unless you plan to send writes from the request pane yourself, the token never needs write permission at all.
The bundled collection is a curated set of ~30 read requests generated from NetBox’s own API schema — the circuit-outage walk (circuit → terminations → devices at the site → interfaces → IPs) plus the everyday lookups: who has this IP, prefixes containing, devices by site, role, tag, or search. It’s a starting point, not an allowlist — the AI knows NetBox’s API and can propose any documented read; an unknown path just 404s.
The outage question, answered from both sides
Ask the AI: “Circuit CID-1001 is down — which devices are impacted, and what state are they in?”
It looks up the circuit in NetBox, walks the terminations to the sites, and lists the devices — every lookup a gated, host-pinned, read-only API call, each one approved by you (or auto-approved for the chat: safe to turn on here, because the tool structurally cannot express anything but a read). Opening SSH sessions to those devices stays yours — select them in the sidebar and Launch all — and the AI picks them up and continues with per-command-approved diagnostics. Your documentation becomes the AI’s context without becoming anyone’s new attack surface.
Sync your inventory from NetBox
The bulk-import pane gains a live source beside SecureCRT, MobaXterm, and CSV: pick your NetBox session, fetch, and review a diff — not a dump — computed against a stable per-device NetBox identity, so re-syncing next month updates instead of duplicating.
| What it shows | What you decide | |
|---|---|---|
| New | NetBox devices Transit doesn’t know | Import — with per-row and bulk edits |
| Changed | Matched devices whose host/vendor/site drifted | Accept or skip, per field |
| Stale | Local devices gone from NetBox | Keep (default), unlink, or delete |
The mapping does the obvious thing: the primary IP becomes the host, the site becomes the sidebar group, the platform becomes the vendor (unknown platforms become custom vendors, so your own command policies line up), and tags carry over. NetBox stores no device passwords — by design — so you map each import to an auth profile you already have.
One click applies everything atomically: if any row fails, nothing is written. Deletes are never part of the default — each one is a per-row choice, re-confirmed by name before the commit.
Wrong data can’t become quiet damage
A CMDB can be wrong, and a compromised one can lie on purpose. The sync is built so that costs you review time, not safety: every change is human-reviewed before one atomic commit; a wrong vendor still lands on a default-deny command policy with per-command approval; a wrong host meets the same first-connect host-key verification as a hand-typed one; and the AI cannot trigger, see, or shape a sync — it’s not on its tool surface.
Versions
Generated and verified against NetBox 4.x; the endpoints used are stable across NetBox 3.x and 4.x. Self-hosted and cloud instances both work — Transit talks to whatever URL you give it, over your network, with your token held by reference in your OS keyring.