Platform and integration
API
Application Programming Interface
An API is a defined contract that lets one piece of software call another. It comprises a set of endpoints, request and response shapes, authentication requirements, and rate limits that let a client request data or trigger an action without needing to understand the internals of the system it is calling.
Why API matters in a Microsoft estate
API matters because integrations, APIs, virtual machines, and delivery pipelines are how Microsoft estate data and automation become usable. These terms help readers understand how systems connect before they decide what to build or automate.
How API shows up in practice
In the Microsoft cloud estate that this glossary covers, the API surface that matters most is Microsoft Graph, the single REST and SDK gateway that sits in front of Microsoft 365, Entra ID, Intune, Windows, Teams, SharePoint, and related services. It exposes users, groups, licences, devices, mail, calendars, security signals, and administrative actions through one consistent authentication and permissions model built on OAuth 2.0 and Entra app registrations. For IT teams and MSPs, APIs are what separate a tool that genuinely automates from one that only reports. Reading tenant state through an API is straightforward and low risk, since it requires only read-scoped permissions and cannot change anything. Writing through an API, such as revoking a session, removing a licence assignment, or updating a Conditional Access policy, requires write-scoped permissions and carries real operational weight.
This is why credible tooling separates discovery and read access from any action that changes tenant state, and logs every write call as an auditable event. Rate limits and throttling are a practical constraint that shapes how any Graph-based tool is built. Pulling full licence, device, and user data across even a mid-sized tenant means paging through thousands of objects under Microsoft's throttling policy. Tools that report cost and licence data in near real time are therefore doing meaningful engineering work to batch, cache, and back off correctly, rather than simply querying on demand. API permission scope is also a security and governance question in its own right, not just a technical one.
An app registration that requests Directory.ReadWrite.All when it only needs User.Read.All is a standing risk that a security review should catch. The principle of least privilege applies to the tooling an organisation authorises against its tenant just as much as it applies to the people who use it. For estates already investing in automation, the API layer is also the boundary that determines whether a workflow can be scripted, scheduled, or chained into a pipeline. A product with a documented, stable API lets IT operations build on it, while a product without one locks its data inside its own interface. This is one of the reasons API access and documented Graph permission scopes are now a standard question in vendor evaluation for Microsoft 365 and Azure tooling.