Integration endpoints

NetLock RMM is designed to fit into an existing operations stack rather than replace it. This appendix lists every external system the product talks to, what the integration is for, and where in the Console it is configured. Use it as a firewall-review checklist and as a quick index when you need to find "where do I plug in the X credentials?".

Every row points to the chapter where the integration is documented in depth. The configuration column names the Console page that owns the credentials.

X.5.1 Community and catalogues

Three upstream services feed Collections with content you can pick from or publish into.

Each App Hub catalogue is server-side — the refresh runs on the server, not in the operator's browser. Outbound network reachability to the relevant catalogue is therefore a server firewall concern, not a workstation one.

X.5.2 Notification channels

Five channels on the Notifications page reach outbound destinations. Every channel is independently configurable and every recipient carries a severity filter and a tenant scope.

Each channel has its own Test action that sends a probe. A configuration that has never passed its test is a configuration that silently drops every event until the first failure is noticed — run the test on every channel immediately after setup.

X.5.3 Ticket System webhooks

Separate from the notification webhooks above, the Ticket System has its own per-department outbound webhook surface.

Ticket webhooks follow the same URL + secret + events shape as the notifications webhook but draw from a different event stream. They also require the tickets_manage_webhooks flag.

X.5.4 Identity providers

One SSO provider can be active at a time. All are OpenID Connect — SAML 2.0 is not supported in the current release. The same configuration page hosts tabs for each.

Saving SSO configuration restarts the Web Console — plan the change during a maintenance window.

X.5.5 AI / LLM

Where AI requests go depends on the model source selected on the AI / LLM Settings page. The two paths below are mutually exclusive — a deployment uses one or the other, never both. See A.11.2 — Model selection.

Managed NetLock AI

Selected with Use NetLock AI (managed), and the default for a new deployment.

Your own provider

Selected with Use my own model. The configuration speaks the OpenAI chat-completions shape, so any provider that exposes that shape works. Requests go straight from the Web Console — and, for the end-user tray chat, from the server — to the host you enter; nothing passes through the Members Portal.

localhost in the local-model templates resolves to the host running the Console — not the host running the operator's workstation, and not a device running the agent. Adjust the base URL when the model runs on a different machine. The base URL is used exactly as entered with /chat/completions appended, so it has to carry the /v1 segment where the provider uses one.

X.5.6 Members Portal and vulnerability data

Two infrastructure endpoints that underpin community features and patch management.

X.5.7 Outbound firewall checklist

For a self-hosted deployment, the server needs outbound HTTPS to every endpoint above that the deployment actually uses. A starter checklist:

• api.members.netlockrmm.com — for any community feature, for licence information, and for the managed NetLock AI.
• services.nvd.nist.gov (and its redirects) — for NVD downloads.
• The catalogue hosts for Winget, Flathub, and Chocolatey — only for App Hub refreshes.
• The identity provider's OIDC discovery and token endpoints — only for SSO.
• Each notification destination — SMTP gateway, the host in the Teams webhook URL, Telegram API, ntfy.sh (or your self-hosted ntfy), and whatever your generic webhooks target.
• The LLM provider's base URL — only when AI features are enabled and the deployment uses its own model. With the managed NetLock AI there is no separate AI destination; that traffic goes to api.members.netlockrmm.com.

Cloud deployments delegate this connectivity to the hosted operations team; only the notifications and LLM endpoints remain the customer's firewall concern.

Agent-side egress

The list above covers the server. Every managed device additionally needs outbound access to the deployment's own backend address — the host and port the Agent Download wizard put into the installer, 443 in a standard deployment. That single address carries all five agent roles (communication, remote, update, trust, file server) plus the SignalR command, screen and tunnel hubs, so one rule is enough. There is no UDP side channel and no STUN / TURN traffic.

Where the devices have no direct egress, that traffic can go through a forward proxy. Point the agents at it with the installer's proxy parameters, described in Devices behind an HTTP proxy. Two things matter when the firewall rules are written:

• Only the backend traffic uses the proxy. LAN sensor probes, network and SNMP discovery, Wake-on-LAN and the jump-host end of a tunnel keep connecting directly and must keep their direct path to the local network.
• The proxy has to allow the CONNECT method to the backend host on 443 for the WebSocket transport of the hubs. A proxy that refuses it is not fatal — the connection falls back to server-sent events and then to long polling — but remote control and screen sharing are noticeably slower on the fallback.

Related chapters

• Chapter 8 — Collections — Scripts, App Hub, and the upstream catalogues.
• Chapter 10 — Tickets — department webhooks.
• Chapter 15 — Community — Members Portal API key.
• A.4 — Security: IP whitelist & SSO.
• A.8 — Notifications deep dive.
• A.11 — AI / LLM configuration.