Read live from GET /api/admin/vsites
VSites
Every vrouter and vclient the VSite subsystem has actually created -- the dashboard's only vrouter/vclient surface.
Selected vsite
Vclients
Loading vsites…
Staff-only dev surface
Operate the router fleet.
Create and inspect routers and clients, manage the router fleet, assign users, and inspect decrypted conversations from one protected dashboard.
Staff identity
Admin or support sign in
Telegram is required. In a private DM to the Air Router bot, send:
Set up an authenticator app (Google Authenticator, Authy, 1Password, or similar).
Or enter this key manually:
The QR code and key are not stored across a reload. Restart sign-in to generate a fresh one.
Save these recovery codes. Each works once, if the authenticator app is ever lost. They will not be shown again.
Firebase verifies the password, then a second factor (an authenticator app by default, or Telegram for an account already linked) confirms it. Only server-configured admin and support roles can open these APIs.
Loading
Firebase identity
Add user
Support and admin can both create client or support accounts (never admin -- that role is never offered here). Every new user enrols an authenticator app at first sign-in; linking Telegram afterwards is optional.
Assignments
Users
Staff
| User | Role | Router | State | Actions |
|---|
Client accounts
| User | Role | Router | State | Actions |
|---|
Who changed whose role, and when
Recent role changes
| Time | Actor | Subject | From | To |
|---|---|---|---|---|
| No role changes yet. | ||||
Dev registry · stands in for an eventual ISP customer database
Add customer
Only name is required. This is a staff-only dev tool, seeded with fictional test data -- never a real customer's details.
Add, edit, delete and seed require dev lab mode, a developer-only capability -- this registry stands in for an ISP feed that does not exist yet. Reading customers and linking or unlinking a router to one stays available here regardless.
One customer may hold several routers
Customers
| Name | Contact | Site address | Contract | Routers | Actions |
|---|---|---|---|---|---|
| Loading customers… | |||||
Creates a router VM, enrolled through the same flow as real hardware
Add a router
Nothing is preset: a lab starts with zero routers. Adding one creates a CHR VM and hands it to the enrollment flow below -- it arrives disabled and unpinned until you capture its certificate fingerprint and confirm enabling it.
Adopts existing hardware · never reconfigures it
Add hardware router
Reads the router, pins its certificate and creates an enrollment row. Nothing is written to the router itself, and nothing is written at all until you confirm what it reported. Like a created router, it arrives disabled until you enable it below.
No credential fields. Every router shares one gateway credential -- a per-router field would be collected, stored and ignored.
Optional · can be linked later from the Customers tab
Link this router to a customer?
Every enrolled, enabled router
Router fleet
Reachability is checked by the backend. Management addresses are informational and credentials are never sent to this page.
Provider-supplied, staff-gated
Router enrollment
Every router the identity provider reports, whether or not Air Router has ever contacted it. Auto-populated entries arrive disabled; only an enabled, enrolled router is ever contacted -- enabling/disabling requires a confirmation code, same as any other applied change. A created router needs its certificate fingerprint captured (first contact) before it can be enabled.
| Identity | Kind | Endpoint | Enrolled | Enabled | TLS pin | Credential | Service plan | Actions |
|---|
Recent enrollment activity
| Time | Router | Actor | Action | Outcome |
|---|
Encrypted records
Conversations
Audited read
Conversation detail
Choose a conversation to inspect its decrypted content. User messages are shown exactly as typed, credentials included; credentials are redacted from Air Router's stored reply only. Addresses are never redacted.
Debug context
No debug record selected.
Content-free events
Admin read audit
| Time | Admin | Target | Type | Purpose |
|---|
Role-level, editable narrowing
Client tool policy
Turn off tools a natural-language CLIENT request may not use on their assigned router. Staff (admin/support) are never affected by this policy and always keep full router control.
Toggles that are off below mean CLIENTS cannot ask the assistant to run that tool; staff can still run it themselves. Five tools (VLANs, RouterOS identity, NTP, timezone, and interface toggling) are off for clients by default because they change router or network identity/topology rather than a per-device or per-site control.
| Group | Tool | Default | Client access |
|---|---|---|---|
| Loading… | |||
REQ-AIR-134 · staff-only, audited
Device lifecycle offline TTL
How long a device that has gone offline keeps showing on the client app before it is hidden. Production default is 24 hours; the lab may run a short TTL (e.g. 60 seconds) to demonstrate the behaviour live. This never affects a currently-present device, and never lifts a block or rate limit on a device that ages out.
Recent changes
| Time | Actor | Change |
|---|---|---|
| No changes yet. | ||