NetLock RMM DocsIntegration endpoints
Every external system NetLock RMM talks to: what it is for, and where to configure it in the Console.
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.
| Endpoint / Service | Purpose | Configuration home |
|---|---|---|
| GitHub | Source for Community Scripts. The Scripts library pulls community-published scripts from a GitHub-backed catalogue and can publish local scripts back. | Chapter 8.1 — Scripts. |
| Winget | Windows package catalogue exposed inside App Hub. A deployment-level Refresh catalogs action syncs the latest catalogue into the Console. | Chapter 8.5 — App Hub. |
| Flathub | Linux package catalogue exposed inside App Hub. Refreshed together with Winget and Chocolatey. | Chapter 8.5 — App Hub. |
| Chocolatey | Secondary Windows package catalogue exposed inside App Hub. | Chapter 8.5 — App Hub. |
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.
| Endpoint / Service | Purpose | Configuration home |
|---|---|---|
| SMTP (any provider) | Email notifications. Global SMTP configuration plus per-recipient addresses. | A.8.2 — Email (SMTP). |
| Microsoft Teams incoming webhook | Post alerts to a Teams channel. One connector per channel. | A.8.3 — Microsoft Teams. |
| Telegram Bot API | Send alerts to a Telegram chat or group via a bot token. | A.8 — Notifications deep dive. |
| ntfy.sh (or self-hosted ntfy) | Push notifications to phones and desktops via topic URL. | A.8 — Notifications deep dive. |
| Generic webhook (notifications) | Arbitrary HTTPS POST per event. Use it to feed a SIEM, a ChatOps pipeline, or any service that accepts JSON. | A.8 — Notifications deep dive. |
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.
| Endpoint / Service | Purpose | Configuration home |
|---|---|---|
| Generic webhook (tickets) | Per-department HTTPS POST fired on ticket lifecycle events (created, replied, resolved, closed). One webhook per department, with per-event toggles. | Chapter 10.16. |
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.
| Endpoint / Service | Purpose | Configuration home |
|---|---|---|
| Azure AD (Microsoft Entra ID) | OIDC sign-in for Azure-federated organisations. | A.4.2 — Single Sign-On. |
| Keycloak | OIDC sign-in backed by a self-hosted Keycloak realm. | A.4.2 — Single Sign-On. |
| Google (Workspace / Identity) | OIDC sign-in for Google-federated organisations. | A.4.2 — Single Sign-On. |
| Okta | OIDC sign-in for Okta tenants. | A.4.2 — Single Sign-On. |
| Auth0 | OIDC sign-in for Auth0 tenants. | A.4.2 — Single Sign-On. |
Saving SSO configuration restarts the Web Console — plan the change during a maintenance window.
X.5.5 AI / LLM providers
The AI / LLM configuration speaks the OpenAI chat-completions shape. Any provider that exposes that shape works.
| Endpoint / Service | Purpose | Configuration home |
|---|---|---|
| OpenAI | Hosted GPT models via https://api.openai.com/v1. | A.11.2 — Provider configuration. |
| Anthropic (OpenAI-compatible endpoint) | Claude models via the OpenAI-compatible endpoint at https://api.anthropic.com/v1. | A.11.2. |
| Ollama | Local model runtime, usually reached on http://localhost:11434/v1. | A.11.2. |
| LM Studio | Local model runtime, usually reached on http://localhost:1234/v1. | A.11.2. |
| Any OpenAI-compatible provider | LocalAI, vLLM, self-hosted OpenAI-compatible gateways. Enter the provider's API Base URL, API Key, and Model manually. | A.11.2. |
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.
X.5.6 Members Portal and vulnerability data
Two infrastructure endpoints that underpin community features and patch management.
| Endpoint / Service | Purpose | Configuration home |
|---|---|---|
Members Portal API (https://api.members.netlockrmm.com) | Deployment-level authentication and distribution for community features — Community Scripts, Community Reports, Community Themes. A single API key is stored on the deployment; every operator inherits it. | Chapter 15 — Community. |
| NVD (National Vulnerability Database) | Source of CVE data shown on the Patch Management → Vulnerabilities tab. The Auto-download toggle refreshes the local copy on a schedule. | Chapter 7.5 — Vulnerabilities. |
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.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, Teams connector host, Telegram API, ntfy.sh (or your self-hosted ntfy), and whatever your generic webhooks target.
- The LLM provider's base URL — only if AI features are enabled.
Cloud deployments delegate this connectivity to the hosted operations team; only the notifications and LLM endpoints remain the customer's firewall concern.
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.