Netmon 7 API Referencev7.0.20
The complete, endpoint-by-endpoint reference for Netmon’s REST API — the same API the dashboard itself calls, so anything you can see in the browser you can script.
The appliance exposes a single REST API over HTTPS, guarded by per-user tokens — everything the web interface shows is reachable through it.
This guide is the endpoint-level reference for that API. It is written for integrators — anyone building a script, a scheduled job, a monitoring bridge, or a custom client against a Netmon appliance. For the conceptual tour of the programmatic surface — personal access tokens, OAuth, and the ready-made PowerShell, Wireshark, and MCP clients — see API & Integrations in the Product Guide; this reference assumes you have read it and are ready to make calls.
Base URL and transport
Every endpoint is served from the appliance over HTTPS:
https://<your-appliance>/api/...Throughout this guide the host is written as APPLIANCE and the path is shown in full, for example GET /api/devices. Three families of paths are routed to the API:
/api/*— the REST API (the bulk of this guide)./auth/*— the browser-facing OAuth authorization, consent, and token endpoints (see Authentication & OAuth)./.well-known/*— the OAuth discovery documents.
Appliances ship with a self-signed TLS certificate unless you have installed your own (see System Settings & Terminal). Scripts that talk to an appliance still presenting the factory certificate must either trust it explicitly or, for testing only, disable verification — curl -k, Invoke-RestMethod -SkipCertificateCheck, and the equivalents. Prefer installing a trusted certificate over disabling verification in anything that runs unattended.
Credentials at a glance
Every call carries a bearer token in the Authorization header:
curl -H "Authorization: Bearer $TOKEN" https://APPLIANCE/api/devicesA token always acts as the user who created it — it can never do more than that user could do in the browser, and the same tag restrictions follow it. There are three ways to obtain one: a session token from POST /api/login (the credential the web UI mints for itself), a personal access token (PAT) you mint once and paste into a script or scheduler, or an OAuth token obtained through a browser sign-in for installed and interactive clients. Authentication & OAuth covers all three in full; the rest of this guide assumes you have a working token.
How to read an endpoint entry
Each endpoint in this guide is presented the same way: the HTTP method and path, the permission the calling user must hold, a description, the request fields, the response as the appliance actually returns it, notable error responses, and a copy-pasteable curl example. Where a response shape is unusual, or an action is destructive, a note or warning calls it out.
On these pages an endpoint appears as a method badge, the path, and — for endpoints that require one — a permission chip:
GET/api/device/{device}devices
The chip names the permission the calling user must hold. Public endpoints carry no chip; where the requirement is something other than a single permission (for example a browser web session, or any authenticated user), a short Permission line spells it out instead.
This guide is generated against a specific release and describes the API as that release behaves. Where the guide and a running appliance disagree, the appliance wins — check the version on the sign-in page against the version shown at the top of this guide.
The complete API Reference is also available as a single downloadable PDF from the appliance’s Settings → Downloadables.
Getting started
Everything you need before your first call: where the API lives, how to authenticate, the conventions every endpoint shares, and how errors are reported. Read this part once; the resource reference assumes it.
Resource reference
Every endpoint the appliance exposes, grouped by resource family — devices and their trackers, logs, alerting, reports, network tools, and packet capture.
.pcapng.
Administration
The endpoints that manage the appliance itself: system settings, data retention and partitions, backups, users and access, LDAP, the operating-system upgrade surface, and the terminal proxy. Most require the system permission; a few are reserved for the super-administrator (sa).
system-permission settings surface — services, interfaces, time, SMTP, licensing, certificates, downloadables — plus the terminal proxy.
Data MaintenanceData retention, partition management, and per-daemon configuration.
Super-AdminThe most privileged surfaces: LDAP / Active Directory and the OS upgrade (sa-only), plus the OAuth client-approval queue (system).
Users & AccessUser, MFA, and permission management, plus the current-user endpoint.
Reference
Cross-reference tables and a complete, searchable index of every endpoint.