canonical: https://jentic.com/apis/azure.com/azure-managementlinkclient # Microsoft Azure ManagementLinkClient Jentic publishes the only available OpenAPI specification for ManagementLinkClient, keeping it validated and agent-ready. The Azure Resource Links API records logical relationships between Azure resources, even across different resource groups within the same subscription. Use it to create a directional link from a source resource to a target, list every link declared at a subscription or scope, and clean up dangling links when one side is deleted. Each resource can hold up to 50 outbound links and the API is authenticated via Azure Active Directory OAuth 2.0 on Azure Resource Manager. ## For AI agents Declare and inspect logical links between Azure resources so dependency graphs survive across resource groups. Useful for tagging owners, tracking dependencies, and enforcing cleanup workflows. ## Scope Does not enforce dependencies, prevent deletion, or evaluate policy - use for declaring and auditing logical links between Azure resources only. ## Capabilities - Create or update a directional link between two Azure resources, with optional notes describing the relationship - List every resource link declared in a subscription to build a dependency map - List resource links scoped to a specific source resource to inspect its outbound dependencies - Retrieve a single link by ID to inspect the source, target, and notes - Delete an obsolete link without affecting either of the linked resources - Enumerate Microsoft.Resources operations exposed for resource link management ## Use cases ### Document cross-resource-group dependencies Platform teams use the Resource Links API to make implicit dependencies explicit, especially when a workload spans multiple resource groups. Linking an app service to its key vault, storage account, or database produces a queryable graph that audit and incident-response tooling can rely on instead of inferring from naming conventions. Example prompt: PUT /{linkId} with sourceId set to the consuming resource and properties.targetId set to the dependency, including a notes field that explains the relationship. ### Cleanup stale links during decommissioning When a workload is retired, agents iterate through the links attached to its resources and delete each one before the underlying resource is removed. The list-by-scope endpoint returns every link rooted at a given resource so the cleanup step is deterministic, and link delete is a single DELETE call per ID. Example prompt: Call GET /{scope}/providers/Microsoft.Resources/links to enumerate links, then DELETE /{linkId} for each link belonging to a resource scheduled for retirement. ### Build a subscription-wide dependency map Architects feed the subscription-scoped list endpoint into a graph database to visualise how resources reference one another, often layered on top of resource groups and tags. Because links are directional, the resulting graph distinguishes between dependents and dependencies and surfaces orphaned resources that hold no inbound references. Example prompt: Call GET /subscriptions/{subscriptionId}/providers/Microsoft.Resources/links and emit one edge per link with sourceId, targetId, and notes for ingestion into a graph store. ### Agent-driven dependency declarations Through Jentic, an AI agent can read a deployment plan, infer which resources reference which others, and declare links between them automatically. The agent searches Jentic for 'link azure resources', loads the input schema, and chains the create-or-update call once per relationship. Jentic injects the Azure AD bearer token at execution time. Example prompt: Use Jentic search 'create azure resource link', load the operation, supply target resource ID and notes, and execute against the source link ID path. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | PUT | /{linkId} | Create or update a resource link | | GET | /{linkId} | Get a resource link by ID | | DELETE | /{linkId} | Delete a resource link | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.Resources/links | List all links in a subscription | | GET | /{scope}/providers/Microsoft.Resources/links | List links rooted at a source scope | ## Key resources - **ResourceLinks** — Create, get, list, and delete directional links between Azure resources within a subscription. - **Operations** — Enumerate Microsoft.Resources resource provider operations associated with link management. ## Why Jentic - **Setup:** Wiring the Resource Links API by hand means setting up MSAL and an Azure AD service principal, minting bearer tokens against management.azure.com, and handling the unusual nested {linkId} routing plus nextLink pagination yourself. Through Jentic you install once, import ManagementLinkClient from the API Directory, store the service principal credentials once, and your agent calls it. - **Permission scoping:** The link id travels in the URL path (/{linkId}), so a rule can pin your agent to creating and reading links under a named source scope. You choose the operations it may call, so deleting a resource link is not included unless you add it. - **Credential handling:** Your Azure AD client credentials are stored once, encrypted, by your own Jentic One instance and exchanged for a short-lived ARM-scoped bearer token at execution time. The raw secret never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'link two azure resources together' or 'list all resource links in a subscription', and Jentic returns the matching ResourceLinks operation with its input schema so the agent declares links without reading the ARM documentation. ## Related APIs - **Resource Management Client** — Manage the resources and resource groups that links reference. - **Management Lock Client** — Apply read-only and delete locks to the resources tracked by links. - **Azure Resource Graph** — Query Azure resources at scale with KQL rather than maintaining explicit links. - **Policy Client** — Enforce that certain resources must always declare links before deployment. ## FAQ ### Why is there no official OpenAPI spec for ManagementLinkClient? Microsoft Azure does not publish a standalone OpenAPI specification for the resource links API. Jentic generates and maintains this spec so that AI agents and developers can call ManagementLinkClient 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 Resource Links API use? The API uses Azure Active Directory OAuth 2.0 via the azure_auth scheme on https://management.azure.com/. Jentic stores your Azure AD client secret encrypted in its vault and exchanges it for a short-lived bearer token at execution time, so the raw secret never enters the agent context. ### Can I link resources that live in different resource groups? Yes. Resource links are subscription-scoped and the source and target can sit in different resource groups within the same subscription. PUT /{linkId} accepts the full ARM resource ID for both the source path and the targetId in the body. ### How many links can a single resource hold? Each resource can be the source of up to 50 outbound links. Inbound links from other resources do not count against this limit, so widely depended-on resources such as shared key vaults can still appear as the target of many links. ### What are the rate limits for the Resource Links API? The endpoints inherit the standard Azure Resource Manager throttle quotas surfaced through x-ms-ratelimit-remaining-* headers. List operations are paginated with nextLink and agents should follow the link rather than parallelising large scans. ### How do I declare a link through Jentic? Search Jentic for 'create azure resource link', load ResourceLinks_CreateOrUpdate, supply the link path under the source resource and a body with properties.targetId plus optional notes, then execute. The link becomes visible immediately in subscription-wide list calls. ### Does deleting a linked resource remove its links? No. Resource links are stored independently of the resources they reference, so when a linked resource is deleted the link becomes a dangling reference. Cleanup workflows should call DELETE /{linkId} for each affected link as part of resource decommissioning. ### Can I limit what my agent is allowed to do with the Azure Resource Links API? Yes. Because you run Jentic One yourself, your own rules decide which Resource Links operations the agent may call and which Azure AD credentials it may use. Since the link id travels in the URL path (/{linkId}), you can pin the agent to a named source scope and grant only the calls you want, such as creating and reading links while withholding DELETE /{linkId} so it cannot remove links. The agent can reach nothing you have not explicitly allowed.