canonical: https://jentic.com/apis/azure.com/azure-service-map # Microsoft Azure Service Map Jentic publishes the only available OpenAPI specification for Service Map, keeping it validated and agent-ready. The Azure Service Map API exposes the Microsoft.OperationalInsights/serviceMap feature inside a Log Analytics workspace, giving agents a structured view of every machine, process, listening port, and TCP connection that the Dependency Agent has observed. It models machines, machine groups, client groups, processes, ports, and connections, and produces an on-demand topology map that shows which services talk to which on each host. ## For AI agents Read process- and connection-level dependency data for Windows and Linux servers reporting into a Log Analytics workspace, and generate a topology map for any machine or group. ## Scope Does not collect logs, manage alerts, or trace application requests - use for machine, process, port, and connection dependency reads only. ## Capabilities - List every machine reporting Service Map data into a Log Analytics workspace - Inspect the running processes observed on a specific machine - Enumerate the listening ports and accepting processes on a host - Read the inbound and outbound TCP connections for a machine, port, or process - Generate an on-demand dependency map for a machine or machine group - Group external clients into client groups to simplify the topology - Check the liveness state of a machine, port, or process at a given timestamp ## Use cases ### Migration Discovery Cloud migration teams use Service Map to discover what actually runs and connects on each server before they pick up boxes for replatforming. The machines, processes, and connections endpoints expose the live dependency graph, so an agent can identify shared databases, hidden inbound clients, and chatty east-west traffic that would otherwise break a lift-and-shift plan. Example prompt: Call generateMap for the workspace with the machine ID of the source server and a 24-hour interval, then return the list of unique connected machines and ports ### Incident Blast Radius Analysis When a service starts misbehaving, an SRE needs to know everything that depends on it. The connections endpoint at machine, port, and process scope returns inbound TCP traffic over a chosen interval, so an agent can build a list of upstream clients in seconds rather than chasing logs across hosts. Example prompt: List connections for the machine and port name 443 with a 1-hour interval, then return distinct remote IPs and process names ### Process and Port Inventory Compliance and security teams need a clean inventory of what listens on every server. The ports and acceptingProcesses endpoints return the listening port catalogue per machine and the processes that own those sockets, giving an agent a structured feed for compliance evidence or unexpected listener detection. Example prompt: List ports for the machine, then for each port list acceptingProcesses and return port number, executableName, and processGroupId ### AI Agent Topology Q&A An agent built on Jentic answers infrastructure questions like which servers does the order service depend on without forcing the user to open the Service Map portal. The agent runs generateMap for the relevant machine group, parses the returned nodes and edges, and gives the user a plain-language answer grounded in real telemetry. Example prompt: Search Jentic for generate azure service map dependency map, load the schema, and execute generateMap for the machine group with a 4-hour window ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/features/serviceMap/machines | List all machines in the workspace | | POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/features/serviceMap/generateMap | Generate a dependency map for a machine or group | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/features/serviceMap/machines/{machineName}/connections | List inbound and outbound connections for a machine | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/features/serviceMap/machines/{machineName}/processes | List processes observed on a machine | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/features/serviceMap/machines/{machineName}/ports | List listening ports on a machine | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/features/serviceMap/machines/{machineName}/ports/{portName}/acceptingProcesses | List processes accepting traffic on a port | ## Key resources - **machines** — List and inspect machines reporting Service Map data, plus their processes, ports, and connections - **machineGroups** — Group machines for combined topology and inspection - **clientGroups** — Aggregate external clients connecting to monitored machines into named groups - **processes** — Read processes observed on a machine and their accepting ports and connections - **ports** — Enumerate listening ports per machine and the processes that own them - **generateMap** — Produce an on-demand dependency map for a machine, group, or client group - **summaries** — Read aggregate summaries of machines reporting into the workspace ## Why Jentic - **Setup:** Wiring the Service Map API by hand means registering an Azure AD app, running the OAuth2 azure_auth implicit flow with the user_impersonation scope against management.azure.com, and writing the generateMap request body plus the nested Log Analytics workspace path yourself. Through Jentic you install once, import Service Map from the API Directory, store the Azure service principal credential once, and your agent calls it. - **Permission scoping:** Service Map puts the workspace and machine names in the URL path (.../workspaces/{workspaceName}/features/serviceMap/machines/{machineName}/...), so a rule can pin your agent to one workspace. Its operations are read and map-generation calls, so you choose which the agent may run, such as listing machines or generating a dependency map. - **Credential handling:** Your Azure service principal credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'generate an Azure Service Map dependency map' or 'list listening ports on a monitored machine', and Jentic returns the matching Service Map operation with its input schema so the agent calls the right endpoint directly. ## Related APIs - **Azure Monitor** — Manages metrics, alerts, and diagnostic settings on top of the same Log Analytics workspaces - **Application Insights** — APM telemetry and application-layer dependency tracking - **Azure Workload Monitor** — Workload-level health monitoring across Azure resources ## FAQ ### Why is there no official OpenAPI spec for Service Map? Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Service Map via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Service Map API use? Service Map uses Azure AD OAuth 2.0 with the implicit flow against https://login.microsoftonline.com/common/oauth2/authorize and the user_impersonation scope. When called through Jentic, your AAD service principal credentials live in your Jentic One instance and the agent only sees a short-lived bearer token scoped to the workspace it is reading. ### Can I get a dependency map for a specific server? Yes. POST to /.../features/serviceMap/generateMap with a machine ID or machine group ID and a time interval; the response returns the nodes (machines, processes, client groups) and edges (connections) of the topology for that window. ### How do I find what processes listen on a port? GET /.../machines/{machineName}/ports/{portName}/acceptingProcesses returns every process observed accepting connections on that port. You can pair that with /machines/{machineName}/ports/{portName}/connections to also see who connected to it during the interval. ### What are the rate limits for the Service Map API? Azure Resource Manager applies subscription-level read throttling around 12,000 requests per hour per principal and write throttling around 1,200 per hour, surfaced in the x-ms-ratelimit-remaining-subscription-reads and x-ms-ratelimit-remaining-subscription-writes response headers. Generating a map counts as a single read against quota. ### How do I run a migration discovery query through Jentic? Search Jentic for generate azure service map dependency map, load the schema for POST /.../features/serviceMap/generateMap, and execute it with the source machine ID and a 24-hour interval. The Jentic Python SDK ships the search, load, and execute pattern after pip install jentic. ### Does Service Map require an agent on the server? Yes - the underlying data comes from the Microsoft Dependency Agent installed on each Windows or Linux machine, reporting into a Log Analytics workspace. The API surfaces what the agent has captured; if no agent is installed, the machine simply will not appear in the listings. ### Can I limit what my agent is allowed to do with the Service Map API? Yes. Because Jentic One is self-hosted, you set the rules that decide which Service Map operations and credentials your agent may use. Since the workspace and machine names sit in the URL path (.../workspaces/{workspaceName}/features/serviceMap/machines/{machineName}/...), you can pin the agent to a single Log Analytics workspace, and because every operation is a read or a map-generation call, you choose whether it may only list machines, processes, ports, and connections or also run generateMap. Your Azure service principal credential stays in your own Jentic One instance and is injected at execution time, so the agent never sees it directly.