Product
API sessions
Not every device speaks SSH. UniFi controllers, cloud dashboards, SDN fabrics — and sources of truth like NetBox — are driven over HTTP/REST. API sessions bring those into the same workspace: a full API client you drive yourself, plus the same investigation-only AI — now able to investigate a controller, not just a terminal.
It’s the same principle as the SSH side, in a second surface: you can do anything; the AI can only look.
Two actors, one session
| You (the API client) | The AI agent | |
|---|---|---|
| Methods | Any — GET / POST / PUT / DELETE | GET only |
| Gated? | No — like typing at the terminal | Yes — GET-only gate and your click |
| Response | Raw (your own controller) | Redacted before the model sees it |
| Price | Free | The AI subscription |
The human path is a request builder — method, path, query, headers, body —
with a response panel (pretty/raw JSON, a Headers view, status and
timing). It’s ungated, exactly like typing configure at the SSH terminal.
The AI gets one extra ability — propose a read-only API call (GET) — and
it is structurally GET-only: the tool has no method field, so a
prompt-injected or jailbroken model cannot request a write.
Add a controller
Add an API controller the way you add a device: give it a name, a vendor, and a base URL, then store its credential. Pick one of the vendors below and Transit fills in the base URL and auth scheme and drops in that vendor’s request collection. A Generic kind points the same client + AI at any REST controller — pick the auth scheme yourself (API-key header, Bearer, HTTP Basic, login credentials, or none).
Your credential is stored by reference in your OS keyring (or 1Password / env) and used server-side at request time; it never crosses to the AI or to the app’s own UI, and the host is pinned to your base URL — so neither you nor the AI can point a request, or your credential, at a foreign host.
Which controllers, and how each one authenticates
Every controller authenticates in one of three ways. Which one yours uses decides what you set up once, and whether the AI can investigate it.
| Controller | How you authenticate | AI |
|---|---|---|
| Ubiquiti UniFi | API key | ✅ |
| Cisco Meraki | API key | ✅ |
| NetBox | API token | ✅ |
| Cisco ACI (APIC) | Log in first | ✅ |
| Cisco Catalyst SD-WAN (vManage) | Log in first | ✅ |
| Juniper Apstra | Log in first | ✅ |
| HPE Aruba Central | Log in first (OAuth) | ⚠️ |
| FortiManager / FortiAnalyzer | Log in first | ❌ |
| Anything else (Generic) | You choose | ✅ |
API key — UniFi, Meraki, NetBox
Generate a key in the vendor’s dashboard, paste it in once, and you’re done.
- Meraki — Organization → Configure → API & Webhooks → API keys and access → Generate API Key. Keys are personal to your Dashboard account and you can hold at most two, so if you ever rotate, generate the second before revoking the first.
- UniFi — Site Manager, under API.
- NetBox — your profile → API Tokens. Classic tokens work on every
NetBox version (the preset sends
Authorization: Token <key>); v2nbt_…tokens (NetBox 4.4+) use the Bearer scheme instead. A read-only token is enough — NetBox is also an inventory source, and that path never writes back.
Store the key in your OS keyring, 1Password, or an environment variable — Transit keeps only the reference.
These are the simplest to live with, and the AI works against them immediately, because a stored key is available on every request.
Log in first — ACI, Catalyst SD-WAN, Apstra, Aruba Central, FortiManager
These don’t take a standing key. They want a username and password posted to a login endpoint, and hand back a session token that expires.
Pick Login credentials as the auth scheme and store the username and password. Then open the collection’s Log in first folder and send the login request. Two things happen automatically: your credentials are filled into the request from your keyring at send time — they never appear in the app’s UI or on disk — and the session token that comes back is captured and attached to every other request in the collection for you.
The token expires (APIC’s, for example, after ten minutes). When it does, send the login request again. Nothing else needs re-doing.
Self-signed certificates
On-prem controllers usually present a certificate no public authority vouches for. Transit doesn’t quietly accept it. The first time you reach one, you get its fingerprint and a prompt: verify it out-of-band, and Transit pins that exact certificate for that exact host from then on. Anything else still fails. It’s the same trust-on-first-use model as an SSH host key.
Why the AI can’t drive FortiManager or FortiAnalyzer
Both are JSON-RPC: every call, including reads, is a POST to a single
/jsonrpc endpoint. Transit’s AI is structurally GET-only — the tool it uses
has no method field at all, so it cannot express a POST even if a
prompt-injected model tried. That’s the read-only guarantee doing its job,
not a gap: these collections ship for you to drive, and the AI simply
can’t participate.
Aruba Central is the partial case. Its OAuth login produces a token that lives in your session, which the AI can ride — but if you want the AI working against it unattended, configure a long-lived token with the Bearer scheme instead.
Collections & Postman import
Build and save your own requests into collections, organize them per
controller, and import an existing Postman v2.1 collection (folders and
all). Credentials never survive the trip: auth headers are stripped, and a
literal password sitting in a login body or a collection variable is replaced
with a placeholder you fill in from your keyring. A saved request never stores
a credential. Path variables like {{siteId}} are set once and reused;
right-click a value in a response to capture it into a variable.
What the AI can and can’t do
On an open controller the AI sees the session immediately — it reads the request/response history (redacted) and can propose GETs without you having to send anything first. Each proposed GET passes a GET-only, host-pinned gate and an approval click (or an opt-in per-chat auto-approve for GETs — still GET-only, the gate still runs every time). It can never send a write, reach another host, or see the API key.
Response bodies are redacted before the model sees them by the same
pattern-based filter the terminal uses — it strips secret-shaped tokens
(PEM blocks, API keys, JWTs) and credential-named JSON fields (any
password, passphrase, psk, secret, token, key, or shared-secret
field, matched case-insensitively) on every controller, generic ones
included. It’s best-effort, not a guarantee: a custom API that hides a
secret in an oddly-named field with a non-secret-shaped value could slip
past it — so the hard boundary is the GET-only, host-pinned gate, not
redaction. You always see responses raw. Response headers are a
human-only view and are never sent to the AI.
What it isn’t
Transit’s API client is built for investigation, not API development. It’s deliberately focused — no mock servers, test scripts, or monitors. If you live in a full API IDE, keep it. Transit is the one app where your SSH sessions and your API controllers investigate side by side, under a single read-only AI.